Removing Co-installers from Driver Packages
Caution
Starting in January 2023, driver packages containing a co-installer are no longer signed by the Hardware Developer Center portal. For details of the requirement, please refer to Windows Hardware Compatibility Program Specifications and Policies, specifically version 22H2 policies, section Device.DevFund.INF.Declarative.
This page addresses common reasons for co-installers to be present in a driver package, and offers mechanisms to perform the same task without a co-installer.
WDF and WinUSB Co-installers
The WDF co-installer and WinUSB co-installer are not required on any system running Windows 10 and later. The WDF co-installer references can be removed without any additional work. The WinUSB co-installer references can be removed, and WinUSB should be referenced from the driver package INF using the Include and Needs directives.
WinUSB driver package guidance
Installing software that presents user interface
Rather than launching an application during an installation, provide a Universal Windows Platform application that is installed using an AddSoftware directive from a DDInstall.Software section of the driver package INF.
For more information, see Pairing a driver with a Universal Windows Platform (UWP) app. An AddSoftware directive is supported on Windows 10, version 1703 and later versions of Windows.
For additional details, see Installing Associated Software below.
Setting device friendly names
INF File
A driver package INF can set the device friendly name as follows:
[DDInstall.HW]
AddReg = FriendlyName_AddReg
[FriendlyName_AddReg]
HKR,,FriendlyName,, "Device Friendly Name"
Runtime
The friendly name can be set by the driver during the Start IRP or the PrepareHardware phase by setting the DEVPKEY_Device_FriendlyName property with one of the following APIs:
Other device settings/configurations:
When possible, the driver can change the device settings and configuration within the driver Start IRP or the PrepareHardware phase. When modifying state at runtime, the driver should follow the driver package isolation requirements. These requirements contain the guidance on driver configuration and state layout and help future-proof the driver by making it more resilient to external changes, easier to update, and more straightforward to install.
For settings and configuration that cannot be set within the driver itself, a driver package may also include user-mode runtime components that alter the settings and configuration. This can be a user-facing app or a Win32 service that updates the configuration. For info on how to include user-mode software for use with a device, see Using a Component INF File.
If a persistent component such as a service is used, ensure that its functionality is necessary and cannot be performed in a less resource-intensive manner, such as within a driver package INF or within the driver itself. For info on how to ensure that a service only runs when relevant devices are connected, see Service Triggers, Win32 services interacting with devices, and Registering for device interface notifications. The service must also meet the latest requirements, for example passing API Validator.
Installing Associated Software
The 'Componentized' portion of the DCH driver requirements introduced a concept called the SoftwareComponent, which is a mechanism to decouple the install of a device driver from its associated software. When a software component is created by the INF, it will automatically create a child device that maps to the software component. This child device will exist for the purpose of installing the software associated to the parent device. This software can be installed and updated independently of the main device and driver.
Within a SoftwareComponent driver package INF, the recommended mechanism to install software is using an AddSoftware directive. This will trigger the download and installation of software from the Windows Store.
Dependencies across drivers and devices
Device start/enumeration ordering dependencies
To the extent possible, inter-device dependencies or start ordering requirements should be avoided.
For ACPI-enumerated devices, the dependency object (_DEP) may be used in the ACPI firmware to enforce device start ordering. For more info, see Device Management Namespace.
Drivers can respond to the IRP_MN_QUERY_DEVICE_RELATIONS IRP to define relationships between devices, such as removal relations. For more info, see IRP_MN_QUERY_DEVICE_RELATIONS.
Driver package install dependencies
The CopyInf Directive can be used to also install an additional driver package during the same install API call as another driver. The driver package passed to the install API will be installed before any CopyInf-referenced driver packages, but driver packages referenced by CopyInf are not guaranteed to be installed in any particular order.
Configuring components from multiple vendors bundled in single driver package
Driver packages support a type of driver package INF called an extension INF. This is an INF file that is specifically designed to augment and extend the functionality of a "base" driver package INF. An extension may not supply the function driver for the device, but may otherwise use any other directives or write other settings for a device. During a driver installation, a single base driver package INF is selected using driver ranking to provide the functionality for the device, then any extension INFs are selected for the device. For more info, see Using an extension INF file.
A common paradigm for utilizing extension driver package INFs is for the hardware manufacturer to supply the base driver package INF, and for an OEM shipping that part inside a system to create an extension driver package INF that customizes it for that system.
Installing/orchestrating firmware updates
Different firmware update mechanisms are recommended depending on the nature of the device being updated. Each of the following can be used to ship and install a firmware update via Windows Update.
Non-removable
The UEFI firmware update platform is designed to update components of a system that cannot be removed, such as the system firmware. For more info, see UEFI Firmware Update Platform.
Removable
For removable devices such as HID or USB devices, the CFU model allows for safe firmware updates. For more info, see Component Firmware Update.
Custom Implementation
Alternatively, a custom driver can be written that updates the firmware of the device at the driver's discretion. For more info, see Custom Firmware Updating Driver.