jaclaz

No, it is not "the other way around". The ETDCtrlHelper.exe DOES NOT autostart (with the driver or with the ETDCrtl.exe) at boot. <- this is the actual issue IF run manually throws an error. Adding a "run" key in the Registry it should start BUT the unmodified one should also throw an error, exactly like when run manually. The attempt to make it not error out when run manually was to exclude that it actually *somehow* started AND failed immediately and silently, this is seemingly not the case. jaclaz

Really? Never knew about that. Come on , the issue is that it depends on how exactly the Registries are compared/snapshot/copied/etc. and by which specific software the comparison is made. jaclaz

We don't know yet, as the ETDCtrlHelper.exe won't autostart in XP. I only guessed that - since the same calls to Vista+ user32.dll version are present in very old versions of the driver actually "named" to be for XP - this could be the case, at least for the call to "ChangeWindowMessageFilter". jaclaz

Not necessarily is "Elantech". As an example we have seen that ETDService.exe -install creates a key in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\ETDService For all we know the Setup.exe may create any number of such keys, without Elantech in the name/path. And the .inf contains several HKLM entries, I could understand if - for whatever reason - some are not there in XP, but they should be there in 8.1. Say (a couple for all): HKLM,"%ServiceRoot%\Elantech\DeviceInformation",Port0_MasterDeviceType,%REG_DWORD%,0 HKLM,"%ServiceRoot%\Elantech\GroupOption\GroupMap\IC1059Series_UID_2D",SeriesType,%REG_SZ%,"5" which should expand to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Elantech\... Which in itself may actualy be (offline) either of: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Elantech\... or: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Elantech\... jaclaz

Well that is HKCU only? If there are differences connected to the starting of something they are more likely to be in HKLM. And then (if you include HKLM) you have probably CurrentControlSet "misaligned", the data you provided earlier pointed to having in 8.1 CurrentControlSet corresponding to ControlSet002 (while normally it is ControlSet001). Anyway, let's first see if the crazy Frankendriver Setup.exe attempt leads us forward, otherwise we need to find a way to do a "proper" Registry comparison (there must be a way to get all the info without having MBs in size of unneded other data ). jaclaz

I will throw this on the table (and quickly hide my hand behind my back): https://www.nakka.com/soft/npop/index_eng.html https://npopuk.org.uk/3.04/ jaclaz

Ok, on second thought, it seems like the Setup.exe in tp118w7.exe is XP compatible . Create a new \Frankendriver\X86 directory and populate it with the files from either Z11503-cab or tp118w7 according to the attachment (Frankendriver_setup.xls). Then try running (in XP) the Setup.exe \Frankendriver\X86 If it works, it works. If you still have the issue with ETDCtrlHelper.exe (and only in this case) replace the ETDCtrlHelper.exe with the modified one coming from ETDCtrlHelper_mod_2.zip. If the Setup.exe checks the driver signing (which is invalid), we are stuck. BUT we have still another possibility, in the tp118w7 there are TWO Setup.exe one is in the driver folder \tp118w7\{app}\Elantech\11.4.14.1\X86\ : Setup.exe 05/03/2013 Version 11.0.0.4 whilst the other one is one level above, in \tp118w7\{app}\Elantech\11.4.14.1\ : Setup.exe 14/06/2012 Version 11.0.0.1 which - most probably - should use the setup.ini and the files in \X86 So you could also try to have ALL the files from Z11503-cab in a directory, let's say \mytest\X86, then copy to \mytest\ the Setup.exe from \tp118w7\{app}\Elantech\11.4.14.1\ and run it (the Setup.exe outside the \X86\directory cannot be part of the driver signing). If it installs (wit the same stupid errors as with the .inf install of Z11503-cab, due to the "too high" versions of the files), then you can replace them with the needed ones from tp118w7 as you already did with the current .inf install that partially works. jaclaz Frankendriver_setup.xls

You need to compare the Registry in the Windows 8.1 (where now everything works as it should) with the Registry in XP. It is entirely possible that the key is in installing through the Setup.exe (as opposed to the simpler .inf install). As well it is possible that - when run through the *whatever* autostart mechanism the "normal" ETDCtrlHelper.exe does not throw that error, notwithstanding the dependencies. jaclaz

@Dave-H ONLY intended as "Malo nodo, malus quærendus cuneus" try (it costs nothing) the two attachments (one at the time, of course). To be filed under: half-@§§ed hacks jaclaz P.S.: let me know once you have downloaded them, so that I will remove the attachments.

All the ETDCtrlHelper.exe's (including the one in the very early Z10052) do have a call to User32.dll "ChangeWindowMessageFilter" (while later ones after Z10590 have both that one and the one to "UnregisterPowerSettingNotification"). It is "queer" as at least Z10052 is "expressly" for XP. Anyway, if - as it seems - the missing link is ETDService.exe instead, your next step is searching the Windows 8.1 Registry to find any reference to ETDService.exe. When run on command line we have: ETDService.exe Parameters: -install to install the service. -remove to remove the service. Service failed to run w/err 0x00000427 ETDService.exe -install ETDService is installed. And an entry in the Registry is made: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\ETDService and: ETDService.exe -remove ETDService is removed. the entry is removed allright. It is absolutely possible that the Setup.exe (and not the .inf processing) runs ETDService.exe -install. Check the 8.1 Registry. Try installing the service in XP. The text strings in ETDService.exe do connect it to ETDCtrl.exe: 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