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 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.
A driver package with a universal INF file can be configured in advance and added to an offline system.
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 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 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:
- 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.