Getting Started with Universal Windows drivers

Universal Windows drivers enable developers to create a single driver package that runs across multiple device types, from embedded systems to tablets to desktop PCs.

A Universal Windows driver package contains an INF file and binaries that install and run on Universal Windows Platform (UWP)-based editions of Windows 10. They also install and run on other editions of Windows 10 that share a common set of interfaces.

The driver binary can use KMDF, UMDF 2, or the Windows Driver Model (WDM).

A universal driver consists of the following parts:

  • A base driver
  • Optional component packages
  • An optional hardware support app

The base driver contains all the core functionality and shared code. The optional component packages can contain customizations and additional settings.

Typically, a device manufacturer, or independent hardware vendor (IHV), writes the base driver. Then, a system builder, or original equipment manufacturer (OEM), provides any optional component packages.

After the IHV has certified the base driver, it can be deployed on all OEM systems. Because a base driver can be used across all systems that share a hardware part, Microsoft can test the base driver broadly by using Windows Insider driver flighting instead of limiting distribution to specific machines.

The OEM validates only the optional customizations that it provides for the OEM device.

Universal drivers are distributed through Windows Update, and hardware support apps are distributed through Microsoft Store.

Design principles

When you write a universal driver package, there are four design principles to consider:

  • Declarative (D): Install the driver by using only declarative INF directives. Don't include co-installers or RegisterDll functions.

  • Componentized (C): Edition-specific, OEM-specific, and optional customizations to the driver are separate from the base driver package. As a result, the base driver, which provides only core device functionality, can be targeted, flighted, and serviced independently from the customizations.

  • Hardware Support App (H): Any user interface (UI) component associated with a universal driver must be packaged as a Hardware Support App (HSA) or preinstalled on the OEM device. An HSA is an optional device-specific app that's paired with a driver. The application can be a Universal Windows Platform (UWP) or Desktop Bridge app. You must distribute and update an HSA through the Microsoft Store. For details, see Hardware Support App (HSA): Steps for driver developers and Hardware Support App (HSA): Steps for app developers.

  • Universal API compliance (U): Binaries in the universal driver package call only those APIs and DDIs that are included in UWP-based editions of Windows 10. These DDIs are marked as Universal on the corresponding documentation reference pages. INF files use only universal INF syntax.

In the documentation, we use the DCHU acronym to refer to these principles. Later in this article, you'll find guidance to make your driver package DCHU-compliant. Also check out Universal driver scenarios, which describes how the DCHU universal driver sample applies the DCHU design principles.


When you write a universal driver package, follow these steps:

Best practices