Prev: Character that can be used for DeviceDesc
Next: Build fails with DDK 7600, OK with 6001.18002
From: DWinters on 19 Mar 2010 15:49
In expanding our drivers to support Windows Seven 64-bit, we've run into a
snag, with error code 52. We're currently using a minimal .INF to try to get
one card working in just this environment, and once it works we'll expand it
for the other 100+ products and combine it with our 32-bit .INF.

We have a certificate based on the VeriSign Class 3 Code Signing 2009-2 CA.
We build the .SYS, sign the .SYS, make a .CAT with INF2CAT, then sign the
..CAT. Previous (failed) driver versions are removed by uninstalling via
Device Manager, and checking the checkbox to delete driver files. Driver
installation starts out well, asks if we want to trust ourselves, and does
not show the red dialog, but ends with a Code 52 failure message, saying
something unspecific in the driver package isn't signed properly and warning
that this may be the result of an attack.

Installing the certificate in the Trusted Root Certification Authorities
store doesn't appear to change anything, so we don't think it's a problem
with the certificate itself. Performing the build/sign/INF2CAT/sign steps
from Windows Seven 64-bit doesn't appear to change anything, so we don't
think it's a format problem. Our leading hypothesis is that there's an
additional signing step needed; does Code 52 correspond to a more specific
failure of signing than its message indicates? Is there a step noticeably
missing?
From: Maxim S. Shatskih on 20 Mar 2010 07:23
> In expanding our drivers to support Windows Seven 64-bit, we've run into a
> snag, with error code 52.

What will setupapi.dev.log say?

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

 | 
Pages: 1
Prev: Character that can be used for DeviceDesc
Next: Build fails with DDK 7600, OK with 6001.18002