jaclaz

I checked several versions before, most have that call: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-unregisterpowersettingnotification which is seemingly Vista and later. (in User32.dll). Unless I am mistaken, the first (last) ETDCtrlHelper.exe without that call is 10.0.0.7 in Z10590. You can try it, in the worse case it won't work as well. Rename the current ETDCtrlHelper.exe to ETDCtrlHelper(11.0.0.7).exe, then try dropping the one from Z10590 in the directory (then logoff/login/reboot/etc.). As a side note, it has to be undestood if the "defaults" correspond to Registry settings ( and what you change is volatile because it is not written to the Registry) or if they are *somehow*/*somewhere* hardcoded in some of the driver files. jaclaz

Yep, the situation is (and has been) more or less cool in the area I live in (Tuscany). Of course we use all the precautions, surgical masks, etc. (and we will need to use them for a looong period) but - little by little the Governement is loosening a bit the lockdown rules (since the 4th of May). Movements are still limited to motivated reasons, and (still) only intra-regional. There is (undestandably) abroad the idea that Italy is a "monolith", but in reality the really serious problems were limited to 4 Northern regions (Lumbardy, Piedmont, Veneto and Emilia Romagna), we are mid-way both geographically and in number of cases and deaths and the southern regions all in all had it with much smaller effects. Even today, a few weeks after the peak, those 4 regions are about half or more than total number of both new cases and deaths: https://github.com/pcm-dpc/COVID-19/blob/master/schede-riepilogative/regioni/dpc-covid19-ita-scheda-regioni-20200510.pdf Out of the current total of 219,070 cases, those 4 regions make 81,507+28,665+24,796+18,722= 153,690 or 153,690/219,070= 70% The situation, particularly in Lumbardy, has been tragic , even if it is a densely populated region, the numbers are impressive. jaclaz

Bah. Start again from scratch. Uninstall the driver completely. Reinstall the Z115203-cab. Overwrite all files ALREADY EXISTING (AND NOT add any new file) in the installed with the ones coming from 11.4.14.1 (tp118w7), including the .sys. Namely you DO NOT want (for now) in the installed files: 1) ETDApi32.dll 2) ETDIntelligent.exe 3) Lenovo.exe 4) Lenovo_Win8.exe The whole thing should be back to yesterday situation and work the same. jaclaz

Stop ETDCtrl.exe 11.0.0.1 ETDCtrlHelper.exe 10.0.0.83 replace them with ETDCtrl.exe 11.0.0.13 ETDCtrlHelper.exe 11.0.0.7 reboot. ETDCtrlHelper.exe should be running again (and not the ETDIntelligent.exe) Strings from within ETDCtrl.exe (11.0.0.13, but the same is 11.0.0.1) Theory the ETDCtrl.exe tries to find a suitable file in this order, for some reasons the current versions are not compatible, so it loads ETDIntelligent.exe. jaclaz P.S.: Other interesting set of strings: Try adding to the mix the ETDUI.cpl (10.0.0.64) which is only in Z11542 and try deleting (actually better renaming it) the ETDAniConf.exe

Yep, and the fun thing is that ETDCtrlHelper.dll is exactly the same size 1.644.944 bytes, which definitely means that they are two builds/compiles of essentially the same source even a binary compare shows how they are very similar, and both ( I missed it in Dependency Walker) have an unresolved dependency "UnregisterPowerSettingNotification", but very likely this only is an issue when you try to run the file directly. I doubt that the 11.5.4.2 will behave "better" than 11.5.6.6, but as we are proving little by little, you never know until you try, and actually the files in Z11542 seem more similar to those in tp118w7. The ETDIntelligent.exe is only in tp118w7, so you must have copied it accidentally when replacing files. When you are back to a working setup, you should try deleting it. As well you should try deleting (one by one) the following: ETDAniConf.exe ETDApi32.dll ETDMcpl.dll ETD_DLL.dll and see what happens. jaclaz

No, you cannot, not 512 bytes cluster. The "right " cluster size for that size of volume is 32 KB. FAT32 has a 32 bit (or 4bytes) sized file address table (and that explains its name quite nicely). A 32 bit value has 2^32 possible values, including 0. Hence you can index - roughly as few values are reserved - something less than 4,294,967,296 clusters, let's say 4,294,967,290. Now, when you have 4,294,967,290 x 512 bytes/cluster you could have a max capacity in theory (last addressable cluster) of 2,199,023,252,480 bytes, but each of the two fat tables will need to be 4,294,967,290 x 4 = 17,179,869,160 bytes in size (huge and slow, even in theory) BUT in practice the actual useful values stored in a 32 bit FAT table address are actually only 28-bit: https://superuser.com/questions/983139/why-is-fat32-limited-to-just-under-228-clusters so you are limited to 2^28-1-a few reserved values, total 268,435,445. This gives us roughly 268,435,445 x 512 = 137,438,947,840 i.e. roughly 128 GB AND additionally (but this only applies to MS defaults/tools), https://web.archive.org/web/20150331162734/https://support.microsoft.com/en-us/kb/314463 If you check the "standard" MS format tables: https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs-fat-and-exfat if you temporarily set aside the artificial limitation introduced in NT 4.00 and later systems you will notice how cluster size is proportional to volume size, and this happens because the idea is to keep FAT tables of a decent size. So you can use a "third party tool" to format a 2 TB volume, BUT you will need to choose a cluster size that complies with the set limitations. The larger the cluster size the faster would be the filesystem, but there will be more "slack space", areas belonging to a cluster but not occupied by files. If you plan to store millions of 512 bytes in size this is an issue, if you store a small number of huge files it is unnoticeable. Use this: http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm that BTW has this to say: http://www.ridgecrop.demon.co.uk/index.htm?guiformat.htm jaclaz

Again, NO. A RAID 1 is a "plain" mirroring, the two disks appear as a single disk, with the capacity of one of the two (the smallest one in case of different sized disk). A RAID 0 is a (striped) set of two disks that appear to the user as a single disk double the size. You have NOT checked in any sensible way whether the set is a striped set or a (hypothetical) concatenated one, but a RAID 0 will appear to the user EXACTLY as "just the capacity of two disks joined into one". jaclaz

Good. For the record, it wasn't a real shot in the dark , more like an "educated guess" (but still a "wild" one nonetheless). I checked (actually doubting it from the begining) that each and every file in the 11.4.14.1 had no issues on XP with Dependency Walker. I expected that the 11.4.14.1 was too "late" for working on XP, hence the attempts to go back further in time, but evidently - at least limited to the .sys and other "key" files of the driver - that driver is still "old generation enough" to work. Still I have no logical explanation on why the .inf install in Windows 8.1 works (or actually fails to work) as it does, nor I have any deeper understanding on how the various files interact with each other. I still believe that part of the files that are installed are unneeded and can be removed/deleted. It is possible that now that we have a somehow working and "properly" installed driver we actually need to go back a few versions to have it also "properly" working. And we also have to experiment on XP with a modified, simplified, .inf that allows "direct" install, now that we know that the actual driver works, we can forget about having it 8.1 install compatible and .inf on XP should be "easier". Since the tp118w7 (11.4.14.1, .sys 11.0.0.31) is 05/03/2013, and its origin is Lenovo, next experiment is redoing the same, but using the files from Z11566 for the replacement, instead: http://dlcdnet.asus.com/pub/ASUS/nb/DriversForWin8/Touchpad/Touchpad_Elantech_Win7_8_32_VER11566.zip Touchpad_Elantech_Win7_8_32_VER11566.zip that has .sys 11.0.0.6 dated 03/01/2013. and then down to Z11542 http://ftp.tekwind.co.jp/pub/asustw/nb/DriversForWin8/Touchpad/Touchpad_Elantech_Win7_8_VER11542.zip Touchpad_Elantech_Win7_8_VER11542.zip that has .sys 10.0.0.202 dated 30/10/2012 so that (hopefully) we are back to "Asus originated" drivers. You don't need to "re-install" with the Z115203-cab .inf file, you can try just replacing the files, first with the ones from Z11566 and then with the ones from Z11542. Then we will see about Registry and "keeping" settings. jaclaz And now, for NO apparent reason:

Yep, nothing out of the usual. Next test: jaclaz

Yep. Instead of deleting (supposedly) unneeded lines from the (working) Z115203-cab .inf I tried adding to the Z10054 the lines (coming from the Z115203-cab .inf) that should (maybe) needed to install on 8.1 and used the same double quotes style as Z115203-cab. What is in Device Manager (Code 10, nothing, some other driver error code)? We don't know if it didn't install because it didn't install or if it doesn't work because it doesn't work. Check the setupApiDev.log to see if there is any error, compare it with the successful install of Z115203-cab for reference. Back to previous attempts, did you try: 1) install the Z115203-cab "as is" on XP 2) replace all installed files with the files from tp118w7.exe jaclaz

Read only OR with TrustedInstaller credentials required? If the latter, RunAsTI or similar should do: jaclaz

Ok, new (crazy) attempt. I tried to "win8.1fy" the Z10054. http://ftp.tekwind.co.jp/pub/asustw/nb/Drivers/Touchpad/Elantech/ http://ftp.tekwind.co.jp/pub/asustw/nb/Drivers/Touchpad/Elantech/Touchpad_Elantech_Win7_32_Z10054.zip Touchpad_Elantech_Win7_32_Z10054.zip Try installing it in 8.1 using the attached modified .inf. jaclaz Z10054_ETD_mod.inf

Good, (as often happens meaning bad). I will review the changes I made, but I cannot really understand what it could be, all I did was removing a few files that are not used and remove the hardware ID's we are not interested with + the various Registry settings for various apps. The idea - failed at the moment - was to have a simpler, working .inf that would be easier to compare with older .infs in order to be able to try even older versions of the drivers. And it is still surprising that the modified .inf actually works via Setup.exe and not "normally". Anyway, let's get back to where we were before this attempt. Let's recap. You can install (in 8.1) the 11.5.20.3 Z115203-cab with the original .inf both via Setup.exe and via Device Manager/Have disk. and replace files with the ones from And it is still working. So - temporally - we are back to May 2013. Then you could go back in versions on this (or that) file, but when you were mixing too much it stopped working (the three negative tests). Right now, we have (in reverse date order) these: Z11566 Jan 2013 Z11542 Oct 2012 Z11521 Sep 2012 <- and we have already seen that some of the files still work when replaced in the install tp118w7 Z11509 Jul 2012 Z10590 Feb 2012 Z10560 Dec 2011 Z10054 Dec 2011 <- last one with ETD0108 in the .inf Z10053 Nov 2011 Z10052 Oct 2011 <- version "declared" for XP (but without the ETD0108) But we still don't know how to make a .inf that installs correctly any of them and we don't know which actual files are really-really needed and their interaction with each other, nor what actual Registry entries are "needed" and which ones (or their lack thereof ) make a driver not functional. It is possible that - given the "gap" between XP and 8.1 - a driver that would work in XP cannot work in 8.1, and viceversa (which is our current situation) a driver that works in 8.1 doesn't work in XP because of file version of .dll calls, etc., but maybe a little change would make it work. Unless we understand the mechanisms behind we are probably stuck. Do you have the possibility (disk space, source, etc.) to make a (temporary) Windows 7 (or Vista) install? I guess that if we cannot test these "intermediate" drivers on an "intermediate" OS we cannot go further back in time. jaclaz

Cannot find any difference (meaningful ones I mean). There is the (expected) note about user forcing install, but no further differences that I can see: Maybe I really made some (gross) mistake when pruning the .inf? Yet another test. Make a copy of the original .inf. Change something meaningless in it, let's say only put a ; in front of: ASUS_UI_Win10.exe = 1 this should be enough to make the signature not valid. jaclaz

Yep, but until we find out what actually happens (to the Registry) with the original .inf and what actually happens with the modified .inf (and the differences between them) we are stuck. Try checking SetupAPIdev.log: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries maybe threre is a hint there. jaclaz

Sure , it is expected behaviour, but what I don't know is whether - besides the need to "OK the install" - the installing process is different, i.e.: signed diver == unsigned driver with manual OK Or - say - it is needed to use pnputil: https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/pnputil-command-syntax?redirectedfrom=MSDN or some other program. jaclaz

Yep, it seems to me a sensible plan . But it is still needed to understand if the whole matter is related or connected to driver signing/catalog file. It is possible that you will have to edit the (restored) Registry in a couple places, in the HKEY_LOCAL_MACHINE\System\DriverDatabase\ keys. I always had the impression that the signed catalog file was irrelevant on 32-bit systems, if plug and play was not used (i.e. the driver is forced via Device Manager have disk, and the only "issue" is with one or two prompts about driver not signed or not verified), but I may well be wrong about this. jaclaz

Wait a minute. So, a "normal" .inf install with the original file leads to a driver fully working AND the ETDservice.exe NOT installed BUT the correspondent install with the modified file leads to a driver NOT working (still with the ETDservice NOT installed)? The differences in the Registry are more or less the expected ones (corresponding to what I have removed): \Elantech\APOptimize\ \Elantech\GestureAPHotKey\ [-HKEY_LOCAL_MACHINE\System\ControlSet002\Control\Elantech\GroupOption] [-HKEY_LOCAL_MACHINE\System\ControlSet002\Control\Elantech\PointStick] [-HKEY_LOCAL_MACHINE\System\DriverDatabase\DeviceIds\ The "strange" things are: [HKEY_LOCAL_MACHINE\System\ControlSet002\Control\Elantech] "InstallDir"="C:\\Windows\\System32\\DriverStore\\FileRepository\\etd.inf_x86_c8652d0653ac6f04" And: [HKEY_LOCAL_MACHINE\System\DriverDatabase\DriverInfFiles\oem28.inf] @=hex(7):65,00,74,00,64,00,2E,00,69,00,6E,00,66,00,5F,00,78,00,38,00,36,00,\ 5F,00,63,00,38,00,36,00,35,00,32,00,64,00,30,00,36,00,35,00,33,00,61,00,63,\ 00,36,00,66,00,30,00,34,00,00,00,00,00 "Active"="etd.inf_x86_c8652d0653ac6f04" (the hex corresponds to "etd.inf_x86_c8652d0653ac6f04", fine) [-HKEY_LOCAL_MACHINE\System\DriverDatabase\DriverPackages\etd.inf_x86_1e2b347cb91ba70d] [HKEY_LOCAL_MACHINE\System\DriverDatabase\DriverPackages\etd.inf_x86_c8652d0653ac6f04] "SignerName"="" "Version"=hex(3):00,FF,00,00,00,00,00,00,6F,E9,36,4D,25,E3,CE,11,BF,C1,08,\ 00,2B,E1,03,18,00,80,57,05,7F,C2,D0,01,03,00,14,00,05,00,0B,00,00,82,00,00,\ 00,00,00,00 "Provider"="ELAN" "InfName"="etd.inf" "OemPath"="f:\\11.5.20.3 - works in 8.1" "SignerScore"=dword:80000000 "StatusFlags"=dword:00000016 @="oem28.inf" (the hex corresponds to ???) As a side note, It is "unusual" that ControlSet002 is in use (not a real problem, only a sign that the actual 8.1 install is not wholly "kosher". The latter one is about one of the drivers actually installed, but you have to check the "other" snapshot to see if there is a corresponding entry for etd.inf_x86_1e2b347cb91ba70d, this probably is connected with driver signing? jaclaz

It is "thread" written in a SMS or by a lazy person (I would think the latter, since it is not a SMS and no link to the specific thread where the other 2 personal mitigations are was given). jaclaz

It is puzzling. Unless *for some reasons* the service is installed by *something else* seemingly unrelated. Now the only things disabled should be: ;SensePoint.exe = 1 ;ASUS_UI_Win10.exe = 1 and, below: ;ETD_PSTUI.AddReg You can try UNREMing them, but I doubt that they are connected to the service issue. Manually, maybe the <ETDService.exe -install> needs some other parameters? You need to snapshot the Registry and find the differences. jaclaz

No. It is pretty much binary. Something is either RAID 0 or is it not. https://en.wikipedia.org/wiki/Law_of_excluded_middle How (EXACTLY) do you know they are not striped? Sure, that is what a RAID 0 should appear to the user. https://en.wikipedia.org/wiki/Standard_RAID_levels https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0 jaclaz

Ok, so - still in 11.5.20.3 and with the driver installed via the .inf and not via setup.exe - the issue is now to have the ETDservice.exe install/start. I.e. in your current situation, we need to find a way to manually do the *whatever* the setup.exe does and the "plain" ETF.inf does not. Just an idea, but maybe this is connected to the "coinstaller" thingy seen before, is it possible that the setup.exe works in some versions as a coinstaller (and in some other versions the coinstaller is instead external)? I don't know, it is more likely that I did some mistakes in the editing of the .inf. What happens (now) if you re-try installing (via Device Manager/Have disk) the 11.5.20.3 with the untouched "ETD.inf"? (or if you prefer, is it possible that I removed "too much" - but WHAT could it be - in the modified .inf?) What I disabled in the reduced .inf, in a nutshell: ;SensePoint.exe = 1 <- surely unused ;ETDAniConf.exe = 1 <- maybe this is needed even if there is no .avi ;ASUS_UI_Win10.exe = 1 <- surely unused ;ETDMcpl.dll,,,0x00000001 <- maybe this is used ; ETD_DLL.dll,,,0x00000001 <- maybe this is used IF the 11.5.20.3 with the "original" .inf installs fine, uninstall it and try installing it with the new modified attachment (I restored a few of the files above). Then (if the original .inf does not work via Device Manager/Have disk) the only possible move ahead is: 1) uninstall completely 2) reinstall the original 11.5.20.3 via Setup.exe (so that it is working/running) 3) take a Registry snapshot 4) uninstall completely 5) reinstall the original 11.5.20.3 BUT via Device Manager/Have Disk 6) take another Registry snapshot 7) compare the two snapshots Now what would be a suitable tool to do these snapshots/compares? (that works under 8.1 I mean) Try this Nirsoft thingy: https://www.nirsoft.net/utils/registry_changes_view.html Cannot say if Regshot V2/unicode runs in 8.1.: https://www.portablefreeware.com/index.php?id=2505 jaclaz Z115203-cab_mod_2_ETD.zip

Good. This is "queer", maybe I did some mistake in the editing? (I left both NTx86.6.2 and NTx86.6.3, as they point to the same _Win8 sections). And this is almost extraordinary, there is no ".avi" text in the whole modified .inf But did you try installing via Device Manager "have disk" or using the Setup.exe? (Maybe the .avi files are "hardcoded" in the setup.exe or there is a directive that copies all the files in source. jaclaz

OK. good (meaning bad), another data point to be reviewed, I'll check these results . In the meantime I have tried "pruning" the ETD.inf in Z115203-cab and compared it to a number of other versions ETD.inf's. I could not find a reason why the Z115203-cab "as is" installs and previous (not Lenovo, actually Asus) drivers do not. The only meaningful (but meaningless ) difference I could find is a different use of the "" (double quotes) in Registry paths that include "%ServiceRoot%". It is strange. Anyway, completely new test. 1) Save your current situation. 2) uninstall completely the Elan drivers from 8.1 3) try installing again the Z115203-cab, BUT using the attached "leaner" .inf (rename the "standard" ETD.inf to Z115203-cab.inf and copy/rename the attached to ETD.inf 4) hopefully it should install (and work) as the original, I commented out all the .avi's so no animations and a few other files that shouldn't be strictly necessary. IF it does (which is not given ), proceed as follows: 5) uninstall (again) completely the Elan drivers 6) get the Z11566 from here: http://ftp.tekwind.co.jp/pub/asustw/nb/DriversForWin8/Touchpad/Touchpad_Elantech_Win7_8_32_VER11566.zip ("sane" size, 14 MB) 7) replace the ETD.inf with the attached .inf as in #3 above 8) try installing it jaclaz Z115203-cab_mod_ETD.zip

OK. So we now know that the version of ETDapix.dll 11.0.0.8 is the minimum version that works with ETDCtrl.exe 11.0.0.13 (and ETDCtrlHelper.exe 11.0.0.7) Now, what happens (keeping the ETDapix.dll version 10.0.0.98) if you try "downgrading" (in pairs) ETDCtrl.exe and ETDCtrlHelper.exe? With: ETDCtrl.exe 10.0.0.117 ETDCtrlHelper.exe 10.0.0.73 from Z11521 If - by any chance - the driver comes back to life, then try: ETDCtrl.exe 10.0.0.101 ETDCtrlHelper.exe 10.0.0.67 from Z11509. If it doesn't, restore the ETDCtrl.exe 11.0.0.13 and ETDCtrlHelper.exe 11.0.0.7 and try downgrading the .sys from the curent one (ETD.sys 11.0.0.31) to 10.0.0.188 and if it works, try again downgrading the two .exe's. @RainyShadow The (stupid) .inf of the (only currently installing without mods) Z115203-cab is huge, almost 2 MB and "as is" it is "unworkable", It must (IMHO) be trimmed down removing all the clutter before being able to do the "fine tuning", some parts are clearly needed, but I am pretty sure (but not too much) that most parts are "unneeded", several models, the Windows 10 provision, etc. As soon as I have some time I'll try looking at it. The coinstaller is a non-problem (anymore), as the Z115203-cab (which installs just fine) has it not, and the earler "Lenovo" driver currently under test (tp118w7) and that is working also has it not, and all the earlier drivers also have it not, it must have been introduced for *some reasons* in mid 2014, but we are already back to march 2013. jaclaz