Using a Universal INF File

If you are building a universal or mobile driver package, you must use a universal INF file. If you are building a desktop driver package, you don't have to use a universal INF file, but doing so is recommended because of the performance benefits.

A universal INF file uses a subset of the INF syntax that is available to a Windows driver. A universal INF file installs a driver and configures device hardware, but does not perform any other action, such as running a co-installer.

Why is a universal INF file required on non-desktop editions of Windows?

Some editions of Windows, such as Windows 10 Mobile, do not support the Plug and Play mechanism for driver installation. Therefore, driver installation takes place on an offline image of the target system. When Microsoft Visual Studio builds your driver for such a target system, it generates an XML-based configuration file that contains all of the registry settings to be applied. As a result, an INF file for such a system must perform only additive operations that do not depend on the runtime behavior of the system. An INF file with such restricted syntax is called a universal INF file.

A universal INF file installs predictably, with the same result each time. The results of the installation do not depend on the runtime behavior of the system. For example, co-installer references are not valid in a universal INF file because code in an additional DLL cannot be executed on an offline system.

As a result, a driver package with a universal INF file can be configured in advance and added to an offline system.

You can use the InfVerif tool to test if your driver's INF file is universal.

Which INF sections are invalid in a universal INF file?

You can use any INF section in a universal INF file except for the following:

The INF Manufacturer Section is valid as long as the TargetOSVersion decoration does not contain a ProductType flag or SuiteMask flag.

Which INF directives are invalid in a universal INF file?

You can use any INF directive in a universal INF file except for the following:

The following directives are valid with some caveats:

  • The INF AddReg Directive is valid if entries in the specified add-registry-section have a reg-root value of HKR, or in the following cases:

    • For registration of Component Object Model (COM) objects, a key may be written under:
      • HKCR
      • HKLM\SOFTWARE\Classes
    • For creation of Hardware Media Foundation Transforms (MFTs), a key may be written under:
      • HKLM\SOFTWARE\Microsoft\Windows Media Foundation
      • HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation
      • HKLM\SOFTWARE\WOW3232Node\Microsoft\Windows Media Foundation
  • INF CopyFiles Directive is valid only if the destination directory is one of the following:

    • 11 (corresponds to %WINDIR%\System32)
    • 12 (corresponds to %WINDIR%\System32\Drivers)
    • 13 (corresponds to the directory under %WINDIR%\System32\DriverStore\FileRepository where the driver is stored)
      Note: CopyFiles may not be used to rename a file for which DestinationDirs includes dirid 13. Also, dirid 13 is only valid on Windows 10 products for a limited subset of device installation scenarios. Please consult guidance and samples for your specific device class for more details.
    • 10,SysWOW64 (corresponds to %WINDIR%\SysWOW64)
    • 10,vendor-specific subdirectory name
      Note: In Windows 10, version 1709, using dirid 10 with a vendor-specific subdirectory name is valid in a universal INF as measured using the InfVerif tool. In later releases, this value may not be supported. We recommend moving to dirid 13.

See Also