I get complaints from users that (rarely) my driver refuses to install.
Finally, I managed to create an environment where I can reproduce the problem. It is a Vista x64 (Virtual Machine) where a previous version of my driver was installed and removed.
Detailed description:
There are two flavors to my driver: v2.0.5 and v2.1.5
When I install either one, no problem.
When I install one of them, remove it then install the other flavor ? it does not install properly.
When I try to reinstall the same driver ? no problem.
I ruled out signature issues because:
The driver (v2.0.5) installs OK when first
There’s no change in behavior when machine in TESTSIGN mode
For the sake of this post I successfully installed v2.0.5 and saved its setupapi.dev file.
Then I restarted the test, installed 2.1.5, removed it cleaned log files an unsuccessfully installed 2.0.5 and saved its setupapi.dev file.
Here are the main differences I can find:
In this section of the BAD setupapi.dev file.
I manually encapsulated (*****) a block that is missing in the GOOD setupapi.dev file.
Also, Line ?ScanQ end Validity flags=620 CopyNodes=XXX? is different : XXX=0 in bad file, XXX=2 in good file.
dvi: {_SCAN_FILE_QUEUE}
flq: ScanQ flags=620
flq: SPQ_SCAN_PRUNE_COPY_QUEUE
flq: SPQ_SCAN_FILE_COMPARISON
flq: SPQ_SCAN_ACTIVATE_DRP
flq: ScanQ number of copy nodes=6
***************************************************************************************************************
flq: File ‘C:\Windows\system32\DRIVERS\hidkmdf.sys’ pruned from copy.
sig: Using catalog ‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem5.CAT’.
! sig: VerifyTrustFailed for C:\Windows\system32\DRIVERS\hidkmdf.sys.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
cpy: DrpSetRegFileProt ‘C:\Windows\system32\DRIVERS\hidkmdf.sys’ Status=0 Class=OEM Legacy
flq: File ‘C:\Windows\system32\DRIVERS\vjoy.sys’ pruned from copy.
sig: Using catalog ‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem5.CAT’.
! sig: VerifyTrustFailed for C:\Windows\system32\DRIVERS\vjoy.sys.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
cpy: DrpSetRegFileProt ‘C:\Windows\system32\DRIVERS\vjoy.sys’ Status=0 Class=OEM Legacy
***************************************************************************************************************
flq: File ‘C:\Windows\system32\WdfCoInstaller01005.dll’ pruned from copy.
sig: Using catalog ‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem5.CAT’.
! sig: VerifyTrustFailed for C:\Windows\system32\WdfCoInstaller01005.dll.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
cpy: DrpSetRegFileProt ‘C:\Windows\system32\WdfCoInstaller01005.dll’ Status=0 Class=OEM Legacy
flq: File ‘C:\Windows\system32\DRIVERS\hidusb.sys’ pruned from copy.
sig: Using catalog ‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Package_27_for_KB948465~31bf3856ad364e35~amd646.0.1.18005.cat’.
cpy: DrpSetRegFileProt ‘C:\Windows\system32\DRIVERS\hidusb.sys’ Status=0 Class=Inbox Windows protected
flq: File ‘C:\Windows\system32\DRIVERS\hidclass.sys’ pruned from copy.
sig: Using catalog 'C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Package_27_for_KB948465~31bf3856ad364e35~amd646.0.1.18005.cat’.
cpy: DrpSetRegFileProt ‘C:\Windows\system32\DRIVERS\hidclass.sys’ Status=0 Class=Inbox Windows protected
flq: File ‘C:\Windows\system32\DRIVERS\hidparse.sys’ pruned from copy.
sig: Using catalog ‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Package_27_for_KB948465~31bf3856ad364e35~amd64~~6.0.1.18005.cat’.
cpy: DrpSetRegFileProt ‘C:\Windows\system32\DRIVERS\hidparse.sys’ Status=0 Class=Inbox Windows protected
flq: ScanQ action=200 DoPruning=32
flq: ScanQ end Validity flags=620 CopyNodes=0
dvi: {_SCAN_FILE_QUEUE exit(0, 0x00000000)}
As consequence, following this section the GOOD log file describes successful {_COMMIT_FILE_QUEUE} section.
Later, there are additional problems but they probably stem from the differences seen here.
Are you the developer of the vjoy package, or is your product something
else? Looking at the sourceforge site, the files that fail to verify look
like they come from the vjoy package. The site http://systemexplorer.net/file-database/file/vjoy-sys says there are 29
different variations of vjoy.sys.
You said you don’t think it’s a signature verification issue, yet the
errors you highlighted in the log are signature verification errors. So
what do the certificate chains for the files that don’t verify look like?
For the most accurate verification, it’s best to run the signtool verify
on the specific system that has the problem, as there have been updates to
the the crypto support libs, you also want to see the certificate chains
referenced using the certificate stores on failing system. For example,
there were issues in kernel code SHA2 signatures, and an update was only
released last fall (see KB2949927).
Another thing you could do is turn on the ETW traces for signature
checking, I believe they are named “Code Integrity” in the trace UI. This
might give additional clues on why the signatures are not verifying.
Another option is you could stop supporting Windows Vista, Microsoft ended
mainstream support for Vista in 2012.
>I get complaints from users that (rarely) my driver refuses to install. >Finally, I managed to create an environment where I can reproduce the >problem. It is a Vista x64 (Virtual Machine) where a previous version of >my driver was installed and removed. > >Detailed description: >There are two flavors to my driver: v2.0.5 and v2.1.5 >When I install either one, no problem. >When I install one of them, remove it then install the other flavor ? it >does not install properly. >When I try to reinstall the same driver ? no problem. > >I ruled out signature issues because: >1. The driver (v2.0.5) installs OK when first >2. There’s no change in behavior when machine in TESTSIGN mode > >For the sake of this post I successfully installed v2.0.5 and saved its >setupapi.dev file. >Then I restarted the test, installed 2.1.5, removed it cleaned log files >an unsuccessfully installed 2.0.5 and saved its setupapi.dev file. > >Here are the main differences I can find: > >In this section of the BAD setupapi.dev file. >I manually encapsulated () a block that is missing in the GOOD >setupapi.dev file. >Also, Line ?ScanQ end Validity flags=620 CopyNodes=XXX? is different : >XXX=0 in bad file, XXX=2 in good file. > > dvi: {_SCAN_FILE_QUEUE} > flq: ScanQ flags=620 > flq: SPQ_SCAN_PRUNE_COPY_QUEUE > flq: SPQ_SCAN_FILE_COMPARISON > flq: SPQ_SCAN_ACTIVATE_DRP > flq: ScanQ number of copy nodes=6 >******************************** > > flq: File ‘C:\Windows\system32\DRIVERS\hidkmdf.sys’ >pruned from copy. > sig: Using catalog >‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem5.C >AT’. >! sig: VerifyTrustFailed for >C:\Windows\system32\DRIVERS\hidkmdf.sys. >! sig: Error 0x800b0109: A certificate chain processed, >but terminated in a root certificate which is not trusted by the trust >provider. > cpy: DrpSetRegFileProt >‘C:\Windows\system32\DRIVERS\hidkmdf.sys’ Status=0 Class=OEM Legacy > flq: File ‘C:\Windows\system32\DRIVERS\vjoy.sys’ >pruned from copy. > sig: Using catalog >‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem5.C >AT’. >! sig: VerifyTrustFailed for >C:\Windows\system32\DRIVERS\vjoy.sys. >! sig: Error 0x800b0109: A certificate chain processed, >but terminated in a root certificate which is not trusted by the trust >provider. > cpy: DrpSetRegFileProt >‘C:\Windows\system32\DRIVERS\vjoy.sys’ Status=0 Class=OEM Legacy > > ************************************* > flq: File >‘C:\Windows\system32\WdfCoInstaller01005.dll’ pruned from copy. > sig: Using catalog >‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\oem5.C >AT’. >! sig: VerifyTrustFailed for >C:\Windows\system32\WdfCoInstaller01005.dll. >! sig: Error 0x800b0109: A certificate chain processed, >but terminated in a root certificate which is not trusted by the trust >provider. > cpy: DrpSetRegFileProt >‘C:\Windows\system32\WdfCoInstaller01005.dll’ Status=0 Class=OEM Legacy > flq: File ‘C:\Windows\system32\DRIVERS\hidusb.sys’ >pruned from copy. > sig: Using catalog >‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Packag >e_27_for_KB948465~31bf3856ad364e35~amd64 6.0.1.18005.cat’. > cpy: DrpSetRegFileProt >‘C:\Windows\system32\DRIVERS\hidusb.sys’ Status=0 Class=Inbox Windows >protected > flq: File ‘C:\Windows\system32\DRIVERS\hidclass.sys’ >pruned from copy. > sig: Using catalog >'C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Packag >e_27_for_KB948465~31bf3856ad364e35~amd64 6.0.1.18005.cat’. > cpy: DrpSetRegFileProt >‘C:\Windows\system32\DRIVERS\hidclass.sys’ Status=0 Class=Inbox Windows >protected > flq: File ‘C:\Windows\system32\DRIVERS\hidparse.sys’ >pruned from copy. > sig: Using catalog >‘C:\Windows\system32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Packag >e_27_for_KB948465~31bf3856ad364e35~amd64~~6.0.1.18005.cat’. > cpy: DrpSetRegFileProt >‘C:\Windows\system32\DRIVERS\hidparse.sys’ Status=0 Class=Inbox Windows >protected > flq: ScanQ action=200 DoPruning=32 > flq: ScanQ end Validity flags=620 CopyNodes=0 > dvi: {_SCAN_FILE_QUEUE exit(0, 0x00000000)} > > >As consequence, following this section the GOOD log file describes >successful {_COMMIT_FILE_QUEUE} section. >Later, there are additional problems but they probably stem from the >differences seen here. > > >— >NTDEV is sponsored by OSR > >Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > >OSR is HIRING!! See http://www.osr.com/careers > >For our schedule of WDF, WDM, debugging and other seminars visit: >http://www.osr.com/seminars > >To unsubscribe, visit the List Server section of OSR Online at >http://www.osronline.com/page.cfm?name=ListServer
Based on your insight, I made additional tests and found out that my ‘minimal function driver’ (hidkmdf.sys) was only test-signed.
Replacing this file with a properly signed file solves the problem.
This leaves me with a few questions:
Why doesn’t this problem occur on Windows 8?
Why did the problem occur on a Vista machine that was in TESTSIGNING mode?
Why doesn’t this problem occur on a ?clean? Vista machine?
>> Are you the developer of the vjoy package, or is your product something else Looking at the sourceforge site, the files that fail to verify look
like they come from the vjoy package.
Yes. I’m the author of vJoy that is hosted on SF. Nothing to do with HeadSoft’s product.
>> Another option is you could stop supporting Windows Vista, Microsoft ended
mainstream support for Vista in 2012.
Not a real option is it. I support XP 32 bit too. This is what many people still use.
I still think it is interesting that Windows 8 accepts a Filter Driver, even if it is a SHIM driver, that is not signed.
Right now no-one complains but I need to understand.