INF Version section

By convention, the Version section appears first in INF files. Every INF file must have this section.

[LayoutFile=filename.inf [,filename.inf]... ]  (Windows 2000 and Windows XP)
[]  (Windows XP and later versions of Windows)
[]  (Windows XP and later versions of Windows)
[]  (Windows 8 and later versions of Windows)
[]  (Windows 10 version 1709 and later versions of Windows)

[PnpLockDown=0|1] (Windows Vista and later versions of Windows)


Must be $Windows NT$ or $Chicago$. This indicates the operating systems for which this INF is valid. These signature values have the following meanings.

Signature value Meaning
$Windows NT$ All Windows operating systems
$Chicago$ All Windows operating systems

The enclosing dollar sign characters ($) are required but these strings are case-insensitive. If signature-name is none of these string values, the file is not accepted as a valid INF.

Generally, Windows does not differentiate among these signature values. One of them must be specified, but it does not matter which one. You should specify the appropriate value so that someone reading an INF file can determine the operating systems for which it is intended.

Some class installers put additional requirements on how the signature value must be specified. Such requirements, if they exist, are discussed in device type-specific sections of this Windows Driver Kit (WDK).

An INF must supply OS-specific installation information by appending system-defined extensions to its DDInstall sections, whether the signature-name is $Windows NT$ or $Chicago$. (See Creating INF Files for Multiple Platforms and Operating Systems for a discussion of these extensions.)

For any standard type of device, this specifies the name of the device setup class for the type of device that is installed by using this INF file. This name is usually one of the system-defined class names, such as Net or Display, which are listed in Devguid.h. For more information, see System-Supplied Device Setup Classes.

If an INF specifies a Class, it should also specify the corresponding system-defined GUID value for its ClassGUID entry. Specifying the matching GUID value for a device of any predefined device setup class can install the device and its drivers faster because this helps the system setup code to optimize its INF searching.

If an INF adds a new setup class of devices to the system, it should supply a unique, case-insensitive class-name value that differs from any of the system-supplied classes in Devguid.h. The length of the class-name string must be 32 characters or less. The INF must specify a newly generated GUID value for the ClassGUID entry. Also see INF ClassInstall32 Section.

This entry is irrelevant to an INF that installs neither a new device driver under a predefined device setup class nor a new device setup class.


This entry is required for device drivers that are installed through the Plug and Play (PnP) manager.

Specifies the device setup class GUID. The GUID value is formatted as shown here, where each n is a hexadecimal digit.

This GUID value specifies the device setup class to assign to devices that are installed from this INF file. This class-specific GUID value also identifies the device class installer for the type of device and class-specific property page provider, if any.

For a new device setup class, the INF must specify a newly generated ClassGUID value. For more information about how to create GUIDs, see Using GUIDs in Drivers. Also see Device Setup Classes.


This entry is required for device drivers that are installed through the PnP manager.

Specifies the extension ID GUID when authoring an extension INF. The GUID value is formatted as shown here, where each x is a hexadecimal digit.

When creating the initial version of an extension INF, the INF must specify a newly generated ExtensionId value. However, when updating an existing extension INF, the ExtensionId must remain the same so that multiple related versions of the extension INF are versioned against each other instead of being treated as independent extension INFs that may be simultaneously installed on the same device instance. For more information about how to author extension INFs, see Using an Extension INF File.


This entry is only required when creating an extension INF, as identified by specifying Class = Extension and ClassGuid = {e2f84ce7-8efa-411c-aa69-97454ca4cb57}.

Reserved for system use unless explicitly required by a device class such as Printer. For example, see V4 Driver INF.

Identifies the provider of the INF file. Typically, this is specified as an %OrganizationName% token that is expanded later in the INF file's Strings section. The maximum length, in characters, of a provider name is LINE_LEN.

For example, INF files supplied with the system typically specify the INF-creator as %Msft% and define %Msft% = "Microsoft" in their Strings sections.


This entry is required for device drivers that are installed through the PnP manager.
Specifies a catalog (.cat) file to be included on the distribution media of a driver package.

When a driver package is submitted to Microsoft for digital signing, WHQL provides a catalog file for the driver package after WHQL has tested and assigned digital signatures to the package. For more information about the testing and signing of IHV or OEM driver packages, see WHQL Release Signature. Catalog files are not listed in the SourceDisksFiles section or CopyFiles directive of the INF. Windows assumes that the catalog file is in the same location as the INF file.

System-supplied INF files never have CatalogFile= entries because the operating system validates the signature for such an INF against all system-supplied files. | | |

Specifies another INF-writer-determined, unique file name, with the .cat extension, of a catalog file. If these optional entries are omitted, a given is used for validating WDM device/driver installations.

If any decorated entry exists in an INF's Version section together with an undecorated CatalogFile= entry, the undecorated entry is assumed to identify a for validating device installations, driver installations, or both on those platforms for which a decorated entry is not specified.

Any cross-platform device driver INF file that has CatalogFile= and entries must supply a unique IHV/OEM-determined name for each such .cat file.

For more information about how to use the system-defined .nt, .ntx86, .ntia64, .ntamd64, .ntarm, and .ntarm64 extensions, see Creating INF Files for Multiple Platforms and Operating Systems.


Because the same .cat file can be used across all supported platforms, the use of this entry is not required or recommended. However, you must use this entry if you want to create platform-specific .cat files for your driver package.

DriverVer= mm/dd/yyyy,w.x.y.z
This entry specifies version information for drivers that are installed by this INF file. Starting with Windows 2000, this entry is required.

For information about how to specify this entry, see INF DriverVer Directive.

Specifies whether Plug and Play (PnP) prevents applications from directly modifying the files that a driver package's INF file specifies. If the PnpLockDown directive is set to 1, PnP prevents applications from directly modifying the files that are copied by INF CopyFiles directives. Otherwise, if the directive is not included in an INF file or the value of the directive is set to zero, an application that has administrator privileges can directly modify these files. Driver files that are protected in this manner are referred to as third-party protected driver files.

To ensure the integrity of a PnP driver installation, applications should not directly modify driver files that are copied by the driver package INF file. Applications should only use the device installation mechanisms provided by Windows to update PnP drivers.

Starting with Windows Vista, a driver package should set PnpLockDown to 1 to prevent an application from directly modifying driver files. However, some existing applications that uninstall driver packages do directly delete driver files. To maintain compatibility with these applications, the PnpLockDown directive for such driver package should be set to zero.


Although PnP on Windows Vista and later versions of Windows does not require that an INF file include a PnpLockDown directive in order to install a driver, PnP in a future version of Windows might require that INF files for PnP driver packages include the PnpLockDown directive.

Deprecated. Was previously used by Driver Install Frameworks (DIFx). For info about the DIFx deprecation, see DIFx Guidelines.

DriverPackageType= PackageType
Deprecated. Was previously used by Driver Install Frameworks (DIFx). For info about the DIFx deprecation, see DIFx Guidelines.


When a driver package passes Microsoft Windows Hardware Quality Lab (WHQL) testing, WHQL returns .cat catalog files to the IHV or OEM. Each .cat file contains a digitally encrypted signature for the driver package. The IHV or OEM must list these .cat files in the INF Version section and must supply the files on the distribution media, in the same location as the INF file. The .cat files must be uncompressed.


If an INF Version section does not include at least one CatalogFile or CatalogFile.ntxxx entry, the driver is treated as unsigned, and the dates listed in the DriverVer directive are not displayed by Windows.

For more information, see Driver Signing.


The following example shows a Version section typical of a simple driver package INF, followed by the required SourceDisksNames and SourceDisksFiles sections implied by the entries specified in this sample Version section:

Signature="$Windows NT$"

; diskid = description[, [tagfile] [, <unused>, subdir]]
1 = %Disk_Description%,,,\WinNT

; filename_on_source = diskID[, [subdir][, size]]
exampleDriver.sys = 1,\x86

; ...

Disk_Description = "Contoso Drivers Disk"
; ...

See also