Windows 10 Driver Publishing Workflow

Publication restrictions

The Windows Hardware Dashboard enforces publication restrictions. Publication restrictions ensure that partners cannot publish drivers for Microsoft class or generic bus HWID strings, and that devices do not receive incorrect drivers due to generic third party or re-used HWIDs.

Microsoft allows exceptions to these rules at its discretion on a case-by-case basis. Partners can escalate these cases to [e-mail].

Examples of these blocks include, but are not limited to the list in Table .

Table : Driver Publication Restrictions

Type of block	Additional information
Invalid driver submission category types	UNCLASSIFIED
Invalid Architecture	ia64
HWIDs with no bus enumerator	N/A
Invalid bus enumerators	ActivCardBus CIRCLASS Hid\irdevice Irbus PS2_ MIDI PNP ACP IAN AVM STREAM DISPLAY
Classcode declarations	\CLASS \CC \&
Two-part HWIDs	Enforced on HDAUDIO bus
Bluetooth HWIDs with service UUIDs and no vendor ID or product ID	N/A
Invalid PCI Vendor Codes	0000 FFFF
Missing device codes or product ID codes	Enforced on PCI and USB buses
Invalid HWID string beginnings	HID_DEVI SERIAL_M ISAPNP\PNP SERENUM\PNP *PNP BIOS\PNP ACPI\PNP
System reserved HWIDs	BIOS\PNP ACPI\PNP
Invalid HWIDs	*DONTUSE SERIAL_MOUSE Root\circlass Hid\irdevice

5. Firmware Update support for systems

   1. UEFI Firmware UpdateCapsule Support

To accommodate updating system firmware on UEFI systems, Windows provides UpdateCapsule support. This support provides a method for OEMs to distribute and update their UEFI system firmware by encapsulating a firmware update blob into a Windows driver package. The end to end publishing workflow treats this driver package no different than any other driver package.

Once the firmware update driver package has been distributed and installed on a given system it is applied during the next boot cycle of the PC. Details on this UpdateCapsule functionality are outlined in the Windows UEFI Firmware Update Platform whitepaper:

http://www.microsoft.com/en-us/download/details.aspx?id=38405

This UpdateCapsule functionality is being added to the Mobile SKU as an alternative to the traditional Phone model of updating system firmware for scenarios where the Phone model is not sufficient. Microsoft recommends utilizing the standard mobile/phone firmware update model to take benefit of the offline servicing model and built-in recovery support. On the Mobile SKU UpdateCapsule should only be used if the standard mobile/phone firmware update process is not tenable.

1. Publishing an UpdateCapsule:

Historically (since the release of Windows 8) UpdateCapsules were distributed solely as part of a Model Based Servicing (MBS) set. MBS provided 2 features which were needed for firmware updates:

1. 
   Dependency Mapping
   This was a way to map dependencies between drivers and/or firmware so that they were serviced as a set. In other words all drivers/firmware were updated at the same time avoiding torn states where different versions of the components were used resulting in unexpected behaviors.
   
2. 
   Distribution Targeting
   This was a method used to ensure that the drivers and firmware in an MBS set were distributed to the expected systems. This prevented customized drivers from being distributed to the wrong system even if the hardware IDs matched.
   This is the same distribution targeting described in List .
   

In Windows 10 we are enabling the publishing of a ​single driver (or firmware UpdateCapsule) using distribution targeting (#2 above) without having to be part of an MBS driver set. The workflow will rely on ComputerIDs (what some people call computer hardware IDs or CHID). These are the identifiers used to target MBS sets to a particular system. They are also used by hardware vendors to map computer metadata such as icons and other assets for display in the Devices and Printers folder (as well as Device Stage). Refer to the following MSDN article for more details:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff552325(v=vs.85).aspx

UpdateCapsule driver packages published outside of an MBS driver set must specify the list of computer IDs that the firmware is applicable to in its driver INF [TargetComputers] section. This prevents the firmware from accidentally being installed on an incorrect system. [TargetComputers] is a new INF directive for Windows 10.

Such a firmware update driver package can be submitted to the DevCenter Dashboard for signing and publishing through Windows Update.

Note that the actual system firmware implementation of the UEFI UpdateCapsule() must validate that a given capsule is indeed appropriate for the machine. With this validation the use of [TargetComputers] is unnecessary. Therefore [TargetComputers] is redundant, but permitted.

2. Validating Firmware Update Capsules

Exactly how a firmware update capsule functions is up to the firmware vendor. As outlined in the Windows Firmware Update Platform whitepaper the capsule could be an entire UEFI implementation, just the difference in files, an actual UEFI based setup application or something else altogether. How it is implemented is defined by the firmware vendor.

Windows provides everything else: discovery of a firmware resource on a Windows system, fetching updated firmware from Windows Update, preparing the system for updating then delivering the update capsule binary image into the firmware vendor’s UEFI UpdateCapsule() method. Once the firmware has been properly updated Windows also provides the follow up reporting and checking for update errors.

The overview on how to validate successful capsule implementation is available on the following whitepaper:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn972665%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

6. Driver publishing FAQ

1. 
   Why did my Driver Signing submission fail?
   

The requirement for Driver Signing is that the driver files must be submitted in cabinet file (CAB) format, detailed here:

https://msdn.microsoft.com/en-us/library/windows/hardware/dn962252(v=vs.85).aspx

The cabarc.exe tool lets you to create the correct format. The key is to make sure that the folder path that contains the driver is included in the cabinet file as well.

For example, if your driver package looks like this:

C:\Desktop

\DriverFolderOne

Driver.inf

Driver.sys

The corresponding cabarc command would be (executing from C:\Desktop):

Cabarc –p –r N .cab DriverFolderOne\*

…where the “-p” parameter ensures the preservation of the file path.

By following this format, the CAB file for submission will be properly formatted. You can confirm the path was preserved in the CAB file by opening the cab in Windows Explorer and switching View to Details. There will be a Path column which should not be empty.

2. 
   Are the Resell and Driver Update Acceptable scenarios supported with Driver Signing?
   

No, the Resell and Driver Update Acceptable scenarios are not supported for the Driver Signing process. These scenarios are only supported for the HLK process.

Partners can hand their properly-formatted CAB file to another partner to use for a Driver Signing submissions, effectively completing the Resell scenario. Partners can also modify INFs, re-create the CAB file, and submit for Driver Signing again, thereby completing the Driver Update Acceptable scenario.

3. 
   There is a blank web page displayed during the process. Why?
   

Please turn off compatibility view in Internet Explorer for Microsoft.com.

4. 
   Is there any dependency to SKU (Enterprise, Pro, Home) to have drivers delivered from Windows Update?
   

No, there is no dependency on SKU for Windows Update to deliver drivers.

5. 
   Is there any requirement for FeatureScore format?
   

FeatureScore must be defined in the INF by using one of the following formats:

dd

0xdd

… where d is a single hexadecimal digit. The submission will fail if one of the proper formats is not followed.

6. 
   For resold driver, is there any Parent-Child dependency when publishing a driver to Windows Update?
   

Parent and Child submissions are treated independently. Once the submission is approved, a partner can resell the driver to the other partner. Once the other partner accepts the resold driver, they can publish the driver independent from the parent submission status.

7. 
   A CHID targeted driver is on Windows Update, but the driver is not updated after running Windows Update. Why?
   

In Windows 10, a driver published on Windows Update is treated as optional. This means that driver will only be updated on two conditions:

• 
  Missing driver: If there’s no driver installed, Windows Update pulls the best driver available then installs it.
  
• 
  Update driver: If the driver already installed, in order to pull the driver from Windows Update, the user must to go to Device Manager, select the driver, and then click Update Driver. This will trigger Windows Update to find the best available driver in their pool.
  

8. 
   Is there a tool to view the list of which driver has CHID targeting to what device?
   

A partner can build the tool to view the list by using Windows Update APIs. Details is here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387287(v=vs.85).aspx

9. 
   Distribution status says “locked.” What does this mean?
   

A HWID and OS pair will be shown as locked when it is already involved in a publication action. It will be released and available for publication when all pending actions have completed.

7. Document Revision History

1. November 2014 – Initial Release

2. January 2015 Update

• 
  Change: Windows Update Preview moved to post Windows 10 release
  
• 
  Change: Distribution Targeting support moved to Windows 10 release
  
• 
  Updated: Features in both WinHEC and release releases
  
• 
  Add: Initial Distribution Ramp Up feature
  
• 
  Formatted: Features of Long-term Workflow
  
• 
  Added details: Features of Long-term Workflow
  
• 
  Change: workflows (and diagrams) based on updated timelines
  
• 
  Change: Publishing policy (Missing Driver only)
  
• 
  Change: Publishing policy (AutoUpdate is by request and goes through DDCHelp)
  
• 
  Emphasis: Driver submitted to Windows Update/Windows Update Preview must be release ready (fully tested)
  
• 
  Added: CHIDs are case sensitive
  

1. April 2015 Update

• 
  Changed details about ComputerHardwareIds.exe
  
  • 
    Default Behavior
    
  • 
    Simulation Behavior
    
• 
  Updated details about Driver Targeting
  
  • 
    Included information on resell and Driver Update Acceptable scenarios
    
• 
  Included Windows 10 CHID hierarchy with new CHIDs
  
  • 
    Five new CHIDs include Baseboard Manufacturer and Baseboard Product information
    
• 
  Updated scenarios
  
  • 
    Added resell and resell + Driver Update Acceptable scenarios
    
• 
  Added details on Windows Update distribution for Distribution Targeting and Installation Targeting
  
• 
  Added details on [TargetComputers] INF section
  
• 
  Added details on Publication Restrictions
  
• 
  Updated Implementation Timeline
  

1. May - June 2015 Upadate

• 
  Added details on firmware updates. including reference to a firmware update validation whitepaper.
  

• 
  Added tables to Examples
  
• 
  Added FAQ section
  

.

© 2015 Microsoft. All rights reserved.