A Signed Driver Installs Only With WinDbg

Hello everyone!

I have a strange problem that is somehow connected to WinGbg so I thought to post here about it.

We test a driver on a virtual machine with Win 7 x64 and VMware Workstation.
When WinDbg is started and rests on a COM port pipe, the driver installs smoothly on the virtual machine.
But when I try to install a signed driver on the virtual machine without WinDbg running and attached, I get this error: http://screencast.com/t/IYd3ezTCnww

It reads as Windows is unable to verify a digital signature of the driver.

But I have signed the driver with a DigiCert valid certificate and their utility and the process has completed correctly. But after the installation, the icon marked with yellow exclamation mark appears on a driver item in the Device Manager and the device properties read as the driver is unproperly signed - error 52.

We do every operation on Windows 7 x64 Service Pack 1: http://screencast.com/t/2HVY7gZYHQs0

  1. We build the driver project using WDK 7600.16385.1: http://screencast.com/t/22VpFGWr4gh

Here is the screencast video: http://screencast.com/t/gCukl8j4oQ1

  1. We add “WdfCoInstaller01009.dll” to our output.

  2. We sign a driver binary UemPcSc.sys using DigiCert tool

  3. We create .cat file by issuing this command: “inf2cat /driver:D:_Projects\WinXPBusTest\uempcsc\objchk_win7_amd64\amd64 /OS:7_x64”

The screencast video: http://screencast.com/t/NMIkQ4dneY

  1. We sign the catalog file uempcsc.cat using the same tool

  2. We install the driver using Device Manager, but it doesn’t start, showing error code 52 in the end: http://screencast.com/t/gucwd6Jab

The video: http://screencast.com/t/90LHyCUQ4i

I’ve tried to figure out this situation with error code 52 using some Internet articles: http://www.davidegrayson.com/signing/

But they don’t provide any possible clues…

We’ve installed all updates available from the Windows Update.

Still the problem persists.

See below the setup log extract - you can see the problem places there marked as exclamation marks to the left:
sig: Catalog = C:\Windows\System32\DriverStore\FileRepository\uempcsc.inf_amd64_neutral_cfa4a2cff7dabe40\uempcsc.cat
! sig: Verifying file against specific (valid) catalog failed! (0x800b0109)
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

! sig: VerifyTrustFailed for C:\Windows\system32\DRIVERS\uempcsc.sys.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

!!! dvi: Device not started: Device has problem: 0x34: CM_PROB_UNSIGNED_DRIVER.

So I don’t know how might I correct “A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider”.

When I check the signed SYS’s properties, it looks fine and valid: http://screencast.com/t/T2KKAlgpZ

I’ve tried several ways:

  1. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, generate .cat, sign .sys, .dll, .cat
  2. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, generate .cat, sign .sys, .cat
  3. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, generate .cat, sign .cat
  4. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, sign .sys, .dll, generate .cat, sign .cat
  5. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, sign .sys, generate .cat, sign .cat

I’ve used inf2cat tool 2.6.0.0 from WinDDK 7600.16385.1 and inf2cat tool 3.2.0.0 from WDK 8.1

I tried to add timestamp and not.

With no luck: upon checking .sys or .cat (see the setud.dev.log extract above) the setup fails with error 52.

This is a VERY odd error, I simply can’t figure out how can WinDbg influence the driver installation process in such a way. Why everything installs smoothly if it’s running and connected to the virtual machine.

Please help - maybe someone has had similar problem or knows some WinDbg features that might somehow affect the driver…

You’ve signed it but you haven’t installed the public version of your cert
on the system. You need to do that as well for a non-whql’d driver. See
“Release Signing” in the kernel mode signing doc.

Mark Roddy

On Fri, Feb 26, 2016 at 5:14 AM, wrote:

> Hello everyone!
>
> I have a strange problem that is somehow connected to WinGbg so I thought
> to post here about it.
>
> We test a driver on a virtual machine with Win 7 x64 and VMware
> Workstation.
> When WinDbg is started and rests on a COM port pipe, the driver installs
> smoothly on the virtual machine.
> But when I try to install a signed driver on the virtual machine without
> WinDbg running and attached, I get this error:
> http://screencast.com/t/IYd3ezTCnww
>
> It reads as Windows is unable to verify a digital signature of the driver.
>
> But I have signed the driver with a DigiCert valid certificate and their
> utility and the process has completed correctly. But after the
> installation, the icon marked with yellow exclamation mark appears on a
> driver item in the Device Manager and the device properties read as the
> driver is unproperly signed - error 52.
>
> We do every operation on Windows 7 x64 Service Pack 1:
> http://screencast.com/t/2HVY7gZYHQs0
>
> 1. We build the driver project using WDK 7600.16385.1:
> http://screencast.com/t/22VpFGWr4gh
>
> Here is the screencast video: http://screencast.com/t/gCukl8j4oQ1
>
> 2. We add “WdfCoInstaller01009.dll” to our output.
>
> 3. We sign a driver binary UemPcSc.sys using DigiCert tool
>
> 4. We create .cat file by issuing this command: “inf2cat
> /driver:D:_Projects\WinXPBusTest\uempcsc\objchk_win7_amd64\amd64 /OS:7_x64”
>
> The screencast video: http://screencast.com/t/NMIkQ4dneY
>
> 5. We sign the catalog file uempcsc.cat using the same tool
>
> 6. We install the driver using Device Manager, but it doesn’t start,
> showing error code 52 in the end: http://screencast.com/t/gucwd6Jab
>
> The video: http://screencast.com/t/90LHyCUQ4i
>
> I’ve tried to figure out this situation with error code 52 using some
> Internet articles: http://www.davidegrayson.com/signing/
>
> But they don’t provide any possible clues…
>
> We’ve installed all updates available from the Windows Update.
>
> Still the problem persists.
>
> See below the setup log extract - you can see the problem places there
> marked as exclamation marks to the left:
> sig: Catalog =
> C:\Windows\System32\DriverStore\FileRepository\uempcsc.inf_amd64_neutral_cfa4a2cff7dabe40<br>> uempcsc.cat
> ! sig: Verifying file against specific (valid) catalog
> failed! (0x800b0109)
> ! sig: Error 0x800b0109: A certificate chain processed, but
> terminated in a root certificate which is not trusted by the trust provider.
> …
> ! sig: VerifyTrustFailed for
> C:\Windows\system32\DRIVERS\uempcsc.sys.
> ! sig: Error 0x800b0109: A certificate chain
> processed, but terminated in a root certificate which is not trusted by the
> trust provider.
> …
> !!! dvi: Device not started: Device has problem:
> 0x34: CM_PROB_UNSIGNED_DRIVER.
>
> So I don’t know how might I correct “A certificate chain processed, but
> terminated in a root certificate which is not trusted by the trust
> provider”.
>
> When I check the signed SYS’s properties, it looks fine and valid:
> http://screencast.com/t/T2KKAlgpZ
>
> I’ve tried several ways:
> 1. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, generate .cat,
> sign .sys, .dll, .cat
> 2. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, generate .cat,
> sign .sys, .cat
> 3. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, generate .cat,
> sign .cat
> 4. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, sign .sys, .dll,
> generate .cat, sign .cat
> 5. rebuild .sys, Generate inf, recopy WdfCoInstaller dll, sign .sys,
> generate .cat, sign .cat
>
> I’ve used inf2cat tool 2.6.0.0 from WinDDK 7600.16385.1 and inf2cat tool
> 3.2.0.0 from WDK 8.1
>
> I tried to add timestamp and not.
>
> With no luck: upon checking .sys or .cat (see the setud.dev.log extract
> above) the setup fails with error 52.
>
> This is a VERY odd error, I simply can’t figure out how can WinDbg
> influence the driver installation process in such a way. Why everything
> installs smoothly if it’s running and connected to the virtual machine.
>
> Please help - maybe someone has had similar problem or knows some WinDbg
> features that might somehow affect the driver…
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

Sorry Mark, but:

  1. How then the driver installs correctly when WinDbg is running on the host PC?
  2. This way we will need to install the cert on each of our clients computers? But we’ve never done this before - our clients have always installed our other drivers just by making simple steps with SYS, INF, DLL, CAT.

xxxxx@inbox.ru wrote:

I have a strange problem that is somehow connected to WinGbg so I thought to post here about it.

We test a driver on a virtual machine with Win 7 x64 and VMware Workstation.
When WinDbg is started and rests on a COM port pipe, the driver installs smoothly on the virtual machine.
But when I try to install a signed driver on the virtual machine without WinDbg running and attached, I get this error: http://screencast.com/t/IYd3ezTCnww

It reads as Windows is unable to verify a digital signature of the driver.

But I have signed the driver with a DigiCert valid certificate and their utility and the process has completed correctly. But after the installation, the icon marked with yellow exclamation mark appears on a driver item in the Device Manager and the device properties read as the driver is unproperly signed - error 52.

We do every operation on Windows 7 x64 Service Pack 1: http://screencast.com/t/2HVY7gZYHQs0

  1. We build the driver project using WDK 7600.16385.1: http://screencast.com/t/22VpFGWr4gh

Here is the screencast video: http://screencast.com/t/gCukl8j4oQ1

  1. We add “WdfCoInstaller01009.dll” to our output.

  2. We sign a driver binary UemPcSc.sys using DigiCert tool

Why would you use the DigiCert tool instead of the Microsoft “signtool”
command that everyone else uses? Does the DigiCert tool understand how
to do the required cross-certificates? Does Signtool show that your
signature is valid?

signtool verify /v /kp UemPcSc.sys

In order for the signature to be valid, the chain must end with the
Microsoft Code Verification Root.

(When the kernel debugger is running, certificate enforcement is disabled.)


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

This error maybe caused by the algorithm you used to code signing is SHA-1. The use of SHA-1 as a hashing algorithm for signing purposes has been discouraged and is no longer a best practice, and Microsoft does NOT support for SHA-1 hashing algorithm from 1 Jan 2016. Microsoft recommends using the SHA-2 hashing algorithm instead.

Microsoft does NOT support for SHA-1 hashing algorithm on Windows 7 and Windows Server 2008R2.
To support for SHA-2 as a hashing algorithm, you must install hotfixs: KB3035131 and KB3033929 on Windows 7 SP1 or Windows Server 2008 R2.

Tim,

Thank you for your response.

I use WinDDK because it supports XP, but Visual Studio 2013 + WDK 8.1 don’t.

But I have deliberately copied the project to Visual Studio in order to test it’s code signing features with our Win 7 x 64 virtual machine.

Alas, the same thing here - error 52 when installing the driver.

Regarding the sertificate chain, please note that it is not WHQL-certified driver.

Here is what the checks show:

VS2013+WDK8.1 version:
http://screencast.com/t/HPJ0iYtJun2P
Is reads “The cert is actual”: http://screencast.com/t/ZsP1SdfBH8ev
Signtool output: http://screencast.com/t/CuGREojbmuI9

WinDDK 7600 version:
http://screencast.com/t/aBvw74iziRt
Is reads “The cert is actual”: http://screencast.com/t/v3YdwpALxMKv
Signtool output: http://screencast.com/t/2b6btCg5

Yawei, thank you for your response.

I’ve tried to install the hotfixes you’ve posted on the machine where I do the driver signing, but it fails with a message saying that the fix is already installed: http://screencast.com/t/laJ7K6YXOOUh

Hmm, I believe I have to somehow make our DigiCert signing tool as well as Visual Studio 2013 + WDK 8.1 signing tool do SHA-2.

When I look at DigiCert cert chain, I can see strange picture:

  1. Our driver’s cert is SHA256: http://screencast.com/t/LcBqFBE39jQ
  2. DigiCert SHA2 High Assurance Code signing CA is SHA256: http://screencast.com/t/duz53jg7
  3. However the top level Digicert root cert is SHA1: http://screencast.com/t/hdimNCMawvGH

Can it be that the Windows cert checker goes through all the chain up to the top level and fails because the top cert is not SHA256 as well?

according to your screenshot, the hashing algorithm you used to code signing is SHA-1. it may be cause d by your code signing script. If you use signtool.exe to signing code, it need /fd Sha256 to set hashing algorithm because sha1 is the default value.

I just did as you say using the cross-certificate:

  1. sign.bat:

signtool sign /v /ac “.\Signing\DigiCert High Assurance EV Root CA.crt” /f “.\Signing\MicroEM CJSC.pfx” /p ****** /fd SHA256 /t http://timestamp.digicert.com “.%1\uempcsc.sys”
pause
signtool verify /kp /v “.%1\uempcsc.sys”
pause
inf2cat /driver:“.%1” /OS:%2
pause
signtool sign /v /ac “.\Signing\DigiCert High Assurance EV Root CA.crt” /f “.\Signing\MicroEM CJSC.pfx” /p ****** /fd SHA256 /t http://timestamp.digicert.com “.%1\uempcsc.cat”
pause
signtool verify /kp /v “.%1\uempcsc.cat”
pause
signtool verify /kp /v /c “.%1\uempcsc.cat” “.%1\uempcsc.sys”
pause

  1. objchk_win7_amd64.bat:

build -cZ
pause
copy .\WdfCoInstaller01009.dll .\objchk_win7_amd64\amd64
pause
sign.bat \objchk_win7_amd64\amd64 7_x64

Is builds, signs and verifies without any error, but it still causes error 52 when I try to install it on a virtual PC.
When I open binary cert properties, it still doesn’t show the complete pass to Microsoft: http://screencast.com/t/iDbzWFglL5J

What could be wrong with this?

BTW here a verification log:

Cross certificate chain (using machine store):
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 16:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: DigiCert High Assurance EV Root CA
Issued by: Microsoft Code Verification Root
Expires: Thu Apr 15 22:55:33 2021
SHA1 hash: 2F2513AF3992DB0A3F79709FF8143B3F7BD2D143
Issued to: DigiCert SHA2 High Assurance Code Signing CA
Issued by: DigiCert High Assurance EV Root CA
Expires: Sun Oct 22 15:00:00 2028
SHA1 hash: F7E0F449F1A2594F88856C0758F8E6F627E5F5A2

Issued to: MicroEM CJSC
Issued by: DigiCert SHA2 High Assurance Code Signing CA
Expires: Tue Dec 06 15:00:00 2016
SHA1 hash: DB99B2DF1FD13DCC876128FF3829A558D8AB7B9E

Dear all,

The driver generated with the script above only didn’t install on a single Windows 7 x64 virtual machine.

On other x64 PCs and virtual machines it now runs correctly.

I don’t know which thing caused the healing: moving to SHA256 or adding cross-signing or both.

So I’d like to thank everyone for your valuable suggestions!

And redardind the forum topic, this Tim’s advise has also been very helpful: “When the kernel debugger is running, certificate enforcement is disabled.” Thank you Tim and Yawei.

xxxxx@inbox.ru wrote:

I use WinDDK because it supports XP, but Visual Studio 2013 + WDK 8.1 don’t.

But I have deliberately copied the project to Visual Studio in order to test it’s code signing features with our Win 7 x 64 virtual machine.

Alas, the same thing here - error 52 when installing the driver.

Regarding the sertificate chain, please note that it is not WHQL-certified driver.

That doesn’t matter. The “signtool verify” output shows that everything
seems to be OK in both cases. My next guess is that you aren’t really
getting this driver copied to C:\Windows\System32\Drivers. How,
exactly, are you installing your driver? If you managed to get an old
driver in the Driver Store, for example, maybe you’re not getting it
updated. If you do a “dir C:\Windows\System32\Drivers\UemPcSc.sys”, do
the time and size match what you expect?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim, please read my previous post - the problem is solved by adding SHA256 and cross-signing.
The last problem with a virtual machine has also been solved by applying “hotfixes: KB3035131 and KB3033929 on Windows 7 SP1 or Windows Server 2008 R2.” as Yawei has suggested (thanks again, Yawei).