Tell us your problem!  We can usually fix it. Signing Windows 8 Drivers

Last update: 02-Feb-2016

Getting drivers to work with Windows 7 was occasionally problematic if the driver was not signed, but there was an option to ignore it and install anyway. According to Microsoft, a driver that works with Windows 7 will work with Windows 8, SO LONG as it's signed with a valid Security Certificate.

What's not immediately clear with Windows 8 is that an unsigned 32 bit Windows 7 driver may (but probably will not) load, and an unsigned 64 bit driver definitely will not . The usual error is a message that the installation failed, or that an unnamed file cannot be found. These error messages are particularly unhelpful and don't accurately reflect the cause of the failure.

It was possible to get unsigned drivers to load in the Windows 8 Consumer Preview, but this capability has been removed in the production release versions.

The result is lots of people who upgrade to Windows 8 now have otherwise perfectly functional hardware gadgets that can't be used. In many cases, these are older devices that are no longer supported by the manufacturer.

Complicating the issue further is that the utilities needed to sort this out are not included with Windows, and requires the Windows Driver Kits (W7 DDK and WDK8) to be downloaded to acquire them. How these utilities are used is often incomprehensible to the average user, and even for a while to developers like us.

Driver Signing Summary

A driver installation kit consists of various SYS, DLL and other files, plus an INF and CAT file.

The INF file is the set of instructions that the driver install software (an installer, Device Manager, dpinst.exe and several others) uses. The content of an INF file is often quite obscure, and the details are not in any sequential order.  See   for a discussion of the INF internal sections and keywords.

The CAT file is a binary that's generated from the INF file, and it's intent is to ensure that the INF file has not been tampered with or is otherwise invalid. The CAT file, once created, is then also processed (i.e. signed) with a Security Certificate that adds additional information that has to chain back to a Trusted Root Security Provider.

In Windows 7, it was possible to edit the INF file to correct or update the installation, and the CAT file could be ignored. In fact this is what we did to initially support our Endoscope-1 and Endoscope-2 products.

What happens when you attempt to install a driver in Windows 8?

The installing utility locates the INF file and does the following:

  1. Checks the content (this is the DriverPackagePreinstall phase) to see if it's valid. Errors often occur here on older driver packages.
  2. Compares the INF content hash code to the information in the CAT file. If it does not match, the installation fails.
  3. Reads the Security Certificate in the CAT file, follows the certificate chain and looks in the local Windows Certificate Store for a Trusted Root Certificate. If it does not find a Trusted Root Certificate, the installation fails.

The upshot of all this is that if you want to ship signed drivers that work on all versions of Windows 8 and later, and have backwards compatibility with Windows 7, you need to purchase a Driver Signing Certificate.

If you want to purchase a Driver Signing Certificate, check around for prices. Verisign want $499/year, Godaddy want $199/year. We purchased the GoDaddy product, because there's no functional difference in the Certificates, and price was important.

Signing Project Summary, and a Thank You!

We had a lot of difficulty with the GoDaddy Certificate, as for several days everything we tried resulted in an error informing us that the Godaddy Certificate was not trusted. It sure looked to us that GoDaddy was selling a product that could not be used. GoDaddy Support was always polite if not always helpful, but in the end we finally got on to someone who really understood the issues, and was able to point out where the problem was located. So, thank you GoDaddy Support for your help. The problem and the solution are described below.

Step #1 Get the latest Trusted Root Certificates

Locate "Update for Root Certificates For Windows XP [December 2012] (KB931125)"

Here's the current link :

This also works on Windows 8. The Microsoft Overview states...

"This item updates the list of root certificates on your computer to the list that is accepted by Microsoft as part of the Microsoft Root Certificate Program. Adding additional root certificates to your computer enables you to use Extended Validation (EV) certificates in Internet Explorer, a greater range of security enhanced Web browsing, encrypted e-mail, and security enhanced code delivery. After you install this item, you may have to restart your computer. Once you have installed this item, it cannot be removed."

Well, actually, any Certificate, including a Root Certificate can be removed if need be, see below.

See   Overview of Digital Signatures for Driver Installation (Windows Drivers)   for more information.


What utilities do you need to sign a driver?

The WDK8 package is the one to get as the required utilities are the latest versions and have more argument options than the Win 7 DDK utilities of the same names. Note that WDK8 needs Visual Studio 2012 to be installed first, otherwise all the necessary utilities are not installed. 

There are x86 and x64 versions of the following files.

Inf2Cat.exe is used to create a CAT file that is compatible with the desired versions of Windows. Note that the Inf2Cat from the Windows 7 DDK does not support making CAT files targeted for Windows 8. Inf2Cat also performs a signability test on the INF file, and reports any errors.

MakeCert.exe is used only for testing a driver prior to release.


This uses your Driver Signing Certificate to modify the CAT file, is the most used, and is also the most confusing to use.


Used for examining the Certificate Store and checking your Windows 8 System for a Trusted Root Certificate.

Windows comes with a small number of Trusted Root Certificates from various providers pre-installed. There seems to be more in Windows 7 than in Windows 8. For example, in Windows 7, Verisign and GoDaddy certificates are present, but not in the Windows 8 PC we used for testing.

A Driver Signing Certificate chains back to a Trusted Root Certificate, and this Root has to be loaded on to your target system.

In an ADMIN CMD console, run CertMgr.  The same presentation can be obtained using IE9, Tools:Content:Certificates, or running the Windows Management Console app certmgr.msc .

In the Root tab, locate the Root for your Driver Signing Certificate.

Can't I make a self-signing Certificate with MakeCert?

Yes, for testing purposes only on your PC, but you still won't have Trusted Root Certificate status, and drivers won't load on other Windows 8 systems.


Ensure that when the driver is signed you use the Timestamp, as this indicates that the Security Certificate was valid at the time of signing, and the driver will remain usable even after the Security Certificate expires. If time stamping is not used, the driver (and its device) will not usable after the Certificate expiry date.

Note that there are Code Signing Certificates and Driver Signing Certificates. These are very similar, with the main difference being that a Code Certificate cannot be used with SYS files, while a Driver Certificate can. The second difference is that a Code Certificate can be encoded with SHA1 or SHA2 (actually SHA256) while a Driver certificate is apparently required by Microsoft to be encoded as SHA2 only.

It is possible to use a SHA2 certificate to sign a file SHA1 using SignTool arguments. More on this below.

The Signing Process:

Let's assume that you have your Driver Signing Certificate and it's been installed into the Certificate Manager. Your Certificate will have been assigned a name (usually your company or business name). Here we'll use "PiXCL Auto Tech", and this is located in the Personal tab (also referred to as the "MY" tab in command args) of the Certificate Manager (see the above screen shot).

It's preferable to move all your driver files into a new directory tree for development testing. We found that a memory stick was ideal for this as it could be moved to different test PCs. If your driver is defined in MyGadget.INF, rename it to MyGadgetW8.INF so there is no confusion. The existing CAT file will be overwritten.

Step #1: Update the INF contents using Notepad, Visual Studio or similar.

This should include 

CatalogFile =


CatalogFile =

Next, create the CAT file to be compatible with all desired versions of X86 and X64 Windows.

Inf2Cat /driver: "directory" /os:XP_X86,Vista_X86,Vista_X64,7_X86,7_X64,8_X86,8_X64

where "directory" is where the INF(s) that define your device are located. A driver package can have multiple INF files: an example is a USB composite device that calls a secondary INF. This directory is also where the CAT files are created.

If all goes well, no errors will be reported. The usual errors will be issues within the INF syntax, such as obsolete key words and sections.

At this point, the binary CAT file is not signed, but includes hash values for the INF content and the various files referenced. Note here that Inf2Cat does check if referenced files are actually present, but will not generate an error if a file is not present.

If ANY changes are made to the INF from now on, you have to make a new CAT file.

Step #2: Sign the CAT file SHA1 with SignTool, for Windows 7

This is the stage that causes a LOT of grief and aggravation.

It is ABSOLUTELY VITAL that at this point you do not make ANY changes to ANY file whatsoever in the driver package. This includes text files, INI files, Icons or other images. The CAT file creation process generates hash values for all the files in the package. Suppose, for example, you make a minor update to an INI file. The signing will still occur, and you may not see any errors, but when you go to install the driver, Windows will refuse to install it.

SignTool has numerous arguments, and they all have to be right.

SignTool sign /s MY /n "PiXCL Auto Tech" /ac "mscvr-cross-gdroot-g2.crt" /fd sha1 /t "path\"

Let's look at the arguments specified.

 /s MY /n "PiXCL Auto Tech"  Both are required and locate the certificate named "PiXCL Auto Tech" in the MY (i.e. Personal ) store. If you leave out the /s MY, the CAT won't sign properly.
 /ac "mscvr-cross-gdroot-g2.crt"  Use this specific Microsoft Cross Certificate to ensure that the certification chain is complete.
 /fd sha1  sign the CAT file using SHA1 encoding. This is the default and in theory can be omitted. In practice it does seem to be required. What's unclear is how SignTool converts or uses a SHA2 certificate to sign SHA1, but this command sequence does work. 
 /t  Get the timestamp from this URL. There are others that can be used as well.
 "path\"  Sign this file. If your driver package has multiple CAT files, run this command again with the secondary CAT filename.

If all goes well, no errors will be reported. If so, add the /v and /debug switches anywhere before the "path\"

SignTool writes the binary signature into the binary CAT file.


Step #3: Verify that the signing was successful.

This is the part where certificate errors will usually appear. If your driver has any SYS files (and it usually will) the /kp switch is the one to use.

SignTool verify /v /kp  /debug /a  "path\"

Here's an example. A discussion follows.

 Verifying: ..\W8 Installation Disk Set\
Unable to verify this file using a catalog.
Hash of file (sha1): 792F7BA176E3DBDDB4476AF209BF91225B6175ED

Signing Certificate Chain:
    Issued to: Go Daddy Class 2 Certification Authority
    Issued by: Go Daddy Class 2 Certification Authority
    Expires:   Thu Jun 29 12:06:20 2034
    SHA1 hash: 2796BAE63F1801E277261BA0D77770028F20EEE4

        Issued to: Go Daddy Root Certificate Authority - G2
        Issued by: Go Daddy Class 2 Certification Authority
        Expires:   Sat May 03 02:00:00 2031
        SHA1 hash: 841D4A9FC9D3B2F0CA5FAB95525AB2066ACF8322

            Issued to: Go Daddy Secure Certificate Authority - G2
            Issued by: Go Daddy Root Certificate Authority - G2
            Expires:   Sat May 03 02:00:00 2031
            SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

                Issued to: PiXCL Automation Technologies Inc
                Issued by: Go Daddy Secure Certificate Authority - G2
                Expires:   Fri Feb 21 13:06:08 2015
                SHA1 hash: 63ED61BA943A040B901A3ECE091E47F1A7BE3C16

The signature is timestamped: Wed Mar 06 09:15:34 2013
Timestamp Verified by:
    Issued to: Starfield Services Root Certificate Authority
    Issued by: Starfield Services Root Certificate Authority
    Expires:   Mon Dec 31 18:59:59 2029
    SHA1 hash: 5D003860F002ED829DEAA41868F788186D62127F

        Issued to: Starfield Services Timestamp Authority
        Issued by: Starfield Services Root Certificate Authority
        Expires:   Wed Apr 26 02:00:00 2017
        SHA1 hash: AEAC793CDD107ACFB314A2FE384A8F16840B7C26

Cross Certificate Chain:
    Issued to: Microsoft Code Verification Root
    Issued by: Microsoft Code Verification Root
    Expires:   Sat Nov 01 08:54:03 2025
    SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

        Issued to: Go Daddy Root Certificate Authority - G2
        Issued by: Microsoft Code Verification Root
        Expires:   Thu Apr 15 15:07:40 2021
        SHA1 hash: 842C5CB34B73BBC5ED8564BDEDA786967D7B42EF

            Issued to: Go Daddy Secure Certificate Authority - G2
            Issued by: Go Daddy Root Certificate Authority - G2
            Expires:   Sat May 03 02:00:00 2031
            SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

                Issued to: PiXCL Automation Technologies Inc
                Issued by: Go Daddy Secure Certificate Authority - G2
                Expires:   Fri Feb 21 13:06:08 2015
                SHA1 hash: 63ED61BA943A040B901A3ECE091E47F1A7BE3C16

Successfully verified: ..\W8 Installation Disk Set\

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

Unable to verify this file using a catalog.

This looks like an error, but it actually is not, and can be ignored.

Signing Certificate Chain:

The top entry here should list the Certificate Provider, in this case, GoDaddy.

 Cross Certificate Chain:

This is the important one. The top entry (in green) MUST be Microsoft Code Verification Root. If it is not, or you have a message about an untrusted Root, either your SignTool command is incorrect, or the cross certificate is not present or invalid, or both.


Step #4: Sign the CAT file again SHA2 with SignTool for Windows 8

SignTool sign /s MY /n "PiXCL Auto Tech" /ac "mscvr-cross-gdroot-g2.crt" /fd sha256
     /sha1 <thumbprint>  /t "path\"

The args are very similar to the first, so we'll just describe the new ones.

 /fd sha256  This instructs SignTool to sign the CAT using SHA256.
 /sha1 <thumbprint>  This is the cerificate thumbprint obtainable from the CertMgr, of your Driver Signing Certificate. You will have to remove the spaces between hex values to make a single string. This is encoded with the SHA1 algorithm, and should not be confused with the Signature Hash Algorithm which is SHA256.

Step #5: Test the installation on a 64-bit Windows 7 PC.

Here's what you should see.


Windows has identified your Driver Signing Certificate, and asks you (and your users) to trust your company.

Windows is doing its best to install everything in your driver package. Give it time...

Whoopee! The signed driver package has installed without errors.

The next item on your TODO list is test this driver on other PCs. Note that your Driver Signing Certificate does NOT have to be present on the target system. This is handled in the certificate chain back to a Trusted Root Provider.


When things go wrong, and the error message is unhelpful.

This is the window you don't want to see, and if you do, it's because the driver package is faulty in some way.

It's completely unclear what an "interactive window station" might actually be (I thought my PC was interactive),  or for what reason it is required. Fortunately, we do have a set of clues.

The C:\Windows\inf\ file:

All device installations copiously log the process into this file which can be read using Notepad or similar. You can delete this at any time, and it's recommended to do so before you start the test installation.

If the installation does not succeed, look in the log file. All warnings and errors start with the ! character.

Errors start with !!!

These are the ones to deal with first. The error that caused us so much grief was INF references to a file removed from the installation build. The missing file error propagated up to a Trust Provider Error.

Some warnings, like this, can be ignored. The driver installer fixes this automatically.

! inf: Detected INFCACHE inconsistency
! inf: Attempting INFCACHE repair 14:13:11.054
! inf: Verify/Fix on INFCACHE complete, status(4) - Fixed 14:13:48.836

A Warning like this next one looks bad, but can also be ignored.

!    sig:                     VerifyTrustFailed for C:\Windows\LancerProject\PAP7501\GUCI_AVS.ini.
!    sig:                     Error 0x800b0109: A certificate chain processed, but terminated in a root certificate
                                 which is not trusted by the trust provider.


When the driver install is REALLY messed up on a target system...

Getting the driver to sign correctly can result in failure residues that have to be manually removed. During our learning process several failed installs eventually resulted in a driver installing correctly, but when we tried to access the device, Windows crashed.

When a driver is installed, there are multiple files created that may have to be removed manually.

In C:\Windows\inf

The install process takes your INF and makes a copy named OEMnn.INF, where "nn" is a number. This new INF is also processed to make OEMnn.PNF. Use Explorer or Visual Studio Search to locate all OEM*.INF containing something e.g. your company name. Delete these and the corresponding PNF.

In C:\Windows\system32\CatRoot\{F750E6C3-38EE-11D1-00C04FC295EE}

This is the Catalog Database directory. Entries here can be removed with the SignTool catdb command, but you may need to do it manually as well.

Device Manager provides a clue here. If you ask it to load a driver and you Select from a Device Class, you will often see multiple instances of your device. This happens because multiples have been loaded into the Catalog Database and are read by Device Manager.

In C:\Windows\System32\DriverStore\FileRepository

There can be multiple copies of driver files here.

In C:\Windows\System32

A failed install may write SYS and other files here. It may be desirable to manually delete them. 


If you spot an error or omission in this page, or have a clarification, please do email us .

Like us on Facebook.

Since you are here, do please have a look around the rest of our website.

Copyright 2005-2015 PiXCL Automation Technologies Inc, Canada. All Rights Reserved.