Download the Windows Driver Kit (WDK)

The WDK is used to develop, test, and deploy Windows drivers.

Runtime requirements

You can run the Windows 10, version 2004 WDK on Windows 7 and later, and use it to develop drivers for these operating systems:

Client OS	Server OS
Windows 10	Windows Server 2019, Windows Server 2016
Windows 8.1	Windows Server 2012 R2
Windows 8	Windows Server 2012
Windows 7	Windows Server 2008 R2 SP1

WDK for Windows 10, version 2004

Step 1: Install Visual Studio 2019

The WDK requires Visual Studio. For more information about system requirements for Visual Studio, see Visual Studio 2019 System Requirements.

The following editions of Visual Studio 2019 support driver development for this release:

When you install Visual Studio 2019, select the Desktop development with C++ workload. The Windows 10 Software Development Kit (SDK) is automatically included, and is displayed in the right-hand Summary pane. Note that the version of the SDK that is compatible with the WDK for Windows 10, version 2004 may not be the default SDK. To select the correct SDK:

In Visual Studio Installer, on the Individual components tab, search for Windows 10 SDK (10.0.19041.0), select this version and continue with install. Note that Visual Studio will automatically install Windows 10 SDK (10.0.19041.1) on your machine.

If you already have Visual Studio 2019 installed, you can install the Windows 10 SDK (10.0.19041.1) by using the Modify button in Visual Studio install.

WDK has Spectre mitigation enabled by default but requires spectre mitigated libraries to be installed with Visual Studio for each architecture you are developing for. Additionally, developing drivers for ARM/ARM64 require the build tools for these architectures to also be installed with Visual Studio. To locate these items you will need to know the latest version of MSVC installed on your system.

To find the latest version of MSVC installed on your system, in Visual Studio Installer go to workload page, on the right pane under installation details, expand Desktop development with C++ and locate the MSVC v142 — VS 2019 C++ x64/x86 build tools (V14.xx) — note where xx should be the highest version available.

With this information (v14.xx), go to Individual components and search for v14.xx. This will return the tool sets for all architectures, including Spectre mitigated libs. Select the driver architecture you are developing for.

For example, searching for v14.25 returns the following:

Step 1.5 Install Refreshed Windows SDK 10.0.19041.685 for Windows 10, version 2004

This SDK is strongly recommended and will eventually be made available through Visual Studio

Step 2: Install Refreshed WDK for Windows 10, version 2004

The WDK Visual Studio extension is included in the default WDK installation.

If you can’t find driver project templates in Visual Studio, the WDK Visual Studio extension didn’t install properly. To resolve this, run the WDK.vsix file from this location: C:\Program Files (x86)\Windows Kits\10\Vsix\VS2019\WDK.vsix.

Enterprise WDK (EWDK) for Windows 10, version 2004

The EWDK is a standalone, self-contained command-line environment for building drivers. It includes the Visual Studio Build Tools, the SDK, and the WDK. The latest public version of the EWDK contains Visual Studio 2019 Build Tools 16.7.0 and MSVC toolset v14.23. To get started, mount the ISO and run LaunchBuildEnv.

The EWDK also requires the .NET Framework version 4.7.2. For more information about other requirements for the .NET Framework, see .NET Framework system requirements.

EWDK with Visual Studio Build Tools

You can use the Visual Studio interface with the build tools provided in the EWDK.

1. Mount the EWDK ISO.
2. Run LaunchBuildEnv.cmd .
3. In the environment created in step 2, type SetupVSEnv, and then press Enter.
4. Launch devenv.exe from the same environment, using the full file path. Example: «C:\Program Files (x86)\Microsoft Visual Studio\2019\\%Community|Professional|Enterprise%\Common7\IDE\devenv.exe»

Note that the Visual Studio major version should match with the version in the EWDK. For example, Visual Studio 2019 works with the EWDK that contain VS16.X build tools.

Driver samples for Windows 10

To download the driver samples, do one of the following:

• Go to the driver samples page on GitHub, click Clone or download, and then click Download ZIP.
• Download the GitHub Extension for Visual Studio, and then connect to the GitHub repositories.
• Browse the driver samples on the Microsoft Samples portal.

File systems driver design guide

This section of the WDK provides conceptual information related to file systems and filter drivers. For reference pages that describe the interfaces your driver can implement or call, see the File System Programming Reference.

File systems

File systems in Windows are implemented as file system drivers working above the storage system.

Every system-supplied file system in Windows is designed to provide reliable data storage with varying features to meet the user’s requirements. Standard file systems available in Windows include NTFS, ExFAT, UDF, and FAT32. A comparison of features for each of these file systems is shown in File System Functionality Comparison. Additionally, the Resilient File System (ReFS), available on Windows Server 2012 and later versions, offers scalable large volume support and the ability to detect and correct data corruption on disk.

Developing a new file system driver is almost always unnecessary, and requirements/specifications for new file system drivers are not predictable. To that end, this design guide does not cover file system development. If you do need to develop a new file system driver beyond those available in Windows, sample code is available as a model (see below).

File system filter drivers

A file system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. Examples of filter drivers include:

• Anti-virus filters
• Backup agents
• Encryption products

Filter driver developers use the system-supplied Filter Manager, which provides a framework for developing filter drivers without having to manage all the complexities of file I/O. The Filter Manager simplifies the development of third-party filter drivers and solves many of the problems with the legacy filter driver model, such as the ability to control load order through an assigned altitude.

File system and filter sample code

A number of Windows driver samples are available, including samples for file system development and file system filter driver development. See Windows driver samples for a complete list.

File system filter driver certification

Certification information for File Systems and File System Filter Drivers is found in the Windows Hardware Lab Kit (HLK). Tests for File Systems and File System Filter Drivers are found in the Filter.Driver category of the HCK.

Additional resources

Along with this documentation and the sample code mentioned above, OSR offers a variety of resources for file system filter development, including seminars and community discussion forums such as the NTFDS forum.

Creating an INF File for a File System Driver

The Windows Setup and Device Installer Services, known collectively as SetupAPI, provide the functions that control Windows setup and driver installation. The installation process is controlled by INF files.

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.

For more information about INF files and how they are created, see Creating an INF File and INF File Sections and Directives. For general information about signing drivers, see Driver Signing.

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. Only catalog files can receive WHQL logo signatures.

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.

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.

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.

DestinationDirs (optional but recommended)

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.

Entry	Value
Signature	«$WINDOWS NT$»
Provider	In your own INF file, you should specify a provider other than Microsoft.
DriverVer	See INF DriverVer directive
CatalogFile	Leave this entry blank. In the future, it will contain the name of a WHQL-supplied catalog file for signed drivers.

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.

Value	Description
0x00000001	SERVICE_KERNEL_DRIVER (Device driver service)
0x00000002	SERVICE_FILE_SYSTEM_DRIVER (File system or file system filter driver service)
0x00000010	SERVICE_WIN32_OWN_PROCESS (Microsoft Win32 service that runs in its own process)
0x00000020	SERVICE_WIN32_SHARE_PROCESS (Win32 service that shares a process)

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.

Value	Description
0x00000000	SERVICE_BOOT_START
0x00000001	SERVICE_SYSTEM_START
0x00000002	SERVICE_AUTO_START
0x00000003	SERVICE_DEMAND_START
0x00000004	SERVICE_DISABLED

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.

Value	Description
0x00000000	SERVICE_ERROR_IGNORE (Log the error and continue system startup.)
0x00000001	SERVICE_ERROR_NORMAL (Log the error, display a message to the user, and continue system startup.)
0x00000002	SERVICE_ERROR_SEVERE (Switch to the registry’s LastKnownGood control set and continue system startup.
0x00000003	SERVICE_ERROR_CRITICAL (If system startup is not using the registry’s LastKnownGood control set, switch to LastKnownGood and try again. If startup still fails, run a bug-check routine. Only the drivers that are needed for the system to startup should specify this value in their INF files.)

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.

NoteВ В 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.