Windows 10: Error code 52 in device manager with correct signature in cross-signed driver

Question

we developed a driver and signed the cat and sys file with our company's Verisign signature (SHA1 + SHA256, including certificate chain). We tested it under Windows 7 and 10 both 32 and 64 bit versions. Now we have some random customers that report that our device is not recognized correctly in device manager and that error 52 shows up:

Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)

Setupapi.dev.log shows this error:

_!!! dvi: Device not started: Device has problem: 0x34 (CM_PROB_UNSIGNED_DRIVER), problem status: 0xc0000428

But this message in Setupapi.dev.log is also present at working installations.

Sign tool shows that the signature is valid, same does the properties page on windows explorer.

What is the reason for this behavior?

Answer 1

Potential solutions to this were not dual signing the cat file and checking the root certs of the customer's pcs. I also learned that the error message in setupapi.dev.log is perfectly normal

After some research with a lot of apparently contradictory Microsoft documentation I finally landed at https://docs.microsoft.com/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later- where it says:

"Note: Starting with Windows 10, version 1607, Windows will not load any new kernel mode drivers which are not signed by the Dev Portal.

[...]

Cross-signed drivers are still permitted if any of the following are true:

The PC was upgraded from an earlier release of Windows to Windows 10, version 1607.

Secure Boot is off in the BIOS.

Drivers was signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA."

And it turned out that Secure Boot was enabled on none of our testing machines, but exactly on the customer machines that had the problem.

Now we have to perform a WHQL certification with the driver. Fortunately there are companies which offer this as a service, so we don't have to maintain a certification machine pool.