none
VS2012 "this driver is not digitally signed" error RRS feed

  • Question

  • We have driver kits that we build on "build systems" and "desktop systems".
    The build systems sign the driver with our production certificate and our desktop builds use a test certificate.  The driver package is signed and the driver is kernel-mode code signed.  I build the  driver and driver package on my desktop and install the test certificate on the target system.  Then I use Device Manager to upgrade the driver.  This works fine for *some* desktop systems and for the build system.  The target system is Windows Server 2012.

    When a developer first builds a driver kit, they are prompted for the private key password for the code signing certificate.  We trust VS2012 to properly install the cert in the local stores and it seems to do that properly.

    For a failing driver kit, at upgrade time Device Manager reports:  "This driver is not digitally signed!".
    When I use Explorer to view the kernel-mode code signature on the driver it looks fine.  When I use Explorer to view the catalog file, it also seems to be properly signed.  Explorer reports "The security catalog is valid." , "The digital signature is OK." and when viewing the certificate path it says "This certificate is OK." .

    When I verify the kits with:
       signtool.exe verify /debug <driver.cat>
       signtool.exe verify /debug /kp <driver.sys>

    there is only one error: "SignTool Error:  Signing Cert does not chain to a Microsoft Root Cert." .  I don't think this is an issue because both the working and failing driver kit have this issue.  Also, we have the target system running in "Test Mode".


    I have checked all of the Tags in the driver kit catalog and all of the files have entries for both sha1 and sha256, though the order of the tags is different between the working and failing cases.

    At this point I can't identify what the difference between the two kits is that results in one kit being reported as unsigned.  Both kits are being used on the same target system to upgrade a device.

    Even more interesting - we have have tried 4 driver kits some of which we have built on 5 different desktops, with what should be the same signing.  We use a properties file to set the signing steps so that all projects use the same signing parameters.

    DeskTop        Driver Kit

    JJ        AA-works, BB-works, CC-works
    KK        AA-works, BB-works
    LL        AA-works, BB-fails, CC-fails
    MM        AA-fails
    NN        DD-works

    Any ideas on how I can find out how these driver packages differ?

    I tried using the Windows Event Logging for Code-Integrity, but is did not provide any additional information.

    Thanks,   Jim
    Tuesday, July 30, 2013 5:51 PM

Answers

  • The setupapi.dev.log file shed some light on the issue.  The driver signing is fine.  The kit installs on another system just fine. 

    The issue seems to be with the DriverStore.  We were trying to install a kit that had no change to the *.INF file.  The Device Manager/Upgrade Manager (not sure what the correct term is) was trying to use the OEM28.INF driver kit, which was the previous kit. When we advanced to the next screen in Device Manager even though it complained that the driver was not signed, it then said that it could not find a file.  We tried deleting all references to the OEM28.INF kit but couldn't get the system to stop using the OEM28.INF file.  I was told that a re-build of the driver kit after changing the INF file worked fine.

    • Marked as answer by Jim Developer Friday, August 2, 2013 9:21 PM
    Friday, August 2, 2013 9:20 PM

All replies

  • Did you look at the logs in %windir%\inf\setupapi.dev.log and setupapi.setup.log? Those might have more information about why you're getting the signing error on install.


    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, July 30, 2013 7:06 PM
  • The setupapi.dev.log file shed some light on the issue.  The driver signing is fine.  The kit installs on another system just fine. 

    The issue seems to be with the DriverStore.  We were trying to install a kit that had no change to the *.INF file.  The Device Manager/Upgrade Manager (not sure what the correct term is) was trying to use the OEM28.INF driver kit, which was the previous kit. When we advanced to the next screen in Device Manager even though it complained that the driver was not signed, it then said that it could not find a file.  We tried deleting all references to the OEM28.INF kit but couldn't get the system to stop using the OEM28.INF file.  I was told that a re-build of the driver kit after changing the INF file worked fine.

    • Marked as answer by Jim Developer Friday, August 2, 2013 9:21 PM
    Friday, August 2, 2013 9:20 PM