This post contains instructions on how to get a submission CAB file for kernel-mode device drivers for Windows 10 ready for the Windows Hardware Developers Center Dashboard portal. To increase the security of the Windows platform, since version 1607, having a kernel-mode driver signed by the portal is required. I would recommend following the links under each step to go to the authoritative source and gain a clear picture about how your needs fit into the process. Previously installed device drivers that have not been signed by the portal and were installed on Windows 10 won’t be rejected by the OS if an upgrade to version 1607 occurred after their installation.

Driver Signing changes in Windows 10
Driver Signing changes in Windows 10, version 1607

NOTE: I should say early on that you’ll need an Extended Validation Code Signing Certificate for your company if you don’t already have one. The Microsoft’s Hardware Dev Center help docs contain the requirement details for the certificate.

The following link is a must-read on the proper submission format for the portal. Much of the information there could not be found elsewhere in the same digested format.

Q&A with project director of the MHDCDp

It’s also a good idea to see where we’re headed. Read through the following Driver Signing page on Microsoft’s Hardware Dev Center to see what our end goal is. That is one of the more important links because it shows the submission format that’s necessary for the portal.

At this stage of the driver release process, you should already have your built driver and INF file and have already verified that it’s not going to destroy someone’s system. While the WHDCD portal will run extensive tests against your driver to check if it’s running exploits against known vulnerabilities, during this process you will be signing attestation agreements in which you “attest” to the veracity of the drivers you’re submitting. Consult the details of those agreements to see what you’re responsible for.

The process can be painstaking. There are many details specific to your use case that will make finding a guide to fit your exact needs unlikely. However, included in this post are the links to much of the documentation that one can dig through for help.

Expect your first submission to the portal to be rejected!

Terms and Definitions

  • CAB – Cabinet files, an archive file for Windows that supports lossless file compression and signing (formerly known as Diamond files)
  • INF – a setup configuration file, used with Windows Installer and with installing device drivers
  • CAT – a catalog file, used as a signature for a set of files, has cryptographic hashes/thumbprints
  • DDF – Diamond Directive File, the build configuration file for makecab
  • HSM – Hardware Security Module, typically a USB device that contains the EV code signing certificate as an encrypted token containing the private key
  • EV Code Signing Certificate – An Extended Validation code signing certificate, these require an additional vetting process around the request for the cert. The signature from an EV cert won’t expire when the certificate expires. Typically sent on an HSM. They are recognized by Microsoft SmartScreen. This kind of cert is required for submission to the MHDCDp.
  • HLK – The Windows Hardware Lab Kit, used to test hardware for Windows 10 (contains chkinf, which we’ll use later)

Process Overview

When you have your driver built into a SYS file and your INF file written, we’re going to verify the INF file with chkinf and generate a CAT file using inf2cat that contains cryptographic hashes for each of the driver files in the capsule. We’ll sign the driver with signtool before we package it up into a CAB file, and we’ll create a DDF cabinet-creation directive file to specify how the cabinet should be composed. Finally, we’ll use makecab to create the CAB file and sign the CAB. At this point the driver submission will be ready for the Windows HDCD portal.


Step 1 – Gaining the Certificate
I’ll assume that you’ve got your kernel-mode drivers built and that you’re ready to begin making a submission. You’ll need to discover which type of certificate, standard or EV, you need. However, the EV cert is good for all situations that require a code signing cert for the MHDCDp. To get the latest info on selecting the proper cert by your submission type, check out Microsoft’s Hardware Dev Center Get a code signing certificate article.

Step 2 – Installing the Certificate
Install the EV Code Signing Certificate to your local store. EV code signing certs are often shipped certified mail on a Hardware Security Module. You’ll need this and the private key. Install the cert using the methods outlined from your certificate provider.

Step 3 – Sign your drivers
You can sign the drivers through Visual Studio:

Signing a Driver for Public Release

Or you can just use signtool in an admin command-prompt:

You’ll need to use the Common Name of your certificate. To get this:
1. Open certmgr.msc (Windows Key + R, certmgr.msc,)
2. Find the install location of your cert. It’s more than likely that the certificate installs to the Certificates – Current User > Personal > Certificates store.
3. Right-click the cert name and go to the Details tab.
4. Select from the drop-down list
5. Select the Subject field.
6. Look in the Value box. The Common Name of your certificate starts with ”CN = “.

signtool documentation

Location of the Common Name for the certificate

Step 4 – Install Windows Hardware Lab Kit
Install the Windows HLK (at least version 10)
Download the Windows Hardware Lab Kit

Step 5 – Check the INF for errors
In C:\Program Files (x86)\Windows Kits\10\Tools\x86\ChkInf\ run the chkinf.bat against the INF file. This runs Perl scripts that check the syntax of your INF files before you make a submission to WHQL. You’ll want to run this to save yourself from having your submission rejected for mistakes. After running chkinf an ‘\htm’ folder will be created that contains a summary file of the set of files checked and a detailed summary HTM file per INF file checked. The detailed summary file contains errors by line, warnings, and an annotated version of the INF file that was checked with the errors and warnings inline. The composition of an INF file is beyond the scope of this post, but if you’re troubleshooting chkinf error messages, here’s a link to the documentation.

chkinf documentation

Step 6 – Create the catalog file
We’ll need to create a catalog file for each driver capsule. The CAT file contains cryptographic hashes for a driver’s INF file for a list of Windows versions that we’ll specify. To create the *.CAT catalog files, run the following command depending upon the target architecture (i.e., X86 or X64). You’ll need to add this to your path or run it directly from that folder.

Inf2cat exists in the C:\Program Files (x86)\Windows Kits\10\bin\x86 folder from the Windows HLK install:

inf2cat documentation

Catalog Files and Digital Signatures

Step 7 – Create the DDF file for the submission CAB
Create a *.DDF file (Diamond Directive File) for makecab using a format similar to the following, (e.g., replace <> tags with your own). The DDF specifies cabinet properties, the name of the cab file, and the capsule details (i.e., capsules are the individual drivers and their associated files). The following example is a good starting place.

How to write a makecab directive file (DDF)


Step 8 – Make the submission CAB
Run the makecab command from the directory containing the DDF file
(e.g., from the same directory as the INF, SYS, and CAT files if the directories were written as .\SSDnsInject.inf etc.):

Step 9 – Sign the submission CAB
Run this command in the directory containing the submission *.cab file. You will need the EV code signing certificate Hardware Security Module and the private key (a prompt will appear):

NOTE: /n, The certificate name here must match the Common Name that you see in certmgr.msc (as before) for a certificate installed to the local store.

Step 10 – At the portal
The portal changes often, so the scope of this post won’t extend there.
However, the following should consistently contain the relevant steps for the current form of the portal.

MHDC Dashboard FAQ

Attestation Signing a Kernel Driver for Public Release

Update a code signing certificate

The following legal agreements must be signed in the portal to make submissions by attestation (kernel-mode drivers not involving manufactured hardware):

For attestation submission, the following agreements will need to be signed:

  • Windows Compatibility Program and Driver Quality Attestment Testing Agreement
  • Windows Certification Program Testing Agreement

For submitting for certification, the following agreements will need to be signed:

  • Windows Logo License Agreement For Software
  • Windows Certification Program Testing Agreement

For using the EV Code Signing Certificate with the MHDCD portal:

  • Code Signing Agreement for Extended Validation (EV) Certified Code

Good luck!

Leave a Comment