Using a Universal INF File
Some editions of Windows use only a subset of the driver installation methods that are available on Windows 10 Desktop. An INF file for non-Desktop versions of Windows must perform only additive operations that are fully described in the INF file. 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 execution of components outside of the system provided device installation components. For example, co-installer references are not valid in a universal INF file because requiring code in an additional DLL to run as part of installation means that the system cannot determine the result of the installation just from the INF file.
To test if your INF is universal, use infverif /u.
A Windows Driver must pass infverif /w, which tests /u as well as Driver Package Isolation.
For a list of InfVerif options, see Running InfVerif from the command line.
If you are building a Windows Desktop Driver package, you don't have to use a universal INF file, but doing so is recommended because of the performance benefits.
Which INF sections are invalid in a universal INF file?
You can use any system defined INF section in a universal INF file except for the following:
- INF ClassInstall32 Section
- INF DDInstall.CoInstallers Section
- INF DDInstall.FactDef Section
- INF DDInstall.LogConfigOverride Section
The INF Manufacturer Section is valid as long as the TargetOSVersion decoration does not contain a ProductType flag or SuiteMask flag.
The INF DefaultInstall Section is valid only if it has an architecture decoration, for example [DefaultInstall.NTAMD64].
Which INF directives are invalid in a universal INF file?
You can use any system defined INF directive in a universal INF file except for the following:
- INF BitReg Directive
- INF DelFiles Directive
- INF DelProperty Directive
- INF DelReg Directive
- INF DelService Directive
- INF Ini2Reg Directive
- INF LogConfig Directive
- INF ProfileItems Directive
- INF RegisterDlls Directive
- INF RenFiles Directive
- INF UnregisterDlls Directive
- INF UpdateIniFields Directive
- INF UpdateInis Directive
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
- For registration of Component Object Model (COM) objects, a key may be written under:
INF CopyFiles Directive is valid only if the destination directory is one of the following dirids:
- 11
- 12
- 13 (see Run from Driverstore)
Note: CopyFiles may not be used to rename a file for which DestinationDirs includes dirid 13. - 10,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.