The extension INF with the unique ExtensionId value is also selected. The system applies the base INF for the device, and then applies the two extension INFs for that device.

Note that extension INF files are always applied after the base INF, but that there is no determined order in which the extension INFs are applied.

Creating an extension INF

Here are the entries you need to define an INF as an extension INF.

Specify these values for Class and ClassGuid in the Version section. For more info on setup classes, see System-Defined Device Setup Classes Available to Vendors.

Provide an ExtensionId entry in the [Version] section. Generate a new GUID for the initial version of an extension INF, or reuse the last GUID for subsequent updates of the initial extension INF.

Note that an organization may only use an ExtensionID that it owns. For information on registering an Extension ID, see Managing hardware submissions in the Windows Hardware Dev Center dashboard.

1. If you are updating an extension INF, keep the ExtensionId the same and increment the version or date (or both) specified by the DriverVer directive. For a given ExtensionId value, PnP selects the INF with the highest DriverVer.

If your extension INF targets Windows 10 S, see Windows 10 in S mode Driver Requirements for information about driver installation on that version of Windows.

In the INF Models section, specify one or more hardware and compatible IDs that match those of the target device. Note that these hardware and compatible IDs do not need to match those of the base INF. Typically, an extension INF lists a more specific hardware ID than the base INF, with the goal of further specializing a specific driver configuration. For example, the base INF might use a two-part PCI hardware ID, while the extension INF specifies a four-part PCI hardware ID, like the following:

Alternatively, the extension INF might list the same hardware ID as the base INF, for instance if the device is already very narrowly targeted, or if the base INF already lists the most specific hardware ID.

In some cases, the extension INF might provide a less specific device ID, like a compatible ID, in order to customize a setting across a broader set of devices.

CHID targeting can be used if a four-part hardware ID is not possible or is not restrictive enough.

Do not define a service with SPSVCINST_ASSOCSERVICE . However, an extension INF can define other services, such as a filter driver for the device. For more info about specifying services, see INF AddService Directive.

In most cases, you’ll submit an extension INF package to the Hardware Dev Center separately from the base driver package. For examples on how to package extension INFs, as well as links to sample code, see DCH-Compliant Driver Package Example.

The driver validation and submission process is the same for extension INFs as for regular INFs. For more info, see Windows HLK Getting Started.

Uninstalling an extension driver

To uninstall an extension driver, use PnPUtil’s delete-driver command with the uninstall flag. This allows the extension driver to be uninstalled without removing the base driver.

Find the oem .inf name of the driver package to uninstall and use pnputil /delete-driver oem .inf /uninstall .

pnputil /enum-drivers can be used to help identify the appropriate oem .inf name.

Example 1: Using an extension INF to set the device friendly name

In one common scenario, a device manufacturer (IHV) provides a base driver and a base INF, and then a system builder (OEM) provides an extension INF that supplements and in some cases overrides the configuration and settings of the base INF. The following snippet is a complete extension INF that shows how to set the device friendly name.

Example 2: Using an extension INF to install additional software

The following snippet is a complete extension INF that is included in the Driver package installation toolkit for universal drivers. This example uses INF AddComponent directive to create components that install a service and an executable. For more info about what you can do in a component INF, see Using a Component INF File.

To access this file online, see osrfx2_DCHU_extension.inx .

For info on how to use an Extension INF to install a filter driver, see Device filter driver ordering.

To improve extensibility, we recommend that an IHV put optional functionality in an extension INF template.

Backward compatibility

Any change to the base INF must be thoroughly tested to ensure that it does not break backward compatibility for existing extension INFs.

When managing a base INF, follow these best practices:

• Document parameter value ranges and constraints both in code comments and in a design document. Future changes must conform to the specified ranges.
• To support new ranges, add an optional parameter (no default value).

If the IHV puts all functionality in the base INF, here is one way to ensure that existing extension INFs continue to work:

1. The IHV provides a companion app that sets a registry flag to disable optional functionality by default.
2. The base driver checks if the flag is enabled before using optional functionality.
3. An OEM-supplied extension INF can opt in by setting the flag to enable.

Submitting an extension INF for certification

For detailed information on how to work with Extension INFs on the Hardware Dev Center, please see Working with Extension INFs in the Windows Hardware Dev Center Dashboard.

Using an INF File to Install a File System Filter Driver

After you have created an INF file, you can use it to install, upgrade, and uninstall your file system filter driver. You can use the INF file alone or together with a batch file or a user-mode setup application.

Right-Click Install

To execute the DefaultInstall and DefaultInstall.Services sections of your INF file, you should do the following:

In Windows Explorer, select and hold (or right-click) the INF file name. A shortcut menu will appear.

Select Install.

NoteВ В The shortcut menu appears only if the INF file contains a DefaultInstall section.

Command-Line or Batch File Install

To execute the DefaultInstall and DefaultInstall.Services sections of your INF file on the command line or by using a batch file installation, type the following command at the command prompt, or create and run a batch file that contains this command:

«Rundll32» and «InstallHinfSection» are described in the Tools and Setup and System Administration sections, respectively, of the Microsoft Windows SDK documentation.

Setup Application

InstallHinfSection can also be called from a setup application, as shown in the following code example:

If you use a setup application to install your driver, observe the following guidelines:

To prepare for eventual uninstall, the setup application should copy the driver INF file to an uninstall directory.

If the setup application installs a user-mode application with the driver, this application should be listed in Add or Remove Programs in Control Panel so that the user can uninstall it if desired. Only one item should be listed, representing both the application and the driver.

For more information about how to list your application in Add or Remove Programs, see «Removing an Application» in the Setup and System Administration section of the Windows SDK documentation.

Setup applications should never copy driver INF files to the Windows INF file directory (%windir%\INF). SetupAPI copies the files there automatically as part of the InstallHinfSection call.

For more information about setup applications, see Writing a Device Installation Application.

Installing a File System Driver

About Driver Installation

The Setup application programming interface (SetupAPI) provides the functions that control Windows setup and driver installation, including the installation of file system and file system filter drivers.

The installation process is controlled by INF files. For more information about INF files:

For file system driver-specific INF file information, see below

For more information about general driver installation (including information about driver packages, INF files, and driver signing), see Device and Driver Installation.

After creating an INF file, you will typically write the source code for your setup application. The setup application calls user-mode setup functions to access the information in the INF file and perform installation operations.

The following information regarding installing and uninstalling file system filter drivers also applies to file system drivers:

Creating an INF File for a File System Driver

A file system driver’s INF file provides instructions that SetupAPI uses to install the driver. The INF file is a text file that specifies the files that must be present for your driver to run and the source and destination directories for the driver files. An INF file also contains driver configuration information that SetupAPI stores in the registry, such as the driver’s start type and load order group.

You can create a single INF file to install your driver on multiple versions of the Windows operating system. For more information about creating such an INF file, see Creating INF Files for Multiple Platforms and Operating Systems and Creating International INF Files.

Starting with 64-bit versions of Windows Vista, all kernel-mode components, including non-PnP (Plug and Play) drivers such as file system drivers (file system, legacy filter, and minifilter drivers), must be signed in order to load and execute. For these versions of the Windows operating system, the following list contains information that is relevant to file system drivers.

INF files for non-PnP drivers, including file system drivers, are not required to contain [Manufacturer] or [Models] sections.

The SignTool command-line tool, located in the \bin\SelfSign directory of the WDK installation directory, can be used to directly «embed sign» a driver SYS executable file. For performance reasons, boot-start drivers must contain an embedded signature.

Given an INF file, the Inf2Cat command-line tool can be used to create a catalog (.cat) file for a driver package.

With Administrator privileges, an unsigned driver can still be installed on x64-based systems starting with Windows Vista. However, the driver will fail to load (and thus execute) because it is unsigned.

For detailed information about the driving signing process, including the driving signing process for 64-bit versions of Windows Vista, see Kernel-Mode Code Signing Walkthrough.

All kernel-mode components, including custom kernel-mode development tools, must be signed. For more information, see Signing Drivers during Development and Test (Windows Vista and Later).

INF files cannot be used to read information from the registry or to launch a user-mode application.

Sections in a File System Driver INF File

To construct your own file system driver INF file, use the following information as a guide. You can use the InfVerif tool to check the syntax of your INF file.

An INF file for a file system driver generally contains the following sections.

Version Section (required)

The Version section specifies the driver version information, as shown in the following code example.

The following table shows the values that file system filter drivers should specify in the Version section.

DestinationDirs Section (optional but recommended)

The DestinationDirs section specifies the directories where the file system driver files will be copied.

In this section and in the ServiceInstall section, you can specify well-known system directories by using system-defined numeric values. For a list of these values, see INF DestinationDirs Section. In the following code example, the value «12» refers to the Drivers directory (%windir%\system32\drivers).

SourceDisksNames Section (required)

The SourceDisksNames section specifies the distribution media to be used.

In the following code example, the SourceDisksNames section lists a single distribution media for the file system driver. The unique identifier for the media is 1. The name of the media is specified by the %Disk1% token, which is defined in the Strings section of the INF file.

SourceDisksFiles Section (required)

The SourceDisksFiles section specifies the location and names of the files to be copied.

In the following code example, the SourceDisksFiles section lists the file to be copied for the file system driver and specifies that the files can be found on the media whose unique identifier is 1 (This identifier is defined in the SourceDisksNames section of the INF file.)

DefaultInstall Section (required)

In the DefaultInstall section, a CopyFiles directive copies the file system driver’s driver files to the destination that is specified in the DestinationDirs section.

The CopyFiles directive should not refer to the catalog file or the INF file itself; SetupAPI copies these files automatically.

You can create a single INF file to install your driver on multiple versions of the Windows operating system. This type of INF file is created by creating additional DefaultInstall, DefaultInstall.Services, DefaultUninstall, and DefaultUninstall.Services sections for each operating system version. Each section is labeled with a decoration (for example, .ntx86, .ntia64, or .nt) that specifies the operating system version to which it applies. For more information about creating this type of INF file, see Creating INF Files for Multiple Platforms and Operating Systems.

In the following code example, the CopyFiles directive copies the files that are listed in the ExampleFileSystem.DriverFiles section of the INF file.

DefaultInstall.Services Section (required)

The DefaultInstall.Services section contains an AddService directive that controls how and when the services of a particular driver are loaded.

In the following code example, the AddService directive adds the file system service to the operating system. The %ServiceName% token contains the service name string, which is defined in the Strings section of the INF file. ExampleFileSystem.Service is the name of the file system driver’s ServiceInstall section.

ServiceInstall Section (required)

The ServiceInstall section adds subkeys or value names to the registry and sets values. The name of the ServiceInstall section must appear in an AddService directive in the DefaultInstall.Services section.

The following code example shows the ServiceInstall section for the file system driver.

The DisplayName entry specifies the name for the service. In the preceding example, the service name string is specified by the %ServiceName% token, which is defined in the Strings section of the INF file.

The Description entry specifies a string that describes the service. In the preceding example, this string is specified by the %ServiceDesc% token, which is defined in the Strings section of the INF file.

The ServiceBinary entry specifies the path to the executable file for the service. In the preceding example, the value 12 refers to the Drivers directory (%windir%\system32\drivers).

The ServiceType entry specifies the type of service. The following table lists the possible values for ServiceType and their corresponding service types.

The ServiceType entry should always be set to SERVICE_FILE_SYSTEM_DRIVER for a file system driver.

The StartType entry specifies when to start the service. The following table lists the possible values for StartType and their corresponding start types.

For detailed descriptions of these start types to determine which one is appropriate for your file system driver, see What Determines When a Driver Is Loaded.

Starting with x64-based Windows Vista systems, the binary image file of a boot-start driver (a driver that has a start type of SERVICE_BOOT_START) must contain an embedded signature. This requirement ensures optimal system boot performance. For more information, see Kernel-Mode Code Signing Walkthrough.

For information about how the StartType and LoadOrderGroup entries determine when the driver is loaded, see What Determines When a Driver Is Loaded.

The ErrorControl entry specifies the action to be taken if the service fails to start during system startup. The following table lists the possible values for ErrorControl and their corresponding error control values.

The LoadOrderGroup entry must always be set to «File System» for a file system driver. This is different from what is specified for a file system filter driver or file system minifilter driver where the LoadOrderGroup entry is set to one of the file system filter load order groups. For more information about the load order groups that are used for file system filter drivers and file system minifilter drivers, see Load Order Groups for File System Filter Drivers and Load Order Groups and Altitudes for Minifilter Drivers.

The AddReg directive refers to one or more INF writer-defined AddRegistry sections that contain any information to be stored in the registry for the newly installed service.

If the INF file will also be used for upgrading the driver after the initial install, the entries that are contained in the AddRegistry section should specify the 0x00000002 (FLG_ADDREG_NOCLOBBER) flag. Specifying this flag preserves the registry entries in HKLM\CurrentControlSet\Services when subsequent files are installed. For example:

DefaultUninstall Section (optional)

The DefaultUninstall section is optional but recommended if your driver can be uninstalled. It contains DelFiles and DelReg directives to remove files and registry entries.

In the following code example, the DelFiles directive removes the files that are listed in the ExampleFileSystem.DriverFiles section of the INF file.

The DelReg directive refers to one or more INF writer-defined DelRegistry sections that contain any information to be removed from the registry for the service that is being uninstalled.

DefaultUninstall.Services Section (optional)

The DefaultUninstall.Services section is optional but recommended if your driver can be uninstalled. It contains DelService directives to remove the file system driver’s services.

In the following code example, the DelService directive removes the file system driver’s service from the operating system.

The DelService directive should always specify the 0x200 (SPSVCINST_STOPSERVICE) flag to stop the service before it is deleted.

There are certain classes of file system products that cannot be completely uninstalled. In this situation, it is acceptable to just uninstall the components of the product that can be uninstalled and leave installed the components of the product that cannot be uninstalled. An example of such a product is the Microsoft Single Instance Store (SIS) feature.

Strings Section (required)

The Strings section defines each %strkey% token that is used in the INF file.

For example, the file system driver defines the following strings in its INF file.

You can create a single international INF file by creating additional locale-specific Strings.LanguageID sections in the INF file. For more information about international INF files, see Creating International INF Files.