[SOLVED] Elan PS/2 Touchpad Driver for XP

[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

[Dave-H]

OK, I'll uninstall again and then install using the original INF, and make a registry snapshot.
I'll then uninstall again, and reinstall using your cut down INF.
I'll then do another registry snapshot and use Nir Sofer's program to compare them, and see if we can see what the relevant differences are.

[Dave-H]

OK, I uninstalled, and reinstalled using the default INF.
I went and checked, and the ETDService service wasn't installed!
I hadn't noticed until then that it wasn't actually there any more with a normal INF-only install.
So, it must be another thing (along with the avi files) that is installed by the setup program, not by the INF!
More significantly, it also means that it's not necessary, as the driver was still working fine!

Anyway, attached is the differences between the two registry snapshots, only including the entries which appeared to be Elan related.
The whole thing was huge of course!
HTH.

ElanDifferences.reg

Edited May 7, 2020 by Dave-H
Amendment

[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

 

 

 

 

 

Edited May 8, 2020 by jaclaz

[Dave-H]

4 hours ago, jaclaz said:

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 ERDservice NOT installed)? 

Yes, that certainly seems to be the case!

How about I reinstall the driver from the default INF, using Device Manager, and then when I have a working driver I back up the whole registry with ERUNT, then uninstall the driver and do the same install with your INF, which will presumably result in a non-working driver, and then restore the whole registry back again from the backup I made while the driver was working?
If the driver then works, presumably that will prove that the problem is in the registry, not missing files or anything like that.
If the driver still doesn't work, that means it's a file problem, not a registry problem.
That will at least narrow things down a bit perhaps.

 

[jaclaz]

40 minutes ago, Dave-H said:

Yes, that certainly seems to be the case!

How about I reinstall the driver from the default INF, using Device Manager, and then when I have a working driver I back up the whole registry with ERUNT, then uninstall the driver and do the same install with your INF, which will presumably result in a non-working driver, and then restore the whole registry back again from the backup I made while the driver was working?
If the driver then works, presumably that will prove that the problem is in the registry, not missing files or anything like that.
If the driver still doesn't work, that means it's a file problem, not a registry problem.
That will at least narrow things down a bit perhaps.

 

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

[Dave-H]

Certainly the driver signing is broken when the install is done with the modified INF, I have to OK the install, which I don't have to with the default INF.
I assume that's expected behaviour, as the driver cannot be considered to be still signed if the INF has been "tampered with"!

[jaclaz]

51 minutes ago, Dave-H said:

Certainly the driver signing is broken when the install is done with the modified INF, I have to OK the install, which I don't have to with the default INF.
I assume that's expected behaviour, as the driver cannot be considered to be still signed if the INF has been "tampered with"!

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

 

Edited May 8, 2020 by jaclaz

[Dave-H]

OK I did my registry restore test, and restoring the registry does make the driver work again.
So I think that proves that the problem with the modified INF is in its registry sections, not anything to do with what files are copied or not copied.
One other thing I've now noticed is that when the driver is uninstalled after an install with the default INF, the mouse correctly reverts to its previous name in Device Manager (Microsoft PS/2 Mouse).
After an uninstall of an installation with the modified INF, it remains as "Elan Input Device" and the driver has to be manually rolled back to revert it correctly.
Another symptom of a problem with the registry entries in the modified INF I assume, in the uninstall section.

[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

[Dave-H]

OK, here's the logs.
I hope they provide some clues.
The log of the default install is a lot bigger than the log of the modified install!

NormalInstall.txt
NormalUninstall.txt
ModifiedInstall.txt
ModifiedUninstall.txt

Edited May 8, 2020 by Dave-H
Typo

[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:

Quote

!!!  sig:                     Driver package INF file hash is not present in catalog file. Filename = etd.inf, Error = 0xE000024B
!    sig:                     Driver package appears to be tampered, but user wants to install it anyway.
     sto:                {DRIVERSTORE IMPORT VALIDATE: exit(0x00000000)} 17:14:27.721
     sig:                Signer Score = 0x80000000
     sig:                Signer Name  = <unsigned>

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

[Dave-H]

Tried that, I then had to OK the install, as expected, but the driver still installed and is working fine!

[jaclaz]

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

Quote

tp118w7.exe

Official version 11.4.14.1 actual .sys file 11.0.0.31.

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

[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