Updating Device Firmware using Windows Update

Updating Device Firmware using Windows Update
In this topic, we explain how to update a removable or in-chassis device's firmware using the Windows Update (WU) service. See Windows UEFI firmware update platform for information about updating system firmware.
You'll do this by providing a firmware update mechanism implemented as a device driver. If your device uses a vendor-supplied driver, you can add the firmware update logic and payload to the driver, or provide a separate firmware update driver package. A firmware update driver package is required if your device uses a Microsoft driver. A universal firmware update driver package is required in both cases. Getting Started with Windows Drivers provides more information about universal drivers. In addition to KMDF, UMDF 2 and the Windows Driver Model can be used in the driver binary.
Since WU cannot execute software, the firmware update driver must hand the firmware over to Plug and Play (PnP) for installation.

Firmware update driver actions

Typically, the firmware update driver is a lightweight device driver that does the following:
  • At device start or in the driver's EVT_WDF_DRIVER_DEVICE_ADD callback function:


  1. Identify the device to which it is attached.
  2. Check if the driver has a firmware version that is more recent than the one currently flashed on the device hardware.
  3. Set a timer to schedule a firmware update if one is needed.
  4. If not, do nothing until the driver is re-started.


  • During system runtime:


  1. Wait for a set of conditions to be met before submitting an update.
  2. Once the conditions have been met, perform the firmware update.

Afterwards, install the updated drivers.

The firmware update driver package typically includes the following:
  • Universal Driver INF
  • Driver catalog
  • Function driver (.sys or .dll)
  • Firmware update payload binary
Submit your firmware update package as a separate driver submission.

Add firmware update logic to a vendor-supplied driver

As shown in the following diagram, the existing function driver can implement the firmware update mechanism:

Alternatively, if you want to update the function driver and the firmware update driver separately, you can create a second device node on which you will install the firmware update driver. This is shown in the image below:

The hardware IDs for the firmware and function device nodes must be different in this case in order to be targeted separately.
The second device node can be created in several ways. Some devices, such as USB, can expose a second device node on a single physical device. By using this functionality, you can create a device node that is targettable by WU, and install a firmware update driver. A single physical device, however, may not be able to enumerate more than one device node.
Install the driver for the firmware update using an extension INF that specifies the AddComponent directive. Here's an example of how you can do it:
"C++
[Manufacturer]
%Contoso%=Standard,NTamd64
[Standard.NTamd64]
%DeviceName%=Device_Install, PCI\DEVICE_ID
[Device_Install.Components]
AddComponent=ComponentName,,AddComponentSection
[AddComponentSection]
ComponentIDs = ComponentDeviceId"
In the above INF sample, ComponentIDs = ComponentDeviceId indicates that the child device will have a hardware ID of SWC\ComponentDeviceId. The following device hierarchy is created when this INF is installed:

Ensure that the INF and binary files containing the firmware payload are updated for future firmware updates.

Modifying a Microsoft-supplied driver to accommodate firmware updates

You need to create a second device node for devices that use a Microsoft-supplied driver, as shown above.

Best practices

  • Specify DIRID 13 in your firmware update driver INF to cause PnP to leave the files in the driver package in the DriverStore:
"C++
[Firmware_AddReg]
; Store location of firmware payload
HKR,,FirmwareFilename,,"%13%\firmware_payload.bin"
This location is resolved by PnP when it installs the device. The driver can then open this registry key to determine the payload's location.
  • Inf entries should be specified as follows:
C++
Class=Firmware
ClassGuid={f2e7dd72-6468-4e36-b6f1-6488f42c1b52}"
  • A firmware driver should search for another device node by walking the tree relative to itself, not by enumerating all nodes in the tree. The user may have plugged in multiple instances of the device, but the firmware driver should only update the associated device. Typically, the device node to locate is the parent or sibling of the device node on which the firmware driver is installed. When two devices are shown in the diagram above, the firmware update driver can search for a sibling device to find the function driver. Using the diagram above, the firmware driver can find the primary device it needs to communicate with by looking for the parent device.
  • If there are multiple instances of the device on the system, the driver should be robust to multiple firmware versions. There may be one instance of the device that has been connected and updated several times; then a brand new device may be plugged in that has outdated firmware. This means that state (such as the current version) must be stored on the device itself, and not in a global location.
  • If a firmware update method already exists (for example, an executable or co-installer), the update code can be reused to update a UMDF driver.