Microsoft Windows Driver Development and Inf File Constructiont

Contents
Developing Drivers
Windows Drivers
Getting Started with Windows Drivers
DCH Design Principles and Best Practices
Driver Package Isolation
API Layering
Building a Windows driver
Validating Windows Drivers
DCH-Compliant Driver Package Example
Debugging a Windows Driver
Building Drivers
Creating a New Device Function Driver
Creating a New Filter Driver
Device Filter Driver Ordering
Creating a New Software Driver
Creating a New Primitive Driver
Creating a Driver From Existing Source Files
Building a Driver with the WDK
Building for OneCore
Building Drivers for Different Versions of Windows
Building ARM64 Drivers with the WDK
Using the Enterprise WDK 10
Installing the WDK 8.1 Build Environment in a Lab
Using the Microsoft C Runtime with User-Mode Drivers and Desktop Apps
Avoiding Floating Point Errors in Custom Build Environments
Counters Manifest Preprocessor Properties for Driver Projects
Driver Model Settings Properties for Driver Projects
Message Compiler Properties for Driver Projects
MOF Compiler Properties for Driver Projects
Stampinf Properties for Driver Projects
Converting WDK 8.1 Projects to WDK 10
Driver convergence model for Windows 10
Target platform on driver reference pages
Analyzing a Driver Using Code Analysis and Verification Tools
Preparing a Computer for Manual Driver Deployment
What happens when you provision a computer (WDK 8.1)
What happens when you provision a computer (WDK 8.0)
Troubleshooting Configuration of Driver Deployment, Testing and Debugging
Creating a Driver Package
Creating a Device Metadata Package
Signing Drivers
Signing a Driver
Signing a Driver During Development and Testing
Signing a Driver for Public Release
Driver Signing Properties
Deploying Drivers
Deploying a Driver to a Test Computer
Deployment Properties for Driver Package Projects
Driver Verifier Properties for Driver Package Projects
KMDF Verifier Properties for Driver Package Projects
UMDF Verifier Properties for Driver Package Projects
Inf2Cat Properties for Driver Package Projects
How to create a custom driver installation script
Installing a driver on Windows 10 Mobile
Debugging a Driver
Testing Drivers
Testing a Driver
Tips for testing drivers during development
How to test a driver at runtime using Visual Studio
How to run the HCK Test Suites in WDK 8.1
How to select and configure the Device Fundamentals tests
How to test a driver package
How to read the driver test results log
How to test a driver at runtime from a Command Prompt
How to write a driver test using a Driver Test template
How to add test metadata
Static Driver Verifier Known Issues - Windows 10 October 2018 Update (version
1809)
Logging
Creating a Driver Verification Log
Creating a log file for the code analysis tool
Creating a log file for Static Driver Verifier
Distributing a driver package
Developing, Testing, and Deploying Drivers
11/2/2020 • 2 minutes to read • Edit Online
The Windows driver development environment and the Windows debuggers are integrated into Microsoft
Visual Studio. In this integrated driver development environment, most of the tools you need for coding,
building, packaging, deploying, and testing a driver are available in the Visual Studio user interface.
To set up the integrated development environment, first install Visual Studio and then install the WDK. You can
find information about how to get Visual Studio and the WDK on the WDK setup and download page. The
Debugging Tools for Windows are included with the WDK installation.
The WDK uses MSBuild.exe, which is available both in the Visual Studio user interface and as a command-line
tool. Drivers created in the Visual Studio environment use Project and Solution files to describe a project or
group of projects. The Visual Studio environment provides a tool for converting legacy Sources and Dirs files to
Project and Solution files.
The Visual Studio environment provides templates for:
New drivers
Driver packages
New tests
Enhancement of existing tests
Custom driver deployment scripts
In the Visual Studio environment, you can configure the build process so that it automatically creates and signs a
driver package. Static and run-time analysis tools are available in Visual Studio. You can configure a target
computer for testing your driver and automatically deploy your driver to the target computer each time you
rebuild. You can choose from an extensive set of run-time tests, and you can write your own tests.
The topics in this section show you how to use Visual Studio to perform several of the tasks involved in driver
development, deployment, and testing.
Additional Videos
You'll find videos on the following pages in the Windows driver docs:
Using the Windows Performance Toolkit (WPT) with WDF
Video: Accessing driver IFR logs without a debugger
Video: Debugging your driver with WDF source code
Videos: Debugging UMDF Drivers
Starting at some point after Windows 10, version 2004, drivers that run on Windows will be classified as either
Windows Drivers or Windows Desktop Drivers.
Windows Drivers will run on all Windows 10 variants, including Windows 10X and Windows 10 Desktop
editions. Windows Desktop Drivers will only run on Windows 10 Desktop editions.
The Windows Driver classification will extend and replace the current Universal Driver classification.
This page provides a preview of the upcoming requirements for Windows Drivers.
NOTE
The distinction between Windows Drivers and Windows Desktop Drivers does not affect any driver being submitted and
certified for Windows 10 Version 2004. Changes in certification and submission will happen at a later date.
Windows Drivers Requirements

When Windows Drivers become a certification option, the following requirements will apply:
Compliant with DCH Design Principles.
Follow the principles of Driver Package Isolation.
Follow API Layering Requirements.
Certified with Windows Hardware Compatibility Program Certification Process using the Hardware Lab Kit.
Note that the Windows Hardware Compatibility Program Certification Process requirements apply to both
KMDF and UMDF drivers.
Windows Drivers vs. Windows Desktop Drivers

The following table summarizes the distinctions above:
F EAT URE W IN DO W S DRIVERS W IN DO W S DESK TO P DRIVERS
Run on Windows 10 Desktop Yes Yes
Run on Windows 10X Yes No
Must be certified with WHCP Yes No
WDK & HLK are primary vehicles for Yes Yes

developing and certifying drivers
Adhere to stricter reliability and Yes No

serviceability requirements (e.g. driver
package isolation)
While it won't be required for a driver running only on Windows 10 Desktop to meet the additional
requirements for a Windows Driver, doing so will enhance driver serviceability and reliability, as well as
preparing the driver for possible future certification on Windows 10X.
DCH Design Principles and Best Practices
This page describes design principles and best practices for Windows Drivers.
DCH Design Principles

There are three design principles to consider for a Windows Driver to be DCH-compliant:
Declarative (D) : Install the driver by using only declarative INF directives. Don't include co-installers or
RegisterDll functions.
Componentized (C) : Edition-specific, OEM-specific, and optional customizations to the driver are separate
from the base driver package. As a result, the base driver, which provides only core device functionality,
can be targeted, flighted, and serviced independently from the customizations.
Hardware Support App (H) : Any user interface (UI) component associated with a Windows Driver must
be packaged as a Hardware Support App (HSA) or preinstalled on the OEM device. An HSA is an optional
device-specific app that's paired with a driver. The application can be a Universal Windows Platform
(UWP) or Desktop Bridge app. You must distribute and update an HSA through the Microsoft Store. For
details, see Hardware Support App (HSA): Steps for driver developers and Hardware Support App (HSA):
Steps for app developers.
The acronym "DCH" refers to the principles listed above. Please refer to the DCH-Compliant Driver Package
Example page to see how a driver sample can apply DCH design principles.
Overview
Driver packages that are DCH-compliant contain an INF file and binaries that install and run on Universal
Windows Platform (UWP)-based editions of Windows 10. They also install and run on other editions of
Windows 10 that share a common set of interfaces.
DCH-compliant driver binaries can use KMDF, UMDF 2, or the Windows Driver Model (WDM).
DCH-compliant drivers consist of the following parts:
A base driver
Optional component packages
An optional hardware support app
The base driver contains all the core functionality and shared code. The optional component packages can
contain customizations and additional settings.
Typically, a device manufacturer, or independent hardware vendor (IHV), writes the base driver. Then, a system
builder, or original equipment manufacturer (OEM), provides any optional component packages.
After an IHV has certified the base driver package, it can be deployed on all OEM systems. Because a base driver
package can be used across all systems that share a hardware part, Microsoft can test the base driver package
broadly via Windows Insider flighting, rather than limiting distribution to specific machines.
The OEM validates only the optional customizations that it provides for the OEM system.
Requirements
To create a driver package that follows DCH design principles, follow these steps:
Create an INF file for your driver:
1. Review the list of INF sections and directives that are valid in Windows Driver packages.
2. Use the InfVerif tool to verify that your driver package's INF file follows Declarative (D) requirements
for Windows Drivers. It should pass infverif /w .
Ensure that any optional component packages that do not contain core driver functionality are separated
from the base driver package.
Hardware support applications associated with your driver package must be distributed through the
Microsoft Store.
Best practices
If you're using the Windows Driver Kit (WDK) Version 2004 with the latest available Visual Studio,
set the Target Platform value in the driver project properties to Windows Driver . This automatically
adds the correct libraries, and it runs the proper INF validation and ApiValidator as a part of build. To do
this:
1. Open the driver project properties.
2. Select Driver Settings .
3. Use the drop-down menu to set Target Platform to Windows Driver .
If your INF performs any custom setup actions that depend on the target platform, consider separating
them out into an extension INF. You can update an extension INF independently from the base driver
package to make it more robust and serviceable. For more information, see Using an extension INF file.
If you want to provide an application that works with your device, include a UWP app. For more
information, see Hardware Support App (HSA): Steps for driver developers. An OEM can preload such an
app by using DISM - Deployment Image Servicing and Management. Or, users can manually download
the app from the Microsoft Store.
In the INF DestinationDirs section , set the destination directories to dirid 13 to make the driver run
from the driver store. This setting won't work for some devices.
Driver Package Isolation
Driver package isolation is a requirement for Windows Drivers that makes drivers more resilient to external
changes, easier to update, and more straightforward to install.
NOTE
While Driver Package Isolation is required for Windows Drivers, Windows Desktop Drivers still benefit from it through
improved resiliency and serviceability.
The following table shows legacy driver practices that are no longer allowed for Windows Drivers in the left
column along with the required behavior for Windows Drivers in the right column.
N O N - ISO L AT ED DRIVER ISO L AT ED DRIVER
INF copies files to System32\drivers Driver files are run from the driver store
Interacts with other drivers using hardcoded paths Interacts with other drivers using system-supplied functions
or device interfaces
Hardcodes path to global registry locations Uses HKR and system-supplied functions for relative location
of registry and file state
Runtime file writes to any location Driver writes files to system-supplied locations
Run From Driver Store

All isolated driver packages leave their driver package files in the driver store. This means that they specify
DIRID 13 in their INF to specify the location for driver package files on install.
A WDM or KMDF driver that is running from the DriverStore on Windows 10 version 1803 and later which
needs to access other files from its driver package should call IoGetDriverDirector y with
DriverDirectoryImage as the directory type to get the directory path that the driver was loaded from.
Alternatively for drivers that need to support OS versions before Windows 10 version 1803, use
IoQuer yFullDriverPath to find the driver's path, get the directory path it was loaded from, and look for
configuration files relative to that path. If the kernel mode driver is a KMDF driver, it can use
WdfDriverWdmGetDriverObject to retrieve the WDM driver object to pass to IoQueryFullDriverPath. UMDF
drivers can use GetModuleHandleExW and GetModuleFileNameW to determine where the driver was
loaded from. For example:
bRet = GetModuleHandleExW(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS,
(PCWSTR)&DriverEntry,
&handleModule);
if (bRet) {
charsWritten = GetModuleFileNameW(handleModule,
path,
pathLength);
…
For a file payloaded by an INF, the subdir listed in the SourceDisksFiles entry for the file in the INF must match
the subdir listed in the DestinationDirs entry for the file in the INF.
Additionally, a CopyFiles directive cannot be used to rename a file. These restrictions are required so that the
installation of an INF on a device does not result in the creation of new files in the DriverStore directory.
Since SourceDisksFiles entries cannot have multiple entries with the same filename and CopyFiles cannot be
used to rename a file, every file that an INF references must have a unique file name.
Dynamically finding and loading files from the Driver Store
In some scenarios, a driver package may contain a file that is intended to be loaded by a binary in another driver
package or by a user mode component.
Here are a couple of examples:
A user mode DLL provides an interface for communicating with a driver in the driver package.
An extension driver package contains a configuration file that is loaded by the driver in the base driver
package.
In these situations, the driver package should set some state indicating the path of the file or a device interface
exposed by the device.
For example, the driver package could use an HKR AddReg to set this state. For this example, it should be
assumed that for ExampleFile.dll , the driver package has a SourceDisksFiles entry with no subdir. This
results in the file being at the root of the driver package directory, and the DestinationDirs for a CopyFiles
directive specifies dirid 13.
Here is an INF example for setting this as device state:
[ExampleDDInstall.HW]
AddReg = Example_DDInstall.AddReg
[Example_DDInstall.AddReg]
HKR,,ExampleValue,,%13%\ExampleFile.dll
An INF example for setting this as device interface state would be:
[ExampleDDInstall.Interfaces]
AddInterface = {<fill in an interface class GUID for an interface exposed by the
device>},,Example_Add_Interface_Section
[Example_Add_Interface_Section]
AddReg = Example_Add_Interface_Section.AddReg
[Example_Add_Interface_Section.AddReg]
The previous examples use an empty flags value, which results in a REG_SZ registry value. This results in the
%13% being turned into a fully qualified user mode file path. In many cases, it is preferable to have the path be
relative to an environment variable. If a flags value of 0x20000 is used, the registry value is of type
REG_EXPAND_SZ and the %13% converts to a path with appropriate environment variables to abstract the
location of the path. When retrieving this registry value, call ExpandEnvironmentStrings to resolve the
environment variables in the path.
If the value needs to be read by a kernel mode component, the value should be a REG_SZ value. When the
kernel mode component reads that value, it should prepend \??\ before passing it to APIs such as
ZwOpenFile .
To access this setting when it is part of the device's state, first the application must find the identity of the device.
User mode code can use CM_Get_Device_ID_List_Size and CM_Get_Device_ID_List to get a list of devices,
filtered as necessary. That list of devices might contain multiple devices, so search for the appropriate device
before reading state from the device. For example, call CM_Get_DevNode_Proper ty to retrieve properties on
the device when looking for a device matching specific criteria.
Once the correct device is found, call CM_Open_DevNode_Key to get a handle to the registry location where
the device state was stored.
Kernel mode code should retrieve a PDO (physical device object) and call IoOpenDeviceRegistr yKey .
To access this setting when it is device interface state, User mode code can call
CM_Get_Device_Interface_List_Size and CM_Get_Device_Interface_List .
Additionally CM_Register_Notification can be used to be notified of arrivals and removals of device
interfaces so the code gets notified when the interface is enabled and then can retrieve the state. There may be
multiple device interfaces in the device interface class used in the above APIs. Examine those interfaces to
determine which is the correct interface for the setting to read.
Once the correct device interface is found, call CM_Open_Device_Interface_Key .
Kernel mode code can retrieve a symbolic link name for the device interface from which to get state. To do so,
call IoRegisterPlugPlayNotification to register for device interface notifications on the appropriate device
interface class. Alternatively, call IoGetDeviceInterfaces to get a list of current device interfaces on the system.
There may be multiple device interfaces in the device interface class used in the above APIs. Examine those
interfaces to determine which is the correct interface that should have the setting to be read.
Once the appropriate symbolic link name is found, call IoOpenDeviceInterfaceRegistr yKey to retrieve a
handle to the registry location where the device interface state was stored.
NOTE
Use the CM_GETIDLIST_FILTER_PRESENT flag with CM_Get_Device_ID_List_Size and CM_Get_Device_ID_List or the
CM_GET_DEVICE_INTERFACE_LIST_PRESENT flag with CM_Get_Device_Interface_List_Size and
CM_Get_Device_Interface_List . This ensures that hardware is present and ready for communication.
Using Device Interfaces

When state needs to be shared between drivers, there should be a single driver that owns the shared state, and
it should expose a way for other drivers to read and modify that state.
Typically, the driver that owns the state exposes a device interface in a custom device interface class. When the
driver is ready for other drivers to have access to the state, it enables the interface. Other drivers can register for
device interface arrival notifications. To access the state, the custom device interface class can define one of two
contracts:
An I/O contract can be associated with that device interface class that provides a mechanism for accessing
the state. Other drivers use the enabled device interface to send I/O requests that conform to the contract.
A direct-call interface that gets returned via a query interface. Other drivers could send
IRP_MN_QUERY_INTERFACE to retrieve function pointers from the driver to call.
Alternatively, if the driver that owns the state allows direct access to the state, other drivers could access state by
using system-supplied functions for programmatic access to device interface state.
These interfaces or state (depending on sharing method used) need to be properly versioned so the driver
owning the state can be serviced independently of other drivers that access that state. Driver vendors cannot
rely on both drivers being serviced at the same time and staying at the same version.
Because devices and drivers controlling interfaces come and go, drivers and applications should avoid calling
IoGetDeviceInterfaces at component start-up to get a list of enabled interfaces.
Instead, the best practice is to register for notifications of device interface arrival or removal and then call the
appropriate function to get the list of existing enabled interfaces on the machine.
For more information about device interfaces, see:
Using Device Interfaces
Registering for Notification of Device Interface Arrival and Device Removal
Registering for Device Interface Change Notification
Reading and Writing State

NOTE
If your component is using device or device interface properties to store state, continue to use that method and the
appropriate OS API's to store and access state. The following guidance is for other state that needs to be stored by a
component.
Access to various state should be done by calling functions that provide a caller with the location of the state
and then the state is read/written relative to that location. Do not use hardcoded absolute registry paths and file
paths.
This section contains the following subsections:
PnP Device Registry State
Device Interface Registry State
Service Registry State
Device File State
Service File State
PnP Device Registry State
Isolated driver packages and user-mode components typically use two locations to store device state in the
registry. These are the hardware key (device key) for the device and the software key (driver key) for the device.
To retrieve a handle to these registry locations, use one of the following options, based on the platform you are
using:
IoOpenDeviceRegistr yKey (WDM)
WdfDeviceOpenRegistr yKey , WdfFdoInitOpenRegistr yKey (WDF)
CM_Open_DevNode_Key (user-mode code)
INF AddReg directive using HKR reg-root entries in an add-registry-section referenced from an INF
DDInstall section or DDInstall.HW section, as shown below:
[ExampleDDInstall.HW]
AddReg = Example_DDInstall.AddReg
[Example_DDInstall.AddReg]
Device Interface Registry State

Use device interfaces to share state with other drivers and components. Do not hardcode paths to global
registry locations.
To read and write device interface registry state, use one of the following options, based on the platform you are
using:
IoOpenDeviceInterfaceRegistr yKey (WDM)
CM_Open_Device_Interface_Key (user-mode code)
INF AddReg directive using HKR reg-root entries in an add-registry-section referenced from an add-
interface-section section
Service Registry State
Registry values that are set by the INF for driver and Win32 services should be stored under the "Parameters"
subkey of the service by providing an HKR line in an AddReg section, and then referencing that section in the
service install section in the INF. For example:
[ExampleDDInstall.Services]
Addservice = ExampleService, 0x2, Example_Service_Inst
[Example_Service_Inst]
DisplayName = %ExampleService.SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %13%\ExampleService.sys
AddReg=Example_Service_Inst.AddReg
[Example_Service_Inst.AddReg]
HKR, Parameters, ExampleValue, 0x00010001, 1
To access the location of this state, use one of these functions, based on your platform:
IoOpenDriverRegistr yKey (WDM) with a DRIVER_REGKEY_TYPE of DriverRegKeyParameters
WdfDriverOpenParametersRegistr yKey (WDF)
GetSer viceRegistr yStateKey (Win32 Services) with a SERVICE_REGISTRY_STATE_TYPE of
ServiceRegistryStateParameters
These registry values supplied by the INF in the “Parameters” subkey for the service should not be modified at
runtime and should be treated as read only. Registry values that are written at runtime should be written under
a different location. To access the location for state to be written at runtime, use one of these functions:
IoOpenDriverRegistr yKey (WDM) with a DRIVER_REGKEY_TYPE of DriverRegKeyPersistentState
WdfDriverOpenPersistentStateRegistr yKey (WDF)
GetSer viceRegistr yStateKey (Win32 Services) with a SERVICE_REGISTRY_STATE_TYPE of
ServiceRegistryStatePersistent
Device File State
If files related to a device need to be written, those files should be stored relative to a handle or file path
provided via OS API’s. Configuration files specific to that device is one example of what types of files to be
stored here.
IoGetDeviceDirector y (WDM) with the Director yType parameter set to DeviceDirector yData
WdfDeviceRetrieveDeviceDirector yString (WDF)
Service File State
Both Win32 and driver services read and write state about themselves.
To access its own internal state values, a service uses one of the following options:
IoGetDriverDirector y (WDM) with the Director yType parameter set to DeviceDirector yData
IoGetDriverDirector y (KMDF) with the Director yType parameter set to DeviceDirector yData
WdfDriverRetrieveDriverDataDirector yString (UMDF)
GetSer viceDirector y (Win32 Services) with the eDirector yType parameter set to
Ser viceDirector yPersistentState
To share internal state of the service with other components, use a controlled, versioned interface instead of
direct registry or file reads.
DriverData and ProgramData

Files that are to be used as part of intermediate operations that can be shared with other components should be
written to either DriverData or ProgramData locations.
These locations offer components a location to write temporary state or state that is meant to be consumed by
other components and potentially collected and copied from a system to be processed by another system. For
example, custom log files or crash dumps fit this description.
Avoid writing files in the root of the DriverData or ProgramData directories. Instead, create a subdirectory with
your company name and then write files and further subdirectories within that directory.
For example, for a company name of Contoso, a kernel-mode driver could write a custom log to
\DriverData\Contoso\Logs and a user-mode application could collect or analyze the log files from
%DriverData%\Contoso\Logs .
DriverData
The DriverData directory is available in Windows 10, version 1803 and later, and is accessible to administrators
and UMDF drivers.
Kernel-mode drivers access the DriverData directory by using a system-supplied symbolic link called
\DriverData . User-mode programs access the DriverData directory by using the environment variable
%DriverData% .
ProgramData
The %ProgramData% user-mode environment variable is available for user-mode components to use when
storing data.
API Layering
Overview
API Layering requires that binaries in Windows Driver packages call only those APIs and DDIs that are included
in UWP-based editions of Windows 10 or are from a curated set of Win32 APIs. API Layering is an extension of
the previous "U" requirement that was a part of DCHU design principles.
To see which platform an API supports, visit the documentation page for the API and examine the Target
Platform entry of the Requirements section. Windows Drivers must only use APIs or DDIs that have a Target
Platform listed as Universal , meaning the subset of functionality that is available on all Windows offerings.
The Windows API Sets page describes a set of best practices and tools for determining whether an API is
available for Windows 10X development.
Validating API Layering

ApiValidator is the main tool used to validate API Layering compliance for Windows Drivers. ApiValidator ships
as part of the Windows Driver Kit (WDK).
See Validating Windows Drivers for more details on using ApiValidator to verify that a Windows Driver meets
the API Layering requirement.
Building a Windows driver
You can use Microsoft Visual Studio 2019 in conjunction with the Windows Driver Kit (WDK) Version 2004 to
build Windows Drivers. You can download kits and tools from the Windows Hardware Dev Center.
In many cases, you can recompile a legacy kernel-mode driver as a Windows Driver, as long as the driver does
not work with any user-mode components. Legacy WDM and KMDF drivers should recompile as Windows
Drivers targeting Windows 10 with no conversion required. While the drivers may compile without any
conversion, this does not mean that the driver meets all of the Windows Drivers requirements. Please see
Getting Started with Windows Drivers for details regarding Windows Drivers requirements.
In contrast, existing user-mode drivers may require modification to compile as Windows drivers. Specifically,
your driver package must not have any dependencies outside of UWP. For example, only some of the Win32
APIs are part of UWP.
Converting an existing driver project to a Windows driver project

1. In Visual Studio 2019, open the existing driver project.
2. In the Solution Explorer pane, select and hold (or right-click) the solution and choose Configuration
Manager . Set the target operating system to Windows 10.
3. Select and hold (or right-click) the driver project and choose Proper ties . Under Configuration
Proper ties->Driver , verify that Target Platform is set to Windows Drivers . To build a driver that runs on
Windows 10 for Desktop editions only, select Desktop .
4. Build the driver. You might see linker errors.
5. Fix the errors one by one by going through the error log. Refer to individual reference pages in the
documentation for possible alternate APIs. If replacements are not available, you may need to redesign your
driver.
Creating a New Windows Driver Project in Microsoft Visual Studio

1. Create a new driver from a template (File->New Project->Create New Project->Project Type-
>Driver->Select the template of interest ).
2. After you create the project, in the Solution Explorer pane, select and hold (or right-click) the solution and
choose Configuration Manager . Set Active solution configuration to the desired target Windows
version, and set Active solution platform to Win32 or x64 . If ARM is not listed, choose <New...> to
build for ARM.
If you choose Windows 10, the driver model defaults to Universal .
To change driver model manually, select and hold (or right-click) the driver project and choose Properties.
Under Configuration Proper ties->Driver Settings->General , find the Target Platform entry.
Choose Windows Driver . Microsoft Visual Studio uses this setting to determine what libraries to link
against.
Note You cannot build a Windows Driver for Windows versions earlier than Windows 10 Version 1809.
3. You might need to modify the .inf file to specify the provider, specified as an %ManufacturerName%
token that is expanded later in the INF file's Strings section. For example:
Provider="Contoso"
4. You can now build the solution. Visual Studio links against the required libraries and generates a .cat file,
an .inf file, and a driver binary.
Creating a New Universal Application or DLL Project in Microsoft

Visual Studio
1. Create a new driver from a template (File->New Project->Create New Project->Project Type-
>Driver->Select the template of interest ) and choose Empty Desktop Application for Drivers
(Universal) or Empty Dll for Drivers (Universal) .
2. After you create the project, in the Solution Explorer pane, select and hold (or right-click) the solution and
choose Configuration Manager . Set Active solution configuration to the desired target Windows
version, and set Active solution platform to Win32 or x64 . If ARM is not listed, choose <New...> to build
for ARM. If you choose Windows 10, the application model defaults to Universal . To change the target
platform manually, select and hold (or right-click) the driver project and choose Properties. Under
Configuration Proper ties->Driver Settings->General , find the Target Platform entry.
3. Build the solution.
For information about the configuration settings you can use in Visual Studio when building your driver, see
Building a Driver with the WDK.
Use the InfVerif, Driver Verifier Driver Isolation Checks, and ApiValidator tools to test your Windows Driver for
compliance with the requirements described in Getting Started with Windows Drivers.
InfVerif
InfVerif is a tool that validates INF syntax and checks that the INF conforms to requirements and restrictions.
Use InfVerif with /w and /v to verify that a Windows Driver:
Meets the declarative (D) principle of DCH Design Principles
Complies with the driver package isolation requirement of Getting Started with Windows Drivers
For more details, see Running InfVerif from the command line.
Targeting current and earlier versions of Windows
Each run of InfVerif tests a single ruleset, for example /w (Windows driver compatibility) or /k (Hardware Dev
Center submission). If your INF contains syntax introduced in a more recent version of Windows and you also
want to target previous Windows versions, use INF decorations to mark version-specific INF entries and then
run InfVerif multiple times, for example:
infverif /k <INF file>

infverif /w NTAMD64.10.0.0.<build number where w is a requirement> <INF file>
If there are no errors, the INF meets the Driver Package Isolation requirement of Windows Drivers.
For example, the INF AddEventProvider Directive is available starting in Windows 10, version 1809. To use this
directive in an INF targeting an OS version before Windows 10, version 1809, decorate both the install section
using legacy INF syntax for registering ETW event providers as well as the install section using the updated
syntax.
For sample code showing how to use OS decorations, see Sample INF Models Sections for One or More Target
Operating Systems.
Driver Verifier Driver Isolation Checks

To qualify as a Windows Driver, a driver must meet Driver Package Isolation requirements. Starting in Windows
10 Preview Build 19568, Driver Verifier (DV) monitors registry reads and writes that are not allowed for isolated
driver packages.
You can either view violations as they happen in a kernel debugger, or you can configure DV to halt the system
and generates a memory dump with details when a violation occurs. You might start driver development with
the first method, then switch to the second as your driver nears completion.
To view violations as they occur, first connect a kernel debugger and then use the following commands. After a
reboot has enabled the DV settings, you can monitor violations in kernel debugger output.
To enable driver isolation checks on a single driver:
verifier /rc 33 36 /driver myDriver.sys
To check more than one driver, separate each driver name with a space:
verifier /rc 33 36 /driver myDriver1.sys myDriver2.sys
To configure DV to bugcheck when a violation occurs, use the following syntax:
verifier /onecheck /rc 33 36 /driver myDriver1.sys
You'll need to reboot to enable the verification settings. To do this from the command line, specify:
shutdown /r /t 0
Here are a few examples of error messages:

Example: ZwCreateKey provides full absolute path:
DRIVER_ISOLATION_VIOLATION: <driver name>: Registry operations should not use absolute paths. Detected
creation of unisolated registry key \Registry\Machine\SYSTEM
Example: ZwCreateKey provides path relative to a handle that is not from an approved API:
DRIVER_ISOLATION_VIOLATION: <driver name>: Registry operations should only use key handles returned from WDF
or WDM APIs. Detected creation of unisolated registry key \REGISTRY\MACHINE\SYSTEM\SomeKeyThatShouldNotExist
Consider enabling Device Fundamentals tests with DV driver isolation checks to help catch driver isolation
violations early.
ApiValidator
The ApiValidator tool verifies that the APIs that your binaries call are valid for a Windows Driver. The tool returns
an error if your binaries call an API that is outside the set of valid APIs for Windows Drivers. This tool is part of
the WDK for Windows 10.
ApiValidator validates that a driver supports API Layering, one of the requirements for Windows Drivers. For a
full list of requirements, see Getting Started with Windows Drivers.
Running ApiValidator in Visual Studio
If the Target Platform property of your driver project is set to Windows Driver , Visual Studio runs
ApiValidator automatically as a post-build step.
To view all the messages displayed by ApiValidator, navigate to Tools->Options->Projects and Solutions-
>Build and Run , and set MSBuild project build output verbosity to Detailed . When building from the
command line, add the switch /v:detailed or /v:diag to your build command to increase the verbosity.
For the umdf2_fx2 driver sample, API validation errors look this:
Warning 1 warning : API DecodePointer in kernel32.dll is not supported. osrusbfx2um.dll calls this API.
C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\ApiValidator.exe osrusbfx2um
Warning 2 warning : API DisableThreadLibraryCalls in kernel32.dll is not supported. osrusbfx2um.dll calls
this API. C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\ApiValidator.exe osrusbfx2um
Warning 3 warning : API EncodePointer in kernel32.dll is not supported. osrusbfx2um.dll calls this API.
C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\ApiValidator.exe osrusbfx2um
Warning 4 warning : API GetCurrentProcessId in kernel32.dll is not supported. osrusbfx2um.dll calls this
API. C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\ApiValidator.exe osrusbfx2um
Warning 5 warning : API GetCurrentThreadId in kernel32.dll is not supported. osrusbfx2um.dll calls this
Warning 6 warning : API GetSystemTimeAsFileTime in kernel32.dll is not supported. osrusbfx2um.dll calls
Warning 7 warning : API IsDebuggerPresent in kernel32.dll is not supported. osrusbfx2um.dll calls this
Warning 8 warning : API IsProcessorFeaturePresent in kernel32.dll is not supported. osrusbfx2um.dll calls
Warning 9 warning : API QueryPerformanceCounter in kernel32.dll is not supported. osrusbfx2um.dll calls
Error 10 error MSB3721: The command ""C:\Program Files (x86)\Windows Kits\10\bin\x64\ApiValidator.exe" -
DriverPackagePath:"C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\Debug\\" -
SupportedApiXmlFiles:"C:\Program Files (x86)\Windows Kits\10\build\universalDDIs\x86\UniversalDDIs.xml" -
ApiExtractorExePath:"C:\Program Files (x86)\Windows Kits\10\bin\x64"" exited with code -1. C:\Program
Files (x86)\Windows Kits\10\build\WindowsDriver.common.targets 1531 5 osrusbfx2um
Fixing validation errors

1. If you switched a legacy desktop UMDF driver project to Windows Driver, verify that you are including the
correct libraries when building your binaries. Select and hold (or right-click) the project and choose
properties. Navigate to Linker->Input . The Additional Dependencies should contain:
%AdditionalDependencies);$(SDK_LIB_PATH)\OneCoreUAP.lib
To review other linker options for targeting OneCore SKUs, see Building for OneCore.
2. Remove or replace API calls that are not permitted one at a time and rerun the tool until there are no
errors.
3. In some cases, you can replace these calls with alternate DDIs that are listed on the reference pages for
the desktop-only DDI. You may have to code a workaround if there is not a suitable replacement. If you
need to, write a new Windows Driver starting from the driver templates in the WDK.
If you see errors like the following, please refer to the guidance in Building for OneCore.
ApiValidation: Error: FlexLinkTest.exe has a dependency on 'wtsapi32.dll!WTSEnumerateSessionsW' but is

missing: IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0")
ApiValidation: Error: FlexLinkTest.exe has a dependency on 'wtsapi32.dll!WTSFreeMemory' but is missing:
IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0")
ApiValidation: NOT all binaries are Universal
Running ApiValidator from the Command Prompt

You can also run Apivalidator.exe from the command prompt. In your WDK installation, navigate to C:\Program
Files (x86)\Windows Kits\10\bin<arch> and C:\Program Files (x86)\Windows
Kits\10\build\universalDDIs<arch> .
Impor tant Notes:
ApiValidator requires the following files: ApiValidator.exe, Aitstatic.exe, Microsoft.Kits.Drivers.ApiValidator.dll,
and UniversalDDIs.xml.
The UniversalDDIs.xml must match the binary architecture being validated, for example for an x64 driver use
the x64 UniversalDDI.xml
ApiValidator only tests one architecture at a time
See Known ApiValidator issues below for additional info
Use the following syntax:
Apivalidator.exe -DriverPackagePath: <driver folder path> -SupportedApiXmlFiles: (path to XML files
containing supported APIs for Windows drivers)
For example, to verify the APIs called by the Activity sample in the WDK, first build the sample in Visual Studio.
Then open a command prompt and navigate to the directory containing the tool, for example
C:\Program Files (x86\Windows Kits\10\bin\x64 . Enter the following command:
apivalidator.exe -DriverPackagePath:"C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2\_fx2\Debug" -

SupportedApiXmlFiles:"c:\Program Files (x86)\Windows Kits\10\build\universalDDIs\x64\UniversalDDIs.xml"
The command produces the following output:
ApiValidator.exe: Warning: API DecodePointer in kernel32.dll is not supported. osrusbfx2um.dll calls this
API.
ApiValidator.exe: Warning: API DisableThreadLibraryCalls in kernel32.dll is not supported. osrusbfx2um.dll
calls this API.
ApiValidator.exe: Warning: API EncodePointer in kernel32.dll is not supported. osrusbfx2um.dll calls this
API.
ApiValidator.exe: Warning: API GetCurrentProcessId in kernel32.dll is not supported. osrusbfx2um.dll calls
this API.
ApiValidator.exe: Warning: API GetCurrentThreadId in kernel32.dll is not supported. osrusbfx2um.dll calls
this API.
ApiValidator.exe: Warning: API GetSystemTimeAsFileTime in kernel32.dll is not supported. osrusbfx2um.dll
calls this API.
ApiValidator.exe: Warning: API IsDebuggerPresent in kernel32.dll is not supported. osrusbfx2um.dll calls
this API.
ApiValidator.exe: Warning: API IsProcessorFeaturePresent in kernel32.dll is not supported. osrusbfx2um.dll
calls this API.
ApiValidator.exe: Warning: API QueryPerformanceCounter in kernel32.dll is not supported. osrusbfx2um.dll
calls this API.
ApiValidator.exe Driver located at C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\Debug is NOT a

Universal Driver
Troubleshooting ApiValidator
If ApiValidator.exe outputs an incorrect format error such as the following:
Error 1 error : AitStatic output file has incorrect format or analysis run on incorrect
file types. C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\ApiValidator.exe
osrusbfx2um
Use this workaround:

1. Open Project properties, navigate to General , and rename Output Director y to the following:
$(SolutionDir)$(Platform)\$(ConfigurationName)\
2. Rebuild the solution.

Known ApiValidator Issues
ApiValidator does not run on ARM64 because AitStatic does not work on ARM64.
ARM64 binaries can be tested on x64 machines but not on an x86 machine.
ApiValidator can run on x86 to test x86 binaries and ARM binaries.
ApiValidator can run on x64 to test x86, x64, ARM, and ARM64 binaries.
DCH-Compliant Driver Package Example
This topic describes how the DCHU driver sample applies DCH design principles. You can use it as a model to
apply DCH design principles to your own driver package.
If you would like a local copy of the sample repo, clone from Windows-driver-samples.
Some portions of the sample may use directives and APIs that are only available on certain versions of
Windows 10 and above. Please refer to Device and Driver Installation to see what OS version a given directive is
supported on.
Prerequisites
Before you read this section, you should become familiar with the DCH Design Principles.
Overview
The sample provides example scenarios where two hardware partners, Contoso (a system builder, or OEM) and
Fabrikam (a device manufacturer, or IHV) are working together to create a driver that is DCH-compliant for a
device in Contoso's upcoming system. The device in question is an OSR USB FX2 learning kit. In the past,
Fabrikam would write a legacy driver package that was customized to a specific Contoso product line, and then
hand it to the OEM to handle servicing. This resulted in significant maintenance overhead, so Fabrikam decided
to refactor the code and create a DCH-compliant driver package instead.
Use declarative sections/directives and properly isolate INF

First, Fabrikam reviews the list of INF sections and directives that are invalid in DCH-compliant driver packages.
During this exercise, Fabrikam notices that they're using many of these sections and directives in their driver
package.
Their driver INF registers a co-installer that applies platform-dependent settings and files. This means that the
driver package is larger than it should be, and it is harder to service the driver when a bug affects only a subset
of the OEM systems that ship the driver. Also, most of the OEM-specific modifications are related to branding, so
Fabrikam needs to update the driver package every time an OEM is added or when a minor issue affects a
subset of OEM systems.
Fabrikam removes the non-declarative sections and directives and uses the InfVerif tool to verify that the new
driver package's INF file follows the declarative INF requirement.
Use extension INFs to componentize a driver package

Next, Fabrikam separates customizations that are specific to OEM partners (such as Contoso) from the base
driver package into an extension INF.
The following snippet, updated from [ osrfx2_DCHU_extension.inx ], specifies the Extension class and identifies
Contoso as the provider since they will own the extension driver package:
[Version]
Class = Extension
ClassGuid = {e2f84ce7-8efa-411c-aa69-97454ca4cb57}
Provider = Contoso
ExtensionId = {zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz} ; replace with your own GUID
In [ osrfx2_DCHU_base.inx ], Fabrikam specifies the following entries:
[OsrFx2_AddReg]
HKR, OSR, "OperatingMode",, "Default" ; FLG_ADDREG_TYPE_SZ
HKR, OSR, "OperatingParams",, "None" ; FLG_ADDREG_TYPE_SZ
In [ osrfx2_DCHU_extension.inx ], Contoso overrides the OperatingParams registry value set by the base and
adds OperatingExceptions :
[OsrFx2Extension_AddReg]
HKR, OSR, "OperatingParams",, "-Extended"
HKR, OSR, "OperatingExceptions",, "x86"
Note that extensions are always processed after the base INF but in no definite order. If a base INF is updated to
a newer version, then the extensions will still be re-applied after the new base INF is installed.
Install a service from an INF file

Fabrikam uses a Win32 service to control the LEDs on the OSR board. They view this component as part of the
core functionality of the device, so they include it as part of their base INF ([ osrfx2_DCHU_base.inx ]). This user-
mode service (usersvc) can be added and started declaratively by specifying the AddSer vice directive in the
INF file:
[OsrFx2_Install.NT]
CopyFiles = OsrFx2_CopyFiles
[OsrFx2_Install.NT.Services]
AddService = WUDFRd, 0x000001fa, WUDFRD_ServiceInstall ; Flag 0x2 sets this as the service for the device
AddService = osrfx2_DCHU_usersvc,, UserSvc_ServiceInstall
[UserSvc_ServiceInstall]
DisplayName = %UserSvcDisplayName%
ServiceType = 0x10 ; SERVICE_WIN32_OWN_PROCESS
StartType = 0x3 ; SERVICE_DEMAND_START
ErrorControl = 0x1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %13%\osrfx2_DCHU_usersvc.exe
AddTrigger = UserSvc_AddTrigger ; AddTrigger syntax is only available in Windows 10
Version 2004 and above
[UserSvc_AddTrigger]
TriggerType = 1 ; SERVICE_TRIGGER_TYPE_DEVICE_INTERFACE_ARRIVAL
Action = 1 ; SERVICE_TRIGGER_ACTION_SERVICE_START
SubType = %GUID_DEVINTERFACE_OSRFX2% ; Interface GUID
DataItem = 2, "USB\VID_0547&PID_1002" ; SERVICE_TRIGGER_DATA_TYPE_STRING
[OsrFx2_CopyFiles]
osrfx2_DCHU_base.dll
osrfx2_DCHU_filter.dll
osrfx2_DCHU_usersvc.exe
Note that such a service could also be installed in a component or extension INF, depending on the scenario.
Use a component to install legacy software from a driver package
Fabrikam has an executable file osrfx2_DCHU_componentsoftware.exe that they previously installed using a co-
installer. This legacy software displays the registry keys set by the board and is required by the OEM. This is a
GUI-based executable that only runs on Windows for desktop editions. To install it, Fabrikam creates a separate
component driver package and adds it in their extension INF.
The following snippet from [ osrfx2_DCHU_extension.inx ] uses the AddComponent directive to create a virtual
child device:
[OsrFx2Extension_Install.NT.Components]
AddComponent = osrfx2_DCHU_component,,OsrFx2Extension_ComponentInstall
[OsrFx2Extension_ComponentInstall]
ComponentIds=VID_045e&PID_94ab
Then, in the component INF [ osrfx2_DCHU_component.inx ], Fabrikam specifies the AddSoftware directive to
install the optional executable:
[OsrFx2Component_Install.NT.Software]
AddSoftware = osrfx2_DCHU_componentsoftware,, OsrFx2Component_SoftwareInstall
[OsrFx2Component_SoftwareInstall]
SoftwareType = 1
SoftwareBinary = osrfx2_DCHU_componentsoftware.exe
SoftwareArguments = <<DeviceInstanceId>>
SoftwareVersion = 1.0.0.0
[OsrFx2Component_CopyFiles]
osrfx2_DCHU_componentsoftware.exe
The source code for the Win32 app is included in the sample.
Note that the component driver package is only distributed on Desktop SKUs due to targeting set in the
Windows Hardware Dev Center dashboard. For more info, see Publish a driver to Windows Update.
Allow communication with a hardware support app

Fabrikam would like to provide a GUI-based companion app as part of the Windows Driver package. Because
Win32-based companion applications cannot be part of a Windows Driver package, they port their Win32 app
to the Universal Windows Platform (UWP) and pair the app with the device.
The following snippet from osrfx2_DCHU_base/device.c shows how the base driver package adds a custom
capability to the device interface instance:
WDF_DEVICE_INTERFACE_PROPERTY_DATA PropertyData = { 0 };
static const wchar_t customCapabilities[] = L"CompanyName.yourCustomCapabilityName_YourStorePubId\0";
WDF_DEVICE_INTERFACE_PROPERTY_DATA_INIT(&PropertyData,
&GUID_DEVINTERFACE_OSRUSBFX2,
&DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities);
Status = WdfDeviceAssignInterfaceProperty(Device,
&PropertyData,
DEVPROP_TYPE_STRING_LIST,
sizeof(customCapabilities),
(PVOID)customCapabilities);
The new app (not included in the sample) is secure and can be updated easily in the Microsoft Store. With the
UWP application ready, Contoso uses DISM - Deployment Image Servicing and Management to pre-load the
application on Windows Desktop edition images.
Tightly coupling multiple INF files

Ideally, there should be strong versioning contracts between base, extensions, and components. There are
servicing advantages in having these three packages serviced independently (the "loosely coupled" scenario),
but there are scenarios where they need to be bundled in a single driver package ("tightly coupled") due to poor
versioning contracts. The sample includes examples of both scenarios:
DCHU_Sample\osrfx2_DCHU_extension_loose
DCHU_Sample\osrfx2_DCHU_extension_tight
When the extension and component are in the same driver package ("tightly coupled"), the extension INF
specifies the CopyINF directive to cause the component INF to be copied to the target system. This is
demonstrated in
DCHU_Sample\osrfx2_DCHU_extension_tight\osrfx2_DCHU_extension\osrfx2_DCHU_extension.inx:
[OsrFx2Extension_Install.NT]
CopyInf=osrfx2_DCHU_component.inf
This directive can also be used to coordinate installation of INF files in multifunction devices. For more details,
see Copying INF files.
NOTE
While a base driver can payload an extension (and target the base driver in the shipping label), an extension bundled with
another driver cannot be published to the extension hardware ID.
Run from the driver store

To make it easier to update the driver, Fabrikam specifies the Driver Store as the destination to copy the driver
files by using dirid 13 where possible. Using a destination directory value of 13 can result in improved stability
during the driver update process. Here is an example from [ osrfx2_DCHU_base.inx ]:
[DestinationDirs]
OsrFx2_CopyFiles = 13 ; copy to Driver Store
See the driver package isolation page for more details regarding how to dynamically find and load files from the
Driver Store.
Summary
The following diagram shows the driver packages that Fabrikam and Contoso created for their DCH-compliant
driver. In the loosely coupled example, they will make three separate submissions on the Windows Hardware
Dev Center dashboard: one for the base, one for the extension, and one for the component. In the tightly
coupled example, they will make two submissions: base and extension/component.
Note that the component INF will match on the component hardware ID, whereas the base and extensions will
match on the board's hardware ID.
See also
Using an Extension INF File
osrfx2_DCHU_base.inx
"loosely coupled" osrfx2_DCHU_component.inx
"loosely coupled" osrfx2_DCHU_extension.inx
"tightly coupled" osrfx2_DCHU_component.inx
"tightly coupled" osrfx2_DCHU_extension.inx
Debugging a Windows Driver
For general information about debugging drivers, see Getting Started with Windows Debugging.
Inflight Trace Recorder

Starting in Windows 10, you can build your KMDF or UMDF driver binary so that it gets additional driver
debugging information through the Inflight Trace Recorder. Windows Drivers can take advantage of this feature.
In addition, if you used the Visual Studio KMDF template, your driver uses Windows software trace preprocessor
(WPP) to write trace messages. Your driver binary is an ETW provider with a provider GUID.
To send a trace message from your driver binary, use this code:
TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DRIVER, "%!FUNC! Entry");
You can access the ETW logs using Tracelog by using !wmitrace in a debugger session.
In this topic we explain how to use Visual Studio to start writing a new device function driver. Device function
drivers are different from filter drivers, software drivers, and file system drivers, which we cover in other topics.
To learn about device function drivers and how they differ from other types of drivers, see What is a Driver?,
Choosing a Driver Model, and Device Nodes and Device Stacks.
To begin, first determine where your device fits in the list of technologies described in Device and Driver
Technologies. To learn about which driver models are available for your device, see the documentation for that
particular technology. The recommended driver model varies from one technology to the next. For some
technologies, the documentation recommends using the User Mode Driver Framework (UMDF) or the Kernel
Mode Driver Framework (KMDF). For other technologies, the documentation explains how to create a minidriver
that is part of a driver pair. Minidrivers go by a variety of names, including miniport and miniclass.
Next, determine which of the following cases describes your driver model recommendation and follow the
steps:
Case 1: The documentation for your technology recommends UMDF.
1. In Visual Studio, on the File menu, choose New | Project .
2. In the New Project dialog box, in the left pane, locate and select Visual C++ | Windows Driver | WDF .
3. In the middle pane, select User Mode Driver (UMDF) .
4. Fill in the Name and Location boxes, and select OK . For more details, see Writing a UMDF Driver Based on a
Template. Note When you create a new UMDF driver, you must select a driver name that has 32 characters
or less. This length limit is defined in wdfglobals.h.
5. At this point, you have a driver project that implements the general code required by most UMDF drivers.
Now you can supply the code that is specific to your device. Refer to the documentation for your technology
to learn about the interfaces that you need to implement.
Case 2: The documentation for your technology recommends KMDF.
2. In the New Project dialog box, in the left pane, locate and select WDF .
3. In the middle pane, select Kernel Mode Driver (KMDF) .
4. Fill in the Name and Location boxes, and select OK . For more details, see Writing a KMDF Driver Based on a
Template. Note When you create a new KMDF driver, you must select a driver name that has 32 characters
or less. This length limit is defined in wdfglobals.h.
5. At this point, you have a driver project that implements the general code required by most KMDF drivers.
Now you can supply the code that is specific to your device. Refer to the documentation for your technology
to learn about the methods that you need to implement.
Case 3: The documentation for your technology describes a minidriver model.
If your device technology has a miniport, miniclass, or some other kind of minidriver model, check to see if
Visual Studio has a specific template for the model.
2. In the New Project dialog box, in the left pane, locate and select Templates | Visual C++ | Windows
Driver .
3. Browse the list of installed templates to find a template for the type of minidriver you need to write.
4. If there is no template for your type of minidriver under Windows Driver , select Online and browse the
templates that are available online.
5. If you find a template for your type of minidriver, select the template, fill in the Name and Location boxes,
and select OK .
6. At this point, you have a driver project that implements the general code required by your minidriver. Now
you can supply the code that is specific to your device. Refer to the documentation for your technology to
learn about the functions that you need to implement.
If your device technology has a minidriver model, and you are not able to find a specific template for your type
of minidriver, the Windows Driver Model (WDM) template is most likely going to be your starting point. Refer to
your technology-specific documentation for guidance. In rare cases, you can use KMDF to write a minidriver, but
usually the starting point is WDM.
2. In Visual Studio, in the New Project dialog box, under Windows Driver , select WDM.
3. Fill in the Name and Location boxes, and select OK .
4. At this point, you have an empty WDM driver project. In the Solution Explorer window, select and hold (or
right-click) your driver project, and choose Add | New Item .
5. In the Add New Item dialog box, select C++ File (.cpp) , enter a name for your file, and select OK .
Note If you want to create a .c file instead of a .cpp file, enter a name that has the .c extension.
6. Refer to the documentation for your technology to learn about the functions that you need to implement.
As you implement and organize your functions, you might decide to add additional .cpp or .c files.
In this topic we explain how to use Visual Studio to start writing a new filter driver. Filter drivers are different
from device function drivers, software drivers, and file system drivers, which we cover in other topics. To learn
about filter drivers and how they differ from other types of drivers, see the following topics.
What is a Driver?
Choosing a Driver Model
Device Nodes and Device Stacks
Filter Drivers
Types of WDM Drivers
To begin, first determine which driver model is appropriate for your filter driver. For help determining which
model is best for you, see Choosing a Driver Model. If you are writing a filter driver for a hardware device,
determine where your device fits in the list of technologies described in Device and Driver Technologies. See the
documentation for that particular technology to see whether there is any guidance for choosing a filter driver
model. The recommended filter driver model varies from one technology to the next. For some technologies, the
documentation recommends using the User Mode Driver Framework (UMDF), the Kernel Mode Driver
Framework (KMDF), or the Windows Driver Model (WDM). For other technologies, the documentation gives
explicit details on how to write a filter driver. Some technologies have mini filter models. For some technologies,
there might not be any recommendation for a filter driver model.
Next, determine which of the following cases describes your driver model recommendation and follow the
steps:
Case 1: The documentation for your technology recommends UMDF.

2. In the New Project dialog box, in the left pane, locate and select Visual C++ | Windows Driver | WDF .
3. In the middle pane, select User Mode Driver (UMDF) .
4. Fill in the Name and Location boxes, and select OK . For more information, see Writing a UMDF Driver
Based on a Template. Note When you create a new UMDF driver, you must select a driver name that has 32
characters or less. This length limit is defined in wdfglobals.h.
5. At this point, you have a driver project that implements the general code required by most UMDF drivers.
Now you can supply the code that is specific to your filter.
Case 2: The documentation for your technology recommends KMDF.

4. Fill in the Name and Location boxes, and select OK . For more information, see Writing a KMDF Driver
Based on a Template. Note When you create a new KMDF driver, you must select a driver name that has 32
Now you can supply the code that is specific to your filter.
Case 3: The documentation for your technology describes a specific
filter or mini filter model.
If your device technology has a specific filter or minifilter model, check to see if Visual Studio has a template for
the model.
2. In the New Project dialog box, in the left pane, locate and select Templates | Visual C++ | Windows
Driver .
3. Browse the list of installed templates to see whether there is a template for the type of filter you need to
write. For example, you might choose the Filter Driver : NDIS template under Networking .
4. If there is no template for your type of filter driver under Windows Driver , select Online and browse the
templates that are available online.
5. If you find a template for your type of filter driver, select the template, fill in the Name and Location boxes,
and select OK .
6. At this point, you have a driver project that implements the general code required by your filter driver. Now
you can supply the code that is specific to your filter. Refer to the documentation for your technology to learn
about the functions that you need to implement.
If your device technology has a specific filter model or a minifilter model, and you can't find a template for your
type of filter driver, refer to your technology-specific documentation for guidance to determine whether to use
UMDF, KMDF, or WDM.
Case 4: The documentation for your technology recommends WDM.

Note If you want to create a .c file instead of a .cpp file, enter a name that has the .c extension.
6. Implement the functions required by your filter. As you implement and organize your functions, you
might decide to add additional .cpp or .c files.
Case 5: The documentation for your technology does not have a

recommendation for a filter driver model.
1. Determine whether UMDF, KMDF, or WDM is the best model for your filter driver. For help, see Choosing
a Driver Model.
3. In Visual Studio, in the New Project dialog box, under Windows Driver , select one of the following
templates:
WDF | User Mode Driver (UMDF)
WDF | Kernel Mode Driver (KMDF)
WDM | Empty Kernel Driver
Note When you create a new KMDF or UMDF driver, you must select a driver name that has 32
4. Implement the functions required by your filter. Create new .c or .cpp files as needed.
If you are not sure which template to use, consider reading or posting to the Windows Hardware WDK and
Driver Development forum.
Device filter driver ordering
Microsoft has developed a method of declaratively adding filters by expressing the intent of the filter, rather than
the stack position, known as device filter driver ordering.
The need for device filter driver ordering

Prior to Windows 10 version 1903, the only supported way to register a device filter driver was by addition of a
registry entry (using the AddReg directive). However, this method of registry manipulation does not provide the
flexibility to specify at exactly which position to register a particular filter.
Filter registration using the AddReg directive simply appends the filter to the end of the filter list. This approach
uses a list of values where order matters and determines where in the stack the filter is loaded.
Using a single list of ordered values is less than ideal, especially when AddReg only appends to the end, because
there are negative consequences when more than one driver is adding filters to the same device.
In the scenario where there is at least one Extension INF involved, if the INFs improperly use AddReg (in other
words don't use the append flag), they could wipe out a filter added by a different INF.
Additionally, multiple Extension INF's could be adding filters, and the relative ordering of those filters may be
important; however, the Plug and Play (PnP) platform does not guarantee an installation order for the
extensions. The result is that the order of the "appends" is not guaranteed.
Implementing device filter driver ordering

In order to provide a flexible declarative method to register device filters, Microsoft has developed a method of
declaratively adding filters by expressing the intent of the filter, rather than the stack position. The solution
provides function driver authors the ability to express in their INF an ordered set of positions (called
levels) that a filter may register itself against.
In addition to a specific level, a filter can declaratively register simply as an upper or lower level filter.
The infrastructure is based on a new filter registration method to determine what order drivers are to be
included in the device stack. The new method does not break compatibility for the old way of adding filters. It
does, however, enable new filters to move to a more robust and flexible registration mechanism.
The method is enabled by having the base INF define an ordered list of one or more "levels". Both the base INF
and any extension INFs may register a declarative filter via a new INF directive that specifies the service name
and level to which the filter belongs to. Upper and lower filters each are represented by their own respective
ordered list of levels.
These upper and lower filter lists are created by sorting all filter drivers by their level. The order of the filters
within each level should be considered arbitrary, where no dependency may be taken on the order of filters
within a particular level. In scenarios where the relative order of two filters must be guaranteed , they should be
registered to different levels.
Consider the following device driver example:
The device driver's base INF declares two upper filter levels, A and B (in that order). In the base INF's associated
Extension INF, two filters are added into each of the two levels.
The result of the installation of the device driver is a device stack order that merges the lists of filter drivers
while respecting the desired positioning and ordering. The resulting device stack order ensures that any filter
placed in the "A" level comes before any filter in the "B" level. However, within each level, the order is arbitrary.
As shown in the example, Filter3 could come before Filter5 or it could come after Filter5. In any case, Filter3 and
Filter5 will come before the filters at the next level, "B".
When designing the series of levels that filters can be registered against, rather than creating a series of levels
for the sake of ordering, the levels should be named and ordered such that they map to the intent of the filter.
For instance, an I/O device may define the level Encryption, to which any encryption filter should be registered.
This allows the intent of the filter to be easily understood and managed, and makes the stack more robust
against breaking changes to the function driver.
NOTE
Even without levels defined by the base INF, a declarative filter may register as simply upper or lower. When levels are not
defined, this is logically equivalent to appending the filter to the end of the UpperFilters/LowerFilters registry value. When
levels are defined, one of the levels must be marked as the default level in the base driver, and in this case the filter will be
registered into that level.
Scenarios
Consider an I/O device driver that encrypts the data that is coming through the stack. A typical implementation
may use a lower filter driver immediately underneath the function driver to accomplish this. In order to ensure
that the encryption filter is placed at the exact position the driver author desires, they may use declarative filters
as shown below:
The Base INF establishes two levels of lower filters, "Encryption" and "Monitoring" (Default). "Monitoring"
(Default) in this example are the rest of the lower filters that might exist for this particular device. By explicitly
placing the "Encrypt" filter driver in the "Encryption" level, the driver ensures that the resulting device stack
order will put the "Encrypt" filter driver before any other lower filters and immediately following the function
driver.
Let's take the example one step further. Imagine a newer version of the driver comes out and the author has
built in encryption to the function driver. This removes the need for a separate "Encrypt" filter driver. The author
simply needs to remove the level that contained the "Encrypt" filter from the Base INF and when the driver
updates, the stack is dynamically built again.
If a filter declares itself to be in an explicit level that does not exist, the filter does not end up in the device stack.
In the example, the Base INF has been updated and even though the Extension INF remains the same, the
resulting device stack excludes the "Encrypt" filter as it was not included in the Base INF's declaration of levels.
Default filter level

To generate the final filter stack, all sources of filter information are merged into a single list. It is important to
note that the merge logic is performed when creating the device stack . If a new filter is added by installing a
new/updated base or extension driver, the devices will be restarted during installation and pick up a new filter
list.
Some sources of filters lack any position information, namely filters added via the legacy
UpperFilters/LowerFilters registry values, or through position-only declarative syntax (discussed below).
To support an effective merge when lacking position information, an additional piece of information must be
defined by the Base INF: a default filter level. The default filter level is a position where filters, lacking level or
position information, will be inserted.
For example, filter levels may be defined in the Base INF as:
Level Order: A, B, C
DefaultFilterLevel: C
Specifying the default level as the final level indicates that any filter that lacking position information will be
appended to the filter list. Alternatively, the driver author may wish to have the stack always end with filters
explicitly registered to level C:
Level Order: A, B, C
DefaultFilterLevel: B
Due to the default filter level being set to B, any additional filter without position information will be inserted
between A's filters and C's filters.
Syntax
Registering filters
[DDInstall.Filters]
AddFilter = <FilterName>, [Flags], FilterSection
FilterLevel OR FilterPosition may be specified in one of two ways:

Option 1:
[FilterSection]
FilterLevel=<LevelName>
Option 2:
FilterPosition=Upper/Lower
This can be done in both Base and Extension INF's.

[DDInstall.Filters]
FilterName is the name of the service on the system.
Flags is currently unused and should be left empty or set to 0.
FilterSection is a section describing the filter.
[Filter Section]
A filter section must contain exactly one of the following two directives: FilterLevel or FilterPosition .
A FilterLevel is a specific place to insert the device filter on the stack, defined by the Base INF. Within each
level, the order of the filters is arbitrary.
A FilterPosition is used in the case where the class has one specific place for third-party filters to be inserted.
Defining Filter Levels
[DDInstall.HW]
AddReg = FilterLevel_Definition
[FilterLevel_Definition]
HKR,,UpperFilterLevels,%REG_MULTI_SZ%,"LevelA","LevelB","LevelC"
HKR,,UpperFilterDefaultLevel,,"LevelC"
HKR,,LowerFilterLevels,%REG_MULTI_SZ%,"LevelD","LevelE","LevelF"
HKR,,LowerFilterDefaultLevel,,"LevelE"
This can only be done by a base driver.

The full declarative list of filters for a specific device can be retrieved by querying the following properties:
DEVPKEY_Device_CompoundUpperFilters
DEVPKEY_Device_CompoundLowerFilters
Legacy-equivalent filter registration

Let's examine how to accomplish the legacy approach of trying to add an upper filter via INF:
[DDInstall.HW]
AddReg = Filters
[Filters]
HKR,,"UpperFilters", 0x00010008, "MyFilter"
This syntax will add "MyFilter" to the end of the list of upper filters.
With the new syntax that has been introduced, the above section is logically similar to:
[DDInstall.Filters]
AddFilter = MyFilter,,MyUpperFilterInstall
[MyUpperFilterInstall]
FilterPosition = Upper
This specifies that the filter "MyFilter" should be added to the list of upper filters. If the base INF has specified
filter levels, using FilterPosition will register the filter in the default level for that position.
If filter levels are not specified, this filter will be registered as an upper filter in arbitrary order.
In this topic we explain how to use Visual Studio to start writing a new software driver. Software drivers are
different from device function drivers, filter drivers, and file system drivers, which we cover in other topics. For
more information about software drivers and how they differ from other types of drivers, see What is a Driver?
and Choosing a Driver Model.
To begin, first determine which driver model is appropriate for your software driver. The three options are the
Kernel Mode Driver Framework (KMDF), the legacy NT driver model, and the Windows Driver Model (WDM). For
help determining which model is best for you, see Choosing a Driver Model.
Case 1: You want to use KMDF

4. Fill in the Name and Location boxes, and select OK . For more details, see Writing a KMDF Driver Based on a
Template.
NOTE
When you create a new KMDF driver, you must select a driver name that has 32 characters or less. This length
limit is defined in wdfglobals.h.
Now you can supply the code that is specific to your software driver.
Case 2: You want to use the legacy NT model

2. In Visual Studio, in the New Project dialog box, under Windows Driver , select WDM | Empty WDM
Driver.
NOTE
You are not going to write a WDM driver, but you need the Empty WDM Driver template.

NOTE
If you want to create a .c file instead of a .cpp file, enter a name that has the .c extension.
6. Include ntddk.h.
7. Implement the functions required by your software driver. As you implement and organize your
functions, you might decide to add header files and additional .cpp or .c files.
Case 3: You want to use WDM

It is extremely unlikely that you'll want to use WDM for a software driver. But if you do, follow these steps.
NOTE
If you want to create a .c file instead of a .cpp file, enter a name that has the .c extension.
6. Include wdm.h.
7. Implement the functions required by your software driver. As you implement and organize your
functions, you might decide to add header files and additional .cpp or .c files.
Creating a new primitive driver
Use a primitive driver to handle and manage software that uses INF-based installation but are not necessarily
tied to a particular hardware device.
Background and benefits of primitive drivers

Prior to Windows 10 version 1903, certain types of software that used INF-based installation but were not
necessarily tied to a particular hardware device were not fully supported by the OS. While these pieces of
software used INF files as a manifest for installation, the OS was not directly aware of this scenario and did not
have support to handle it natively.
Because these pieces of software were not tied to a hardware device, they would install on the whole system
regardless of hardware. As a result, there was no guarantee that these pieces of software were properly
installed, uninstalled, or handled on OS upgrade.
To improve reliability and guarantee proper behavior of these types of software, especially during OS upgrade
and reset scenarios, the Plug and Play platform--starting with Windows 10 version 1903--now handles and
manages this type of software package as a top-level entity.
The types of software that leverage this new platform support are called primitive drivers. Primitive drivers
continue to use INF-based installation and the underlying platform makes use of the Driver Store to keep track
of all relevant files.
The underlying Plug and Play platform then gracefully installs, uninstalls, and maintains driver state on OS
upgrade.
Conceptually, these INFs are managed differently. Previously, [DefaultInstall] (and often, [DefaultUninstall]) were
processed by SetupAPI in a script-like fashion, where the INF was used as a manifest and SetupAPI executed the
instructions in the relevant sections on the caller's behalf.
Undoing the changes (to perform an uninstallation) required specifying an INF section that performed the
opposite set of instructions as the installation section. INF-leveraging primitive drivers, however, do not require
an uninstallation section.
Primitive drivers use the same installation and uninstallation APIs as device drivers, where the uninstallation API
will perform the inverse set of operations as the install operation, and the act of installing or uninstalling the
driver package will process those sections.
INF requirements to access primitive driver functionality

The Version section must be complete, just like PnP drivers.
The Provider directive must be filled in.
The Class directive must be filled in.
The ClassGuid directive must be filled in.
The driver must be DCH-Compliant.
No [Manufacturer] section may be present.
[DefaultInstall] sections must be architecture decorated, and no undecorated versions may be present.
Correct: [DefaultInstall.amd64]
Incorrect: [DefaultInstall]
[DefaultUninstall] may not be present in the INF (see legacy compatibility for an exception).
Primitive drivers targeting only Windows 10 version 1903 and later

Primitive drivers targeted only for Windows 10 version 1903 and later should use DiInstallDriver and
DiUninstallDriver to properly install and uninstall their software in/from the driver store.
Drivers should also use Dirid 13 to properly specify the Driver Store as the desired destination to be installed.
For more information about Dirids, see Using Dirids.
Legacy Compatibility
While [DefaultUninstall] is prohibited in Primitive Drivers, an exception is made for the sake of down-level OS
compatibility. Windows introduces an INF directive that causes an OS version that supports Primitive Drivers to
ignore the [DefaultUninstall] section. If your driver package needs to support down-level OS versions, include
the following syntax to ensure that the platform will appropriately handle such cases:
[DefaultUninstall.NTamd64]
LegacyUninstall=1
The [DefaultInstall] and [DefaultUninstall] sections must still be architecture decorated ; however, by
including the LegacyUninstall=1 , Windows ignores the [DefaultUninstall] section (in Windows 10 version 1903
and later). By doing so, you can include that section in your INF, where it can be used down-level with a legacy
install/uninstall application in order to uninstall the primitive driver package.
Beginning with Windows 10 version 1903, if you pass an architecture-decorated [DefaultInstall] or
[DefaultUninstall] section in to the InstallHInfSection API in setupapi.dll, the driver package will be checked to
determine if it supports primitive driver functionality. If it does support primitive driver functionality, rather than
process the specified section in the legacy way, the INF is passed to DiInstallDriver or DiUninstallDriver, as
appropriate. This way, a single installer can make use of primitive drivers on compatible OS versions and
maintain support for previous OS versions.
Converting from a device driver INF

Converting an INF that uses [Manufacturer] to one that uses [DefaultInstall] requires minor changes to the INF.
Unlike a [Manufacturer] section, a [DefaultInstall] section is both an entry point and an install section. This
conceptually combines the [Manufacturer], [Models], and [DDInstall] section into one.
Consider the following device driver INF:
[Manufacturer]
%Company% = Driver, NTx86, NTamd64
[Driver.NTx86]
%DeviceDesc% = InstallSection_32,
[Driver.NTamd64]
%DeviceDesc% = InstallSection_64,
[InstallSection_64]
CopyFiles = MyCopyFiles_64
AddReg = MyAddReg
[InstallSection_64.Services]
AddService = MyService,, MyService_Install
[InstallSection_32]
CopyFiles = MyCopyFiles_x86
AddReg = MyAddReg
[InstallSection_32.Services]
This INF will receive an 1297 error in InfVerif because it doesn't install on any hardware. This INF can be
converted to a [DefaultInstall]-based INF, as shown below.
[DefaultInstall.NTamd64]
CopyFiles = MyCopyFiles_64
AddReg = MyAddReg
[DefaultInstall.NTamd64.Services]
[DefaultInstall.NTx86]
CopyFiles = MyCopyFiles_x86
AddReg = MyAddReg
[DefaultInstall.NTx86.Services]
The WDK is integrated with Microsoft Visual Studio, and uses the same compiler and build tools that you use to
build Visual Studio solutions and projects. MSBuild replaces the Windows Build Utility (Build.exe) that was used
in versions of the WDK prior to Windows Driver Kit (WDK) 8.
To convert a driver that was created with a previous version of the WDK, create a new Windows driver solution
in Visual Studio using one of the provided Windows driver templates. If you start with a template for your driver
model, the structure of the project will be in place and the correct platform tool set will be selected. You can then
add your source files to the solution. For information about selecting templates, see Creating a New Device
Function Driver, Creating a New Filter Driver, or Creating a New Software Driver.
Related topics
WDK and the Visual Studio build environment
ProjectUpgradeTool
MSBuild
Walkthrough: Using MSBuild
Using Visual Studio or MSBuild to build a driver
This topic describes how you can build a driver using the Visual Studio development environment, or from the
command line by using the Microsoft Build Engine (MSBuild).
Impor tant Starting in Windows Driver Kit (WDK) 8, MSBuild replaced the Windows Build Utility (Build.exe). The
WDK now uses the same compiler and build tools that you use to build Visual Studio projects. Driver projects
that were built with previous versions of the WDK must be converted to work in the Visual Studio environment.
You can run a conversion utility from the command line, or you can convert an existing driver by creating new
Visual Studio project from existing sources. For more info, see Creating a Driver From Existing Source Files and
WDK and the Visual Studio build environment.
Building a Driver Using Visual Studio

You build a driver the same way you build any project or solution in Visual Studio. When you create a new driver
project using a Windows driver template, the template defines a default (active) project configuration and a
default (active) solution build configuration.
Note You can convert projects and solutions that you created with WDK 8 or Windows Driver Kit (WDK) 8.1 to
work with Windows Driver Kit (WDK) 10 and Visual Studio 2019. Before you open the projects or solutions, run
the ProjectUpgradeTool. The ProjectUpgradeTool converts the projects and solutions so that they can be built
using WDK 10.
For information about managing and editing build configurations, see Building in Visual Studio.
The default Solution build configuration is Debug and Win32 .
To select a configuration and build a driver
1. Ensure that you have the same version of SDK and WDK installed on your computer.
2. Open the driver project or solution in Visual Studio.
3. Select and hold (or right-click) the solution in the Solutions Explorer and select Configuration Manager .
4. From the Configuration Manager , select the Active solution configuration (for example, Debug or
Release ) and the Active solution platform (for example, Win32 ) that correspond to the type of build you
are interested in.
5. Select and hold (or right-click) the Avshws project and select Proper ties . Navigate to Driver Settings >
General , and set Target OS Version and Target Platform .
6. Configure the project properties for your driver or driver package. You can set properties for deployment,
driver signing, or other tasks. For more information, see Configuring project properties for your driver and
driver package.
7. From the Build menu, select Build Solution (Ctrl+Shift+B ).
Building a Driver Using the Command Line (MSBuild)

You can build a driver from the command line using the Visual Studio Command Prompt window and the
Microsoft Build Engine (MSBuild)
To build a driver using the Visual Studio Command Prompt window
1. Open a Developer Command Prompt for VS2019 window.
From this window you can use MSBuild.exe to build any Visual Studio project by specifying the project
(.VcxProj) or solutions (.Sln) file.
2. Navigate to the project directory and enter the MSbuild command for your target.
For example, to perform a clean build of a Visual Studio driver project called MyDriver.vcxproj using the
default Platform and Configuration, navigate to the project directory and enter the following MSBuild
command:
msbuild /t:clean /t:build .\MyDriver.vcxproj
Syntax - To specify a specific configuration and platform, use the following command syntax:
msbuild /t:clean /t:build ProjectFile /p:Configuration=<Debug|Release> /p:Platform=architecture

/p:TargetPlatformVersion=a.b.c.d /p:TargetVersion=OS
For example, the following command builds a driver for the "Debug" configuration, "Win32" platform,
and for Windows 10.
msbuild /t:clean /t:build .\MyDriver.vcxproj /p:Configuration="Debug" /p:Platform=Win32

/p:TargetVersion=”Windows10” /p:TargetPlatformVersion=”10.0.10010.0”
The TargetPlatformVersion setting is optional and allows you to specify the kit version to build with.
The default is to use the latest kit.
Configuring project properties for your driver and driver package

You use proper ty pages to configure and set options for your driver and driver package. You can choose to
configure your driver so that it is automatically signed when you build your solution, or automatically deployed
to a remote test computer.
The WDK provides a number of command-line tools, such as Stampinf and WPP Preprocessor (WPP Tracing),
that are commonly included in the build process. These tools are not distributed with Visual Studio. To combine
these tools with the Visual Studio build environment they are wrapped as WDK tasks for MSBuild. If you use one
of the driver templates or have an existing driver that you have converted, these property pages might already
exist for your project. If not, the property pages are automatically added to your project as you add the related
file types to the project or solution (for example, .mc or .man files for the message compiler). For more
information, see WDK and the Visual Studio build environment
You can set properties for an individual driver or for an entire driver package. The following table shows some
of the available properties that you can configure specifically for drivers and driver packages.
DRIVER P RO JEC T P RO P ERT IES DRIVER PA C K A GE P RO P ERT IES
Signing properties for individual driver files (see Signing Signing properties for driver packages (see Signing a
a Driver) Driver)
Counters Manifest Preprocessor Properties for Driver Deployment Properties for Driver Package Projects (see
Projects (for CTRPP) Deploying a Driver to a Test Computer)
Driver Model Settings Properties for Driver Projects Driver Verifier Properties for Driver Package Projects
DRIVER P RO JEC T P RO P ERT IES DRIVER PA C K A GE P RO P ERT IES
Message Compiler Properties for Driver Projects KMDF Verifier Properties for Driver Package Projects
Stampinf Properties for Driver Projects UMDF Verifier Properties for Driver Package Projects
WPP Preprocessor (WPP Tracing) Inf2Cat Properties for Driver Package Projects (see the
Inf2Cat tool)
Troubleshooting tip for building a driver

The following tip can help you troubleshoot problems when you use the WDK and Visual Studio to build drivers.
To increase the verbosity of the build output using the options in Visual Studio
1. Select Tools > Options .
2. Select the Project and Solutions folder and select Build and Run .
3. Change the options for the MSBuild project build output verbosity and MSBuild project build log
file verbosity . By default, these are set to Minimal.
Related topics
Building in Visual Studio
Using the Microsoft C Runtime with User-Mode Drivers and Desktop Apps
ProjectUpgradeTool
MSBuild
WDK and the Visual Studio build environment
Signing a Driver
Building for OneCore
When you use Visual Studio to build user-mode code for Windows 10, you can customize linker options to
target specific versions of Windows. Consider the following factors:
Should the built binary run on only the most recent version of Windows? Or should it run on earlier
versions, such as Windows 7?
Does your project have any UWP dependencies?
For example, when you create a new UMDF v2 driver project, Visual Studio links to OneCoreUAP.lib by default.
This results in a binary that runs on the most recent version of Windows, and it permits addition of UWP
functionality.
However, depending on your requirements, you might choose instead to link to OneCore.lib . The following
table shows the scenarios applicable to each library:
L IB RA RY SC EN A RIO
OneCore.lib All editions of Windows 7 and later, no UWP support
OneCoreUAP.lib Windows 7 and later, UWP editions (Desktop, IoT, HoloLens,

but not Nano Server) of Windows 10
NOTE
To change linker options in Visual Studio, choose project properties and navigate to Linker->Input->Additional
Dependencies .
A subset of Windows APIs compile cleanly but return runtime errors on non-Desktop OneCore editions (for
example Mobile or IoT).
For example, the InstallApplication function returns ERROR_ NOT_SUPPORTED on non-Desktop OneCore editions.
The ApiValidator tool also reports these problems. The next section describes how to fix them.
Fixing ApiValidator errors by using IsApiSetImplemented

If your code calls non-universal APIs, you might see the following ApiValidator errors:
Error: <Binary Name> has unsupported API call to <Module Name><Api Name>
If your app or base driver needs to run on Windows 10 as well as earlier versions of Windows, you must
remove API calls in the above category.
Error: <Binary Name> has a dependency on <Module Name><Api Name> but is missing: IsApiSetImplemented("
<contract-name-for-Module>)
API calls in the above category compile fine, but may not behave as expected at runtime, depending on
the target operating system. To pass the API Layering requirement for Windows Drivers, wrap these calls
with IsApiSetImplemented .
This enables you to compile your code with no errors. Then at runtime, if the target machine does not have the
needed API, IsApiSetImplemented returns FALSE.
The following code samples illustrate how to do this.
Code sample: Direct usage of API, without evaluating for existence

This code runs fine on versions of Windows earlier than Windows 10, but running it on a OneCore edition of
Windows 10 results in WTSEnumerateSessions failure : 78 or ERROR_CALL_NOT_IMPLEMENTED 120 (0x78).
This code sample fails the API Layering requirement of Windows Drivers with the following ApiValidator errors:
ApiValidation: Error: FlexLinkTest.exe has a dependency on 'wtsapi32.dll!WTSEnumerateSessionsW' but is

missing: IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0")
ApiValidation: Error: FlexLinkTest.exe has a dependency on 'wtsapi32.dll!WTSFreeMemory' but is missing:
IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0")
ApiValidation: NOT all binaries are Universal
Here's the code:
#include <windows.h>
#include <stdio.h>
#include <Wtsapi32.h>
int __cdecl wmain(int /* argc */, PCWSTR /* argv */ [])

{
PWTS_SESSION_INFO pInfo = {};
DWORD count = 0;
if (WTSEnumerateSessionsW(WTS_CURRENT_SERVER_HANDLE, 0, 1, &pInfo, &count))

{
wprintf(L"SessionCount = %d\n", count);
for (ULONG i = 0; i < count; i++)

{
PWTS_SESSION_INFO pCurInfo = &pInfo[i];
wprintf(L" %s: ID = %d, state = %d\n", pCurInfo->pWinStationName, pCurInfo->SessionId,
pCurInfo->State);
}
WTSFreeMemory(pInfo);
}
else
{
wprintf(L"WTSEnumerateSessions failure : %x\n", GetLastError());
}
return 0;
}
Code sample: Direct usage of API, after evaluating for existence

This sample shows how to call IsApiSetImplemented . This sample passes the API Layering requirement of
Windows Drivers with the following ApiValidator output:
ApiValidation: All binaries are Universal
Here's the code:

#include <windows.h>
#include <stdio.h>
#include <Wtsapi32.h>
int __cdecl wmain(int /* argc */, PCWSTR /* argv */ [])

{
PWTS_SESSION_INFO pInfo = {};
DWORD count = 0;
if (!IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0"))
{
wprintf(L"IsApiSetImplemented on ext-ms-win-session-wtsapi32-l1-1-0 returns FALSE\n");
}
else
{
if (WTSEnumerateSessionsW(WTS_CURRENT_SERVER_HANDLE, 0, 1, &pInfo, &count))
{
wprintf(L"SessionCount = %d\n", count);
for (ULONG i = 0; i < count; i++)

{
PWTS_SESSION_INFO pCurInfo = &pInfo[i];
wprintf(L" %s: ID = %d, state = %d\n", pCurInfo->pWinStationName, pCurInfo->SessionId,
pCurInfo->State);
}
WTSFreeMemory(pInfo);
}
else
{
wprintf(L"WTSEnumerateSessions failure : %x\n", GetLastError());
}
}
return 0;
}
Recommended actions
Review the linker options above and update your Visual Studio project accordingly.
Use the ApiValidator tool in the WDK. This tool runs automatically when you build a driver in Visual Studio.
Use runtime testing to verify that your user-mode code runs as you expect on non-Desktop OneCore
editions. Note that stubbed APIs may generate different error codes.
See Also
OneCore
If you are writing drivers for different versions of Windows, the following section provides some guidelines
about how you should build those drivers using the Windows Driver Kit (WDK) 8.1 or WDK 8, Visual Studio, and
MSBuild.
Guidelines that apply to building both user-mode and kernel-mode

drivers
Build your drivers using the target configurations and platforms that the WDK provides. Always use the latest
version of the WDK that supports the version of Windows that you want to target. For example, to build
drivers for Windows XP, you must use the Windows 7 WDK. But if you are building a driver for Windows 8.1,
Windows 8, Windows 7, use the WDK 8.1 and Visual Studio.
If your driver must run only on a single version of Windows, build the driver for the target configuration and
platform that matches your target Windows version. For example, if you are building a driver that will run
only on WDK 8.1, specify Win8.1 in the Configuration Manager.
If you want your driver to run on multiple versions of Windows, but without features that are available only
on newer versions, build the driver for the oldest version that you want the driver to support. For example, if
your driver will run on all Windows versions starting with Windows Vista and it will use only features that
are provided on Windows Vista, specify Vista for the project configuration.
Guidelines that apply to building kernel-mode drivers

If you want your kernel-mode driver to run on multiple versions of Windows and dynamically determine
the features that are available to the driver, build the driver using the build configuration for the most
recent version of the operating system. For example, if you want your driver to support all versions of
Windows starting with Windows 7, but to use certain features that were first available in Windows 8.1
when your driver is running on Windows 8.1 or later versions of the operating system, specify
Windows 8.1 (Win8.1 ) as the target configuration.
Use the RtlIsNtDdiVersionAvailable and RtlIsSer vicePackVersionInstalled functions to determine
the version of Windows that is available to your driver at run time. For more information, see Writing
drivers for different versions of Windows.
Create prototypes for pointers to functions that your driver must call conditionally.
If you have a WDM driver, or a non-KMDF kernel-mode driver, and you are targeting Windows 8.1 or
Windows 8 but also want to run on earlier versions of Windows, you need to override the linker
$(KernelBufferOverflowLib) option. When you select Windows 8 or Windows 8.1 configurations, the
driver is linked with BufferOverflowFastFailK.lib, which is not available in earlier Windows versions. For
Windows 7 and Vista, you must link with BufferOverflowK.lib instead.
There are two ways to override the $(KernelBufferOverflowLib) linker option, using either MSBuild or
Visual Studio.
Using MSBuild:
msbuild /p:KernelBufferOverflowLib="C:\Program Files (x86)\Windows
Kits\8.1\Lib\win8\km\x64\BufferOverflowK.lib" /p:platform=x64 /p:Configuration="Win8 Release"
myDriver.sln
Using Visual Studio:

Using Notepad, or another text editor, open the driver project file (*.vcxproj). In the project file, locate the
<Proper tyGroup> for the configurations your driver supports, and add the following line to override
the default linker option:
XM L
<KernelBufferOverflowLib>$(DDK_LIB_PATH)\BufferOverflowK.lib</KernelBufferOverflowLib>
For example, if your driver supports Windows 8.1 and Windows 8 debug and release builds, those
configuration sections would look like the following:
XM L
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8.1 Debug|Win32'"

Label="Configuration">
<TargetVersion>WindowsV6.3</TargetVersion>
<UseDebugLibraries>true</UseDebugLibraries>
<PlatformToolset>WindowsKernelModeDriver8.1</PlatformToolset>
<ConfigurationType>Driver</ConfigurationType>
<DriverType>KMDF</DriverType>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8.1 Release|Win32'"
<TargetVersion>WindowsV6.3</TargetVersion>
<UseDebugLibraries>false</UseDebugLibraries>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8 Debug|Win32'"
<TargetVersion>Windows8</TargetVersion>
<UseDebugLibraries>true</UseDebugLibraries>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8 Release|Win32'"
<TargetVersion>Windows8</TargetVersion>
<UseDebugLibraries>false</UseDebugLibraries>
</PropertyGroup>
The <KernelBufferOverflowLib> elements must appear in the driver project file before the element
that imports Microsoft.Cpp.props, which imports the tool set.
After you modify and save the driver project file, you can open the project file in Visual Studio and build
the driver.
Related topics
Writing drivers for different versions of Windows
Building a Driver
Building ARM64 Drivers with the WDK
Windows 10 can run on machines that are powered by ARM64 processors. However, because Windows 10 on
ARM does not support emulation of x86 kernel-mode drivers, you must recompile kernel-mode drivers to
ARM64 using the instructions below.
Setup
1. Download Visual Studio 2017 or 2019. You'll need at minimum version 15.9.
2. On the Windows start menu, type Visual Studio Installer . Then on the Workloads tab, select Desktop
development with C++ .
3. On the Individual Components tab, select the following options:

Visual C++ compilers and libraries for ARM
Visual C++ compilers and libraries for ARM64
4. Install and restart Visual Studio.

5. Download the Windows SDK. Ensure that you have SDK version 16299 (Windows 10, version 1709) or
later.
6. Download the WDK. Ensure that you have WDK version 16299 or later.
Building an ARM64 Driver with the WDK
1. In Visual Studio, open a driver solution. You can use your own, or one from the Windows-driver-samples
repo.
2. Select Solutions platform and select Configuration Manager .
3. Under Active Solution Platform , select New .
4. From Type or Select new Platform , select ARM64 . Copy settings from Win32 . Select OK and Close .
5. Select ARM64 as the target platform and rebuild.
See Also
Debugging ARM64
Windows 10 on ARM
HLK ARM64 Getting Started Guide
Using the Enterprise WDK
The Enterprise Windows Driver Kit (Enterprise WDK) is a command-line build environment that does not require
any installation prior to use. Once you have downloaded the EWDK, you can manage it with version control
software or you can zip the files and copy as needed. A .zip file created with the Enterprise WDK contains all the
necessary compilers, linkers, build tools, headers and libs to build Visual Studio-based driver projects.
The Enterprise WDK contains the necessary elements to build drivers and basic Win32 driver test applications.
Use your favorite code editor to modify source code and project files. Because it is command-line based, the
Enterprise WDK does lack some of the features incorporated into Visual Studio, such as an IDE, driver
deployment and driver testing.
Getting Started
NOTE
Starting in Windows 10 version 1709, the Enterprise WDK is ISO-based. To get started, download and mount the ISO,
then run LaunchBuildEnv .
1. Download the EWDK from: WDK & EWDK download

2. Expand the .zip file into an appropriately named directory, such as d:\ewdk.
3. From an Administrator command prompt, navigate to the expanded folder in the previous step, and then run
LaunchBuildEnvcmd to create the build environment. For example: D:\EWDK\LaunchBuildEnv
After you create the build environment, you can use it to work on the files or build Visual Studio projects. For
example.
Cd directory_containing_project_files
Msbuild projectname.vsproj
Basic MSBuild commands for projects and solutions:
Msbuild project.vcxproj /p:configuration=[release | debug] /p:platform=[arm | Win32 | x64]
To create a desktop shortcut:
%comspec% /k pushd <drive\dir> && LaunchBuildEnv.cmd
Where <drive\dir> is the location that the files were extracted to, for example, d:\ewdk
%comspec% /k pushd "d:\ewdk" && LaunchBuildEnv.cmd
See Also
MSBuild Reference
Installing the WDK 8.1 Build Environment in a Lab
The Windows Driver Kit (WDK) 8.1 provides a feature that enables you to copy components of Visual Studio and
the WDK to a new location and then launch the build environment from the command line. From here you can
build Windows drivers without having to run the Visual Studio or WDK installation programs.
You might find this feature useful if you need to integrate the WDK with your build process, or if you want to
distribute the build process in a lab or test environment.
Note You can only use this feature for building drivers and applications that use C and C++. This feature cannot
be used for managed code or UWP apps.
1. Download the Visual Studio and WDK and SDK setup files
To run the set up script that enables this feature, you need to provide the paths to the Visual Studio and WDK
setup files. Be sure to save these files (rather than install them).
1. Download Visual Studio Professional 2013 or Visual Studio Ultimate 2013. Download the Product Layout (for
example, vs_ultimate_download.exe ). When you are asked if you want to run or save
vs_ultimate_download.exe, select Run and then select the download option and specify the download path as
C:\VSSetup (this makes the later steps easier). Select Download to download and install a local copy of the
DVD layout on the computer.
2. Download the standalone SDK. When you are asked if you want to run or save sdksetup.exe, select Run and
then specify the download location as C:\Kits\SDK . Select Next and follow the instructions to download the
standalone SDK.
3. Download the WDK 8.1. When you are asked if you want to run or save wdksetup.exe, select Run and then
specify the download location as C:\Kits\WDK . Select Next and follow the instructions to download the
WDK. If you have already installed the WDK on the computer, the web installation program will tell you that
the features installed on the computer are up-to-date. To download the WDK setup files so that you can
deploy the build environment, select Next and specify the C:\Kits\WDK path.
2. Download the BuildLabSupport files

To be able install the WDK build environment on computers in a lab, you need to first download the build lab
support files on your computer.
1. Download BuildLabSupportfiles.zip.
2. Extract the contents of the compressed file to your computer. The extracted files include the BuildLabSupport
directory and include the setup files and utilities you need.
3. Install the WDK 8.1 build environment

The build lab support files include the setup.ps1 PowerShell command file, which extracts the needed Visual
Studio and WDK components and copies them to a target directory (folder). You can then copy this directory to
another location, from which you can build projects in a Visual Studio command-line interface (CLI)
development environment.
Open a Command Prompt window with elevated privileges (Run as administrator ) and go to the
directory where you extracted build lab support files. The PowerShell command script setup.ps1 is in the
<root>\BuildLabSupport directory.
The syntax for the PowerShell command is as follows:
P O W ERSH EL L
powershell –executionpolicy bypass –file Setup.ps1 –DeployBuildLab –VSInstallerPath

<VSInstallerFilePath> -KitInstallersPath <KitInstallersPath> -ExpansionRoot <Target Directory> –
LogFilePath <LogFilePath> -CatalogFile <Filename.xml>
The <VSInstallerFilePath> is the path to the Visual Studio installation program (for example,
Vs_ultimate.exe) and directory that contains the product layout.
The <KitInstallersPath> is the path to the WDK and SDK setup files.
The <Target Directory> is the target directory for the extracted content.
The <LogFilePath> is the target destination for the log file.
<Filename.xml> is the name of the CatalogFile, which contains a list of Microsoft Windows installation
files (MSI) to expand as part of the installation. The name of the file is files.xml.
For example, the following command runs the script from BuildLabSupport directory and installs the
build environment in C:\BuildLabInstall directory.
c:\BuildLabSupport>powershell -executionpolicy bypass -file Setup.ps1 -DeployBuildLab -

VSInstallerPath c:\VSSetup -KitInstallersPath c:\Kits -E
xpansionRoot C:\BuildLabInstall -CatalogFile files.xml
4. Build Windows driver projects and solutions

Using the build environment command script
1. Open a Command Prompt window. Locate the LaunchBuildEnv.cmd file located in the target directory (for
example, C:\BuildLabInstall).
2. Launch the build environment by running LaunchBuildEnv.cmd .
3. Use MSBuild commands to build your driver projects and solutions. For example:
msbuild /t:clean /t:build .\MyDriver.vcxproj /p:Configuration="Win8.1 Debug" /p:Platform=Win32
Related topics
Building a Driver
MSBuild
Using the Microsoft C Runtime with User-Mode
Drivers and Desktop Apps
If you are building applications or drivers for Windows 10, you only need to read this section. If you are using a
version of Visual Studio earlier than Visual Studio 2015, skip this section and start with Redistributing the C
Runtime (applies to before Visual Studio 2015).
Starting in Visual Studio 2015, the Universal C Runtime (UCRT) encompasses the C runtime. The other pieces
required for a complete program (C/C++ Language Features, C++ Library) are provided by Visual Studio in the
VC++ Redistributable. To avoid a runtime redistribution requirement, those pieces are statically linked.
WARNING
When building a user-mode driver project in Visual Studio, if you set PlatformToolset to WindowsUserModeDriver10.0 ,
the toolset ignores any runtime library specified in the project and instead links statically against the VC++ Runtime and
dynamically against the UCRT. When using this toolset, this hybrid linking behavior cannot be reconfigured.
If you're not using the WindowsUserModeDriver10.0 toolset, use the following procedure to make modifications
(for example include another DLL):
1. Set to link statically in general: Proper ties > C/C++ > Code Generation > Runtime Librar y = Multi-
threaded (/MT)
2. Remove the statically linked UCRT: Proper ties > Linker > Input > Ignore Specific Default Libraries
+= libucr t.lib
3. Add the dynamically linked UCRT: Proper ties > Linker > Input > Additional Dependencies +=
ucr t.lib , Proper ties > Linker > Input > Ignore Specific Default Libraries += libucr t.lib
Redistributing the C Runtime (applies to before Visual Studio 2015)

NOTE
All information below this point applies only to pre-2015. Prior to 2015, there were two separate versions of the C
Runtime: the Visual C++ Runtime (VCRT, for example msvcr120.dll ) and the legacy Windows CRT ( msvcrt.dll ).
Visual Studio installs the latest version of the VCRT into the System32 directory. If the file is not in this location,
you can copy it directly into the build directory of your Visual C++ project.
If your user-mode driver or desktop application uses the VCRT, you must distribute the appropriate dynamic-link
libraries. Use the Visual C++ Redistributable Package ( VCRedist_x86.exe , VCRedist_x64.exe , VCRedist_arm.exe ).
Chain the redistributable package in with other binaries, and the redistributable package will receive automatic
updates.
If you want to achieve isolation or avoid the dependency on the VC++ Redistributable, you can link statically to
the CRT instead. While non-driver projects are usually able to copy the specific Visual C/C++ DLLs to the
application local folder (where the application is installed) to avoid a dependency on the VC++ Redistributable,
app-local deployment is not appropriate for a driver.
Do not copy individual CRT components to System32 instead of using a redistributable package. This may cause
the CRT not to be serviced automatically, and potentially to be overwritten.
The following special considerations apply for printer drivers:
These drivers should include the required CRT files in the INF, so the CRT files are copied to the driver store as
part of the driver payload.
V4 print drivers cannot use a co-installer for setup, so the INF must copy relevant binaries of the C/C++
runtime library to the driver store. To do this, reference the appropriate files in the [COPY_FILES] section of
the driver package.
V3 print drivers should not use co-installers for setup, as they are not run during Point and Print connections.
These drivers should reference the appropriate files in the [COPY_FILES] section of the driver package.
The following is an example of how to include the CRT binaries in the [COPY_FILES] section of an INF:
[COPY_FILES]
;CRT
Msvcr120.dll
; other files
* [SourceDisksFiles]
Msvcr120.dll = 2
; other files
* [SourceDisksNames.amd64]
1 = %Location%,,,
2 = %Location%,,,"amd64"
For UMDF drivers:

Statically link your driver against the CRT to include the runtime in the binary. In this case, you do not need to
redistribute the CRT.
Linking your code with the C Runtime libraries (applies to before

Visual Studio 2015)
To determine which DLLs you must redistribute with your application, collect a list of the DLLs that your
application depends on. One way to collect the list is to run Dependency Walker ( depends.exe ).
For more information, see Determining Which DLLs to Redistribute and Choosing a Deployment Method.
You cannot redistribute all of the files that are included in Visual Studio; you are only permitted to redistribute
the files that are specified in Redistributable Code for Visual Studio 2013 Preview and Visual Studio 2013 SDK
Preview. Debug versions of applications and the various Visual C++ dynamic-link libraries are not
redistributable.
The following libraries contain the C run-time library functions:
T ERM DESC RIP T IO N
Msvcr120.dll C runtime
Msvcp120.dll C++ runtime
Msvcr120d.dll Debug version of C runtime - no redistribution allowed
Msvcp120d.dll Debug version of C++ runtime - no redistribution allowed

Avoiding Floating Point Errors in Custom Build
Environments
This information is intended for developers and build engineers who compile kernel-mode drivers for Windows.
In Microsoft Visual Studio Professional 2012, the default architecture for the Visual C++ (VC++) compiler
changed from IA32 to the Streaming SIMD Extensions 2 (SSE2) instruction set. As a result of this change, SSE2
floating point (FP) instructions injected into the binary at compile time can generate floating-point errors if not
accounted for. The issue can be encountered by those who use the Microsoft VC++ compiler, or a custom build
environment to develop Windows drivers. However, the issue does not affect developers who use the Microsoft
Visual Studio development environment, or who use the MSbuild utility to build drivers with an unmodified
toolset.
Floating point errors can cause data corruption or computer crashes

If you compile a driver without using the WDK, Visual Studio, and the recommended platform toolset for
Windows drivers (WindowsKernelModeDriver8.0 ), the driver might not manage floating point operations
correctly, even if the driver compiles without errors.
The Visual Studio Professional 2012 VC++ compiler emits code that uses the SSE2 instruction set by setting the
/arch:sse2 compiler option. Starting with Visual Studio Professional 2012, this is the default option for x86
VC++ compiler code generation. Specifically, the default value changes from /arch:ia32 to /arch:sse2 .
For applications this change generates code that performs better and uses less processor time during execution.
However, for kernel-mode drivers this change will not manage the floating point (FP) state properly. This is due
to the VC++ compiler introducing FP instruction sequences in places where the context has not been saved. Any
binary floating-point system can represent only a finite number of floating-point values in exact form, with the
rest being approximations. The floating-point control state, such as, rounding mode or precision, is what keeps
FP operations in sync with each other. When the state is undefined, this leads to FP calculation errors. These
calculation errors are hard to detect because in most cases application state corruption is the only sign of this
issue. This corruption can manifest itself in many ways, ranging from random crashes to data corruption.
Solution
To avoid these problem with floating-point calculations, add the /kernel flag to the C++ compiler and linker
command lines to prevent generating SSE2 instructions. The /kernel flag changes the default /arch:sse2 value
back to /arch:ia32 .
In addition, if you build a driver using the WDK and the Visual Studio Professional 2012 development
environment, or use MSBuild, in a Visual Studio Command prompt window, the Microsoft provided platform
toolset (WindowsKernelModeDriver8.0 ) sets the /kernel flag. As a result, floating-point generation errors
are avoided.
msbuild myProject.vcxproj /p:PlatformToolset=WindowsKernelModeDriver8.0
Recommendations
Here are the recommended solutions based on the type of development environment you use:
Microsoft tool set (MSBuild) - No work required. Use WindowsKernelModeDriver8.0 as the platform
toolset the /kernel is automatically added where appropriate.
Microsoft VC++ Compiler - Add the /kernel flag to prevent compiler from emitting SSE2.
Custom Tooling/Non-Microsoft Compiler - You must manually account for the assembly instructions
used in the resulting binary.
Counters Manifest Preprocessor Properties for
Driver Projects
Sets the properties for the CTRPP tool that parses and validates your counters manifest. For information about
working with performance counters, see Performance Counters. For information about using performance
counters in a kernel-mode Windows driver, see Kernel Mode Performance Monitoring.
Setting the Counters Manifest Preprocessor properties for driver

projects
1. Open the property pages for your driver project. Select and hold (or right-click) the driver project in
Solution Explorer and select Proper ties .
2. In the property pages for the driver project, select Configuration Proper ties and then select Counters
Manifest Preprocessor Proper ties .
3. Set the properties for the project.
If you want to add this property page to your project so that you can run the CTRPP tool during the build
process, see the WDK and Visual Studio build environment and the Ctrpp task.
O P T IO N DESC RIP T IO N
Add Prefix Specifies the prefix to use for the global variables and
functions defined in the generated header file (same as
the -prefix command option.)
Additional Options Specifies additional options to the CTRPP tool.
Backward Compatibility Generates code that is binary compatible with versions

of Windows prior to Windows 7 (same as the -
backcompat command option).
Enable Legacy Reverts to generating code using Windows Vista code

templates. This option causes CTRPP to generate four
output files: two header files (.h, _r.h), a resource file (.rc),
and a source code file (c). (-legacy )
Generate header file for containing counter names and Creates a header file that assigns symbols to the counter
GUIDs set names and GUIDs for each counter set in the
manifest.
Generate header file for provider Specifies the name of the header file that the tool
generates. If you do not specify a path, the file is
generated in the current folder.
Generate Memory Routines Generate memory allocation/free routine templates. (-

Memor yRoutines )
Generate Notification Callback Generate customized notification callback template. (-

NotificationCallback )
Generate resource file Specifies the name of the resource file that the tool
generates. If you do not specify a path, the file is
generated in the current folder.
Generate Summary Global File Generates a binary counter file per provider. (-
summar y path)
Generates a summary global file GenSumResource.BIN.
Generated Counter Files Path Specifies the path to generate binary counter files. (-
sumPath path)
If no path is specified, the current directory is used.
Header File Name For Counter Generates a header file for containing counter names
and ids. (-ch filename)
Header FileName For Provider Generates a header file for the provider. It replaces the
default name. (-o filename)
Resource File Name Specifies the name for the resource file. This replaces the
default name. (-rc filename)
Comment
The default names of the files that the tool generates are based on the name of the manifest file that you pass to
the CTRPP tool.
Related topics
CTRPP
Performance Counters
Kernel Mode Performance Monitoring
Driver Model Settings Properties for Driver Projects
Sets the basic properties for a kernel-mode or user-mode driver, including the WDF library version and
preprocessor definitions.
Setting driver model properties for driver projects

2. In the property pages for the driver project, select Configuration Proper ties and then select Driver
Model Settings .
Type of driver
The type of driver when the driver Configuration type is Driver . Note that this option is available only when
projects use the WindowsKernelModeDriver8.0 toolset.
Possible values are:
WDM (including all miniport/port drivers such as NDIS or StorPort).
KMDF A KMDF driver.
Expor t driver (WDM) A WDM driver that exports functions which other drivers can call. For more
information, see Creating Export Drivers.
KMDF Version Major
When the type of driver is KMDF, this option specifies the major version of KMDF that will be used when
compiling your driver.
The KMDF_VERSION_MAJOR entry informs the MSBuild utility that it must link the driver to the KMDF library.
For more information, see Framework Library Versioning.
KMDF Version Minor (Target Version) (was KMDF Version Minor prior to Windows 10, version 1803)
When the type of driver is KMDF, this option specifies the minor version of KMDF that will be used when
compiling your driver.
For more information, see Framework Library Versioning. If you do not specify KMDF Version Minor (Target
Version) , Visual Studio uses the following defaults:
Windows 10: 1.15
Windows 8 / Windows 8.1: 1.11
Windows 7: 1.9
KMDF Version Minor (Minimum Required) (optional, available starting in Windows 10, version 1803)
Starting in KMDF version 1.25 and UMDF version 2.25 on Windows 10 version 1803 (Redstone 4), you can build
a KMDF driver that targets a span of framework versions. Use this optional setting to specify the minimum
KMDF version of this range.
For details, see Building a WDF driver for multiple versions of Windows.
UMDF Version Major
When you have a UMDF driver, this option specifies the major version of UMDF that will be used when
compiling your driver. See UMDF Version History. When you have a UMDF driver, the Configuration type is
Dynamic Librar y (.dll) .
UMDF Version Minor (Target Version) (was UMDF Version Minor prior to Windows 10, version 1803)
When you have a UMDF driver, this option specifies the minor version of UMDF that will be used when
compiling your driver. If you do not specify UMDF Version Minor (Target Version) , Visual Studio uses the
following defaults:
For major version = 2:
Windows 10: 2.15
Others: 2.0
For major version = 1:
Windows 8 and above: 1.11
Windows 7: 1.9
UMDF Version Minor (Minimum Required) (optional, available starting in Windows 10, version 1803)
Starting in KMDF version 1.25 and UMDF version 2.25 on Windows 10 version 1803 (Redstone 4), you can build
a UMDF driver that targets a span of framework versions. Use this optional setting to specify the minimum
UMDF version of this range.
For details, see Building a WDF driver for multiple versions of Windows.
Allow Date, Time, and Timestamp
Defines the standard C/CPP macros for __DATE__, __TIME__, __TIMESTAMP__.
Override Target Configuration Preprocessor Definitions
Overrides the default values for preprocessing symbols: _WIN32_WINNT, WINVER, WINNT, and
NTDDI_VERSION for your source file. Note that the default values are controlled by the current target
configuration.
Related topics
Framework Library Versioning
Building and Loading a Framework-based Driver
UMDF Version History
Building UMDF Drivers
Creating Export Drivers
Message Compiler Properties for Driver Projects
Sets the properties for the Message Compiler (MC.exe) tool. The compiler generates the message resource
files that you can add to your project.
For example, if you are using the Event Tracing for Windows (ETW) kernel-mode API to add event tracing to a
kernel-mode driver, you could use the message compiler to create a header file that contains definitions for the
event provider, event attributes, channels, and events. You must include this header file in your source code. The
message compiler creates a resource compiler script (*.rc) that you add to your project file.
Setting Message Compiler properties for driver projects

2. In the property pages for the driver project, select Configuration Proper ties and then select Message
Compiler .
This property page is available if you add a message text file (.mc) or a manifest (.man) to your solution.
Additional Options Specifies additional options to pass to the Message

Compiler (MC.exe) tool.
Ansi Input File Specifies that the input file contains ANSI content (this is
the default). (-a )
Ansi Message In Bin File Specifies that the messages in the output .bin file should
be ANSI. (-A )
Baseline Path The path must point to the folder that contains the .BIN
files that the baseline operation created. (-t directory)
Baseline Resource Path The folder which contains the baseline manifest files. (-s
directory)
Debug Output Path The path in which to place the .dbg C include file. (-x
path)
Enable Callout Macro Adds a callout macro to invoke user code at logging.
Not available for C#, and ignored. (-co )
Enable Debug Output Path Enables the compiler to place the .dbg C include file
specified by the Debug Output Path property.
File extension for the generated header Specifies the extension of the generated header file. (-e
extension)
Generate Baseline Resource Creates a baseline of your instrumentation.
Generate C# (managed) logging class Generates a C# (managed) logging class that includes
methods that you would call to log events in your
manifest. (-cs namespace)
Generate header file for containing counter Use this option to specify the folder into which you want
names and GUIDs the compiler to place the generated header file.
Generate Kernel Mode Logging Macros Generates kernel-mode logging macros. (-km )
Generate MOF File Generate down-level support for all functions and
macros generated. MOF file will be generated from the
manifest. MOF file will be placed in the location specified
by the -h option (-mof ).
Generate OLE2 Header Generates an OLE2 header file. (-o )
Generate static C# (managed) logging class Generates a static C# (managed) logging class that
includes methods that you would call to log events in
your manifest. (-css namespace)
Generate User Mode Logging Macros Generate user-mode logging macros. (-um )
Generated Files Base Name Specifies the base name of all generated files. (-z
basename)
Generated RC and Binar y Message Files Path Specifies the path to the generated the RC and binary
message files.
Header File Path Specifies the path the generated header file. (-h path)
Maximum Message Length Use this argument to have the compiler generate a
warning if any message exceeds length characters. (-m
length)
Prefix Macro Name Use this argument to override the default prefix that the
compiler uses for the logging macro names and method
names. (-p prefix)
RC File Path The folder into which you want the compiler to place the
generated resource compiler script (.rc file) and the
generated .bin files. (-r path)
Remove Characters From Symbolic Name Use this argument to remove characters from the
beginning of the symbolic name that you specified for
the event. (-P prefix)
Set Customer Bit Sets the Customer bit in the entire message Ids. (-c)
Terminate Message With Null Terminates all strings with nulls in the message tables. (-
n)
Unicode Input File Specifies that the input file contains Unicode content. (-
u)
The default is ANSI.
Unicode Message In Bin File Specifies that the messages in the output .bin file are
Unicode. (-U )
This is the default.
Use Base Name Of Input Use this argument to have the compiler use the base
name of the input file for the name of the output .bin
files. (-b )
Use Decimal Values Use this argument to use decimal values for the Severity
and Facility constants in the header file instead of
hexadecimal values. (-d )
Validate Against Baseline Resource Use this argument when you create a new version of
your manifest and want to check it for application
compatibility against the baseline that you created using
the -s option.
Verbose Use this option to generate verbose output. (-v )
Related topics
Message Compiler (MC.exe)
WDK and Visual Studio build environment Message compiler task
Event Tracing for Windows (ETW)
MOF Compiler Properties for Driver Projects
The Managed Object Format (MOF) compiler (mofcomp.exe) parses MOF files and adds the classes and class
instances defined in the files to the WMI repository. Use the Mofcomp property page to compile MOF files with
your driver. For more information about Mofcomp.exe and WMI, see mofcomp , Compiling MOF Files, and
Compiling a Driver's MOF File.
Setting Managed Object Format (MOF) Compiler properties for driver

projects
2. In the property pages for the driver project, select Configuration Proper ties and then select Mof
Compiler .
This property page is available if you add a Managed Object Format (MOF) file (.mof) to your solution.
Additional Options Specifies additional options to pass to the mofcomp

tool.
Amendement Splits the MOF file into language-neutral and -specific

versions. (-AMENDMENT: Locale)
Authority Specifies Authority as the authority (domain name) to

use when logging on to WMI. (-A: Authority)
Auto Recover Adds the named MOF file to the list of files compiled
during repository recovery. (-autorecover )
Create Binar y Mof File Requests that the compiler create a binary version of the
MOF file with the name filename without making any
modifications to the WMI repository. (-B: Filename)
Language Neutral Output Name of the language neutral output. (-MOF: Path)
Language Specific Output Name of the language specific output. (-MFL: Path)
Mof Class Creates or updates MOF classes.

Create Only (-class:createonly) Requests that the
compiler not make any changes to existing classes.
When this switch is used, the compile operation
terminates if a class specified in the MOF file already
exists.
Force Update (class:forceupdate) Forces updates of
classes when conflicting child classes exist.
Safe Update (-class:safeupdate) Allows updates of
classes even if there are child classes, as long as the
change does not cause conflicts with child classes.
Update Only (-class:updateonly) Requests that the
compiler not create any new classes.
See mofcomp for more information.
NamespacePath Requests that the compiler load the MOF file into the
namespace specified as namespacepath. (-
N: namespacepath)
Resource Locale Extracts the localized MOF descriptions from the binary
MOF when used with -ER switch. (-L: ResourceLocale)
Resource Name Extracts binary MOF from a named resource. (-

ER: ResourceName)
Syntax Check Requests that the compiler perform a syntax check only
and print appropriate error messages. No other option
can be used with the Syntax Check option.
WMI Syntax Check Requests that the compiler perform a WMI syntax check
-WMI . If you select this option, you must also select
the Create Binar y Mof File option (-B: Filename)
Related topics
Compiling MOF Files
Compiling a Driver's MOF File
mofcomp
Stampinf Properties for Driver Projects
Sets the properties for the Stampinf tool. You can use Stampinf to update common INF and INX file directives
when you build the driver.
Setting Stampinf properties for driver projects

2. In the property pages for the driver project, select Configuration Proper ties and then select Stampinf .
If you want to add this property page to your project, so that you can run the Stampinf during the build process,
see the WDK and Visual Studio build environment and the Stampinf task.
STA M P IN F O P T IO N DESC RIP T IO N
Enable Architecture Enables the replacement of the $ARCH$ variable used in

INX files. If enabled, the value specified for Architecture
is used. If No is specified, the $ARCH$ variable is
removed. For example, "Standard.NT$ARCH$" becomes
"Standard.NT".
Architecture Specifies the architecture string to replace the $ARCH$

variable that is used in INX files. The default value is
$(InfArch), a macro that selects the current active
configuration in Visual Studio. Possible values include
x86 , x64 . This setting is equivalent to specifying the
Stampinf option -a [ architecture] .
Enable VersionStamp Enables the version time stamp. If enabled, the Driver
Version Number must not be empty. The Driver
Version Number specifies the time that is written in
the INF DriverVer directive for the version number. If
not enabled, see the description of the default behavior
for this option under Driver Version Number .
Driver Version Number Specifies the time that is written in the INF DriverVer
directive for the version number. The format for the
time is hours.minutes.seconds.milliseconds (for example,
11.30.20.15). This option is useful during development
because it provides a convenient way to increase the
version number of the driver. This setting is equivalent to
specifying the Stampinf option -v [ time | ] .
To use the current time, specify an asterisk () with this
parameter.
Default behavior:
If the Driver Version Number is not specified, or if
Enable VersionStamp is No or unspecified, Stampinf
uses one of the following version number values:
If the STAMPINF_VERSION environment variable
is set, Stampinf uses the version number value
that is specified by this environment variable.
If the STAMPINF_VERSION environment variable
is not specified, Stampinf extracts the version
number from the ntverp.h file.
Note By default, the STAMPINF_VERSION environment

variable is not set when you build a driver unless you set it
as a system environment variable. To specify this
environment variable within the Visual Studio build
environment, see How to: Use Environment Variables in a
Build.
Enable DateStamp Enables the date stamp. If enabled, the Driver Version
Directive Date must not be empty. If not enabled, see
the description of the default behavior for this option
under Driver Version Directive Date .
Driver Version Directive Date Specifies the date that is written in the INF DriverVer
directive . The format for the date is month/date/year
(for example, 10/20/2011 ).
To use the current date, specify an asterisk () with this
parameter.
Default behavior:
If the Driver Version Directive Date parameter is not
specified, or if Enable DateStamp is No or unspecified,
Stampinf uses one of the following date values:
If the STAMPINF_DATE environment variable is
set, Stampinf uses the date value that is specified
by this environment variable.
If the STAMPINF_DATE environment variable is
not specified, Stampinf uses the current date.
This setting is equivalent to specifying the Stampinf
option -d [ date|] .
Note By default, the STAMPINF_DATE environment variable

is not set when you build a driver unless you set it as a
system environment variable. To specify this environment
variable within the Visual Studio build environment, see
How to: Use Environment Variables in a Build.
Driver Version Directive Section Specifies the INF section in which to put the INF
DriverVer directive . The default location for this
directive is the INF Version section .
option -s section.
KMDF Version Number Specifies the version of KMDF that this driver depends
on. This is used to customize the KmdfLibraryVersion
and KMDF co-installer name in the INF file. This option
replaces the $KMDFVERSION$ and
$KMDFCOINSTALLERVERSION$ keywords in the INF file.
The string has the following format:
<major_version>.<minor_version>
For example, if you specify 1.5 as the version string, the
values 1.5 and 01005 are used for the two keywords
(respectively).
option -k KMDFversion.
UMDF Version Number Specifies the version of UMDF that this driver depends
on. This option is used to specify the
UmdfLibraryVersion and UMDF co-installer name in the
INF file. The version that is specified replaces the
$UMDFVERSION$ and $UMDFCOINSTALLERVERSION$
keywords in the INF file. The version string has the
following format:
<major_version>.<minor_version>.<service_version>
(where <service_version> is typically zero).
For example, if you specify 1.5.0 as the version string,
the values 1.5.0 and 01005 are used for the major and
minor keywords (respectively).
option -u UMDFversion.
Catalog File Name Specifies the value that is written in the CatalogFile
directive in the INF Version section . By default, the
CatalogFile directive is not written.
option -c catalogfile.
Verbose Shows verbose Stampinf output.

option -n .
Version Header Path Specifies the location of Ntverp.h file. The path represent
the fully qualified location of the directory containing
Ntverp.h.
option -i path.
Related topics
Stampinf
INF DriverVer directive
INF Version section
WDK and Visual Studio build environment
Stampinf task
How to: Use Environment Variables in a Build
Converting WDK 8.1 Projects to WDK 10
This topic describes how to convert a driver project that was created using Microsoft Visual Studio 2013 and
Windows Driver Kit (WDK) 8.1 to a driver project that builds in Microsoft Visual Studio 2015 with the Windows
Driver Kit (WDK) 10.
Visual Studio 2015 has new compiler warnings and errors. Even if your driver project built with no errors in
Visual Studio 2013, you might see errors when you build it in Visual Studio 2015.
Use these steps to convert the projects in a driver solution.
1. In Visual Studio 2015, open the legacy driver solution.
Visual Studio automatically runs ProjectUpgradeTool to convert the projects in this solution. You can also
run this tool from the command line. By default, when you install the WDK, ProjectUpgradeTool.exe
installs in Windows Kits\10\bin\x86.
Visual Studio opens a Review Solution Actions dialog with the title Upgrade VC++ Compiler and
Libraries . Select OK and Visual Studio attempts to upgrade all projects in the solution.
If you see a File Modification Detected dialog, choose Reload All .
2. In the Solution Explorer pane, select and hold (or right-click) the driver project name and choose
Proper ties . Select the Configuration Manager button. In the Active solution configuration list,
choose <New...> . Type a name and copy the settings from a Windows 8.1 project context. Select OK .
Typically, the converted solution contains two configuration profiles, one for debug (testing) and one for
release. To create a similar environment with WDK 10, simply choose <New...> twice. To create a debug
profile, copy from the Win 8.1 Debug profile. To create a release profile, copy from the Win 8.1
Release profile.
3. In WDK versions prior to WDK 10, your driver solution always needed a package project. In WDK 10, you
only need a package project if you are including multiple drivers in a driver package. Use the following
guidelines:
If you have only one driver in the solution and a package project exists, delete it.
If you have more than one driver in the solution, ensure that your solution contains a package
project. Then, for each driver project in the solution, open project properties and navigate to
Configuration Proper ties > Driver Settings . Set BuildPackage to No . If you are building
from the command line, set /p:Suppor tsPackaging=false .
4. Again in driver project properties, choose Proper ties . Navigate to Configuration Proper ties >
Driver Settings > General > Target OS Version . Select Windows 10.
Verify that Target Platform is set to Desktop , and build the solution. Fix any errors that occur.
5. Once the solution builds successfully, change Target Platform to Universal .
Build the solution again. At this point, the only errors are from the ApiValidator tool, which checks if the
driver calls any non-universal functionality. Replace any calls to non-universal DDIs with calls to universal
DDIs.
For more information about ApiValidator, see Validating Universal Windows drivers.
To learn how to determine the target platform for a given DDI, see Target platform on driver reference
pages.
Driver convergence model for Windows 10
To make your device work on Windows and Windows Phone releases before Windows 10, you probably needed
to write two separate drivers, for example one for Windows 8.1 and one for Windows Phone 8.1. In Windows 10,
in most cases, you can write one driver that will run on any Windows 10 version. This topic describes
convergence plans for device driver interfaces in Windows 10 and provides details when there are version-
specific differences. It answers these questions:
For legacy drivers, will a Windows 8.1 driver work on Windows 10 for desktop editions (Home, Pro, and
Enterprise) and/or Windows 10 Mobile?
For new drivers, can I build one driver with the Windows 10 kit that will work on Windows 10 for desktop
editions and Windows 10 Mobile?
W IN DO W S 8. 1 DRIVER B IN A RY RUN S
T EC H N O LO GY O N W IN DO W S 10? C H A N GES F O R W IN DO W S 10
Audio Yes Starting in Windows 10, you can

write a Kernel-Mode Driver
Framework (KMDF) audio driver
that calls KMDF interfaces for PnP,
power management, and idle
management. For I/O handling, a
KMDF audio driver should not use
the I/O queue functionality in
WDF, but should instead use the
existing COM interfaces provided
by PortClass. However, your driver
can use the framework's support
for timers, interrupts, DMA, and
remote I/O targets. KMDF audio
drivers work on both Windows 10
for desktop editions and Windows
10 Mobile.
Existing Windows 8.1 drivers that
link to PortClass continue to work
on Windows 10 for desktop
editions and Windows 10 Mobile.
Biometric Yes The Windows Biometric

Framework (WBF) is available in
both Windows 10 for desktop
If you are developing a new
biometric driver for Windows 10
Mobile, you can use a
Windows 8.1 WBF driver as a
starting point.
Bluetooth Yes In Windows 10, the Bluetooth

transport driver interface for all
devices is converged and uses a
universal Bluetooth driver model.
You can write a single driver that
runs on all Windows device
platforms.
The Bluetooth audio driver surface
area is diverged for Windows 10
and allows the following two
options:
You can write a new universal
audio driver that works for
both desktop and mobile
devices.
An existing Windows Phone 8.1
Bluetooth audio driver will run
on Windows 10 Mobile.
Camera Yes Features previously available in

Windows Phone 8.1 (such as auto
focus and HFR) will be available in
Legacy camera drivers from
Windows 8.1 will require
modifications to take advantage of
these features.
Cellular Yes Windows 10 continues to support

MBIM 1.0 (Mobile Broadband
Interface Model) for data cards on
PCs.
Equivalent cellular and wi-fi
connection management using
converged stack. Mobile operators
can use Open Mobile Alliance
Device Management (OMA DM)
configuration of cellular settings in
Also, OEMs will have access to
Multivariant provisioning in both
Windows 10 for desktop editions
and Windows 10 Mobile, while the
Mobile Broadband Account
Experience (MBAE) will still be
available in Windows 10 for
desktop editions.
Display Yes Already converged. Windows

Display Driver Model (WDDM) 1.3
runs on Windows 8.1 and
Windows Phone 8.1. WDDM 1.3
continues to be supported in
Windows 10. WDDM 2.0 is new
for Windows 10. To use Direct3D
(D3D) 12 runtime and features,
must have a WDDM 2.0 driver.
Location Yes New Global Navigation Satellite

System (GNSS) adapter DDI for
Windows 10.
Windows 8.1 sensor will be
supported using a Global
Navigation Satellite System (GNSS)
legacy PE.
NFC Yes New Windows 10 DDI for Smart

card, Radio Manager, SE.
A Windows 8.1 NFC driver
continues to work, but cannot
take advantage of the new
features.
Sensor Yes New drivers for Windows 10 can

write a User-Mode Driver
Framework (UMDF) 2.x driver that
uses common sensor stack (similar
to Windows Phone 8.1 model) and
same driver package works on
Windows 10 for desktop editions
and Windows 10 Mobile.
Windows 8.1 sensor class
extension uses UMDF 1. Windows
Phone 8.1 sensor class extension
uses UMDF 2. For Windows 10,
new sensor class extension uses
UMDF 2 like Windows Phone 8.1.
To build using Windows 10 kit,
must use latter. Driver binary from
Windows 8.1 still runs on
Windows 10. HID class driver still
inbox for Windows 10, no vendor-
supplied driver and no firmware
changes required if you use the
defined existing HID types from
Windows 8.1.
Touch/Precision Touchpad (PTP) Yes In Windows 10, both HID and

touch miniport drivers will be
supported. Vendors can update a
legacy HID driver or implement a
new touch miniport driver.
For Windows 10 Mobile, bus
restrictions removed, no longer
limited to USB, I2C. Current class
drivers remain in place, any other
bus requires HID miniport driver.
Can provide a filter driver to
support custom gestures.
USB Yes Windows 8.1 provides a host

controller stack. Windows 10 adds
a function stack that allows the
device with a host controller
(PC/tablet/phone) to work as a
peripheral device.
Windows Driver Frameworks (WDF) Yes Windows 10 ships with KMDF

1.15, UMDF 2.15, UMDF 1.11, and
earlier framework versions.
Windows 10 Mobile also ships
with KMDF 1.15, UMDF 2.15, and
earlier framework versions. Note
that UMDF version 1 is not
available in Windows 10 Mobile.
Only KMDF and UMDF version 2
can be used to write Windows
drivers.
WLAN Yes WDI (WLAN Device Driver

Interface) is the new universal
WLAN driver model for
Windows 10. WLAN device
manufacturers can write a single
WDI miniport driver that runs on
all device platforms, and requires
less code than the previous native
WLAN driver model. All new
WLAN features introduced in
Windows 10 require WDI-based
drivers.
Vendor-supplied native WLAN
drivers continue to work in
Windows 10, but functionality is
limited to the version of Windows
for which they were developed.
Target platform on driver reference pages
In the Requirements block at the bottom of Microsoft driver reference pages, you'll see an entry called Target
Platform . This line lists editions of Windows to which the page applies.
Here's an example of such an entry:
The values specified in Target Platform map to the values you can use in Visual Studio, in the Target Platform
property under Configuration Proper ties->Driver Settings->General . Windows Drivers can use any
DDI that specifies Universal as the Target Platform.
Here are the values you might see for Target Platform , and what they mean:
T ERM DESC RIP T IO N
Universal A driver binary in a Windows Driver can call this device

driver interface (DDI). For more info, see Getting Started with
Windows drivers.
Desktop A driver binary for Windows 10 for desktop editions or

Windows Server 2016 can call this DDI.
A Windows Driver runs on the following Universal Windows Platform (UWP)-based editions of Windows 10:
Windows 10 for desktop editions (Home, Pro, and Enterprise)
Windows 10 in S-Mode
Windows 10 IoT Core
Windows Server 2016
Analyzing a Driver Using Code Analysis and
Verification Tools
Code analysis and verification tools can help improve the stability and reliability of your driver by systematically
analyzing the source code. The code analysis and verification tools can detect errors that are missed by the
compiler and by conventional runtime testing. Additionally they can determine whether the driver correctly
interacts with the Windows operating system kernel. Using Microsoft Visual Studio and the Windows Driver Kit
(WDK), you can configure the code analysis and verification tools to run as part of the build process, or you can
schedule the tools to analyze your driver at a predetermined time.
C/C++ Code Analysis Tool for Windows Drivers

The Windows 8 release of the WDK provides enhancements to the C/C++ Code Analysis tool included with
Visual Studio. Specifically, the WDK provides a specialized driver module that is designed to detect errors in
kernel-mode driver code. This driver module is integrated into the C/C++ Code Analysis tool.
When to use: You can run the C/C++ Code Analysis tool for drivers very early in the development cycle, as
soon as the code compiles correctly.
For information about the Code Analysis tool in Visual Studio, see:
Analyzing Application Quality using Code Analysis
Code Analysis for Drivers
How to run Code Analysis for drivers
Using SAL Annotations to Reduce C/C++ Code Defects
SAL 2.0 Annotations for Windows Drivers
Note In previous versions of the WDK, the driver-specific module for code analysis was part of a standalone
tool called PREfast for Drivers (PFD). PREfast for Drivers was also integrated into the WDK Build environment, as
part of Microsoft Automated Code Review (OACR).
Static Driver Verifier

Static Driver Verifier (SDV) is a static verification tool that systematically analyzes the source code of Windows
kernel-mode drivers. SDV determines whether the driver correctly interacts with the Windows operating system
kernel. SDV can be launched from the Driver menu in Visual Studio or from the Visual Studio Command
Prompt window.
When to use: Run Static Driver Verifier early in the development cycle on drivers that compile correctly. Run
Static Driver Verifier before you begin the test cycle.
For information about Static Driver Verifier, see:
Overview: Static Driver Verifier
How to: Using Static Driver Verifier to find defects in drivers
Preparing a Computer for Manual Driver
Deployment
You can deploy a driver automatically or manually. In either case, you need to prepare the target computer first.
Here we describe how to prepare the target computer if you choose to deploy your driver manually.
Typically the computer where you install and test a driver is separate from the computer where you develop and
build the driver package. The computer where you build the driver is called the host computer, and the
computer where you install and test the driver is called the target computer or the test computer. The process of
moving the driver package to the target computer and installing the driver it is called deploying the driver.
1. On the target computer, open a Command Prompt window as Administrator. Enter bcdedit /set
TESTSIGNING ON . Reboot the target computer.
2. Copy the DevCon tool to a folder on the target computer (for example, c:\Tools). The DevCon tool is included
in the Windows Driver Kit (WDK). You can find it under the Tools directory (for example, C:\Program Files
(x86)\Windows Kits\10\Tools\x64\devcon.exe).
3. Create or get a certificate (.cer) file that you can install on the target computer. For example, when you build
one of the WDK sample drivers, the build process creates a certificate (.cer) file. The location of the certificate
file varies depending on what you have specified for configuration and platform. For example, if your
configuration is Win7 Debug and your platform is x64, then the certificate file is in your solution folder under
C++\x64\Win7Debug.
4. Copy the certificate file to a folder on your target computer (for example c:\Certificates).
5. On the target computer, select and hold (or right-click) the certificate file, and choose Install . Work through
the installation wizard.
When you build one of the WDK driver samples, the build process creates a test-signing certificate. You need to
install a test-signing certificate only once. If you have installed a certificate from a WDK driver sample, you can
install other driver samples without installing a certificate again.
What happens when you provision a computer
(WDK 8.1)
Using Microsoft Visual Studio to configure and set up driver deployment and driver testing is called
provisioning a target computer or provisioning a test computer. For information about provisioning, see
Provision a computer for driver deployment and testing (WDK 8.1). Here we show what happens when you use
version 8.1 of the Windows Driver Kit (WDK) to provision a target computer.
When you provision a computer (WDK 8.1)

Provisioning a computer performs the following tasks:
Copies installation files to %SystemDrive%\DriverTest
Creates a user named WDKRemoteUser and switches to that user
Installs .NET 4.0 if it is not already installed
Installs Microsoft Visual C++ Redistributable
Installs Test Authoring and Execution Framework (TAEF) (WDK Client)
Installs debuggers
Installs Windows Device Testing Framework (WDTF)
Turns off AutoReboot
Enables kernel memory crash dumps
Disables Screen Saver
Disables workstation lock policy
Disables ForceGuest
Sets the power policy to a high power configuration, which prevents the system from entering Standby or
Hibernate Mode when idle
Enables the RTC Wake timer
Enables and configures kernel debugging
Enables test signing of drivers
Reboots the target computer if necessary
Creates a system restore point
Removing provisioning from the target computer

Once you have provisioned a target computer, you cannot completely remove the provisioning. However, you
can remove most of the provisioning from the target computer by using Visual Studio on the host computer.
Here are the steps.
1. On the host computer, in Visual Studio, on the Driver menu, choose Test > Configure Computers .
2. Select the name of the target computer, and select Delete computer .
3. Select Remove provisioning and delete computer . Select Next .
4. When the removal process is complete, select Finish .
5. Uninstall WDK Test Target Setup from the target computer.
When you remove provisioning (WDK 8.1)

When you remove provisioning from the target computer, these items are removed:
Test Automation Framework
Debuggers
Windows Driver Testing Framework
%SystemDrive%\DriverTest folder and contents
WDKRemoteUser account
Workstation lock policy
Removing provisioning does not change these items:
Visual C++ Redistributable
AutoReboot setting
Kernel memory crash dump setting
Screen saver setting
ForceGuest setting
Power policy
RTC Wake timer setting
Kernel debugging settings
Test signing setting
What happens when you provision a computer
(WDK 8.0)
Using Microsoft Visual Studio to configure and set up driver deployment and driver testing is called
provisioning a target computer or provisioning a test computer. For information about provisioning with
Windows Driver Kit (WDK) 8 , see Provision a computer for driver deployment and testing (WDK 8). Here we
show what happens when you use version 8.0 of the Windows Driver Kit (WDK) to provision a target computer.
Note WDK 8 is not the most current version of the WDK. We recommend that you get the current version of
the WDK and provision your target computer according to the provisioning instructions here.
When you provision a computer (WDK 8.0)

Provisioning a computer performs the following tasks:
Copies installation files to %SystemDrive%\DriverTest
Creates a user named WDKRemoteUser and switches to that user
Installs .NET 4.0 if it is not already installed
Installs Microsoft Visual C++ Redistributable
Installs Test Authoring and Execution Framework (TAEF) (WDK Client)
Installs debuggers
Installs Windows Device Testing Framework (WDTF)
Turns off AutoReboot
Enables kernel memory crash dumps
Disables Screen Saver
Disables workstation lock policy
Disables ForceGuest
Sets the power policy to a high power configuration, which prevents the system from entering Standby or
Hibernate Mode when idle
Enables the RTC Wake timer
Enables and configures kernel debugging
Enables test signing of drivers
Reboots the target computer if necessary
Creates a system restore point
Removing provisioning from the target computer

Once you have provisioned a target computer, you cannot completely remove the provisioning. However, you
can remove most of the provisioning from the target computer by using Visual Studio on the host computer.
Here are the steps.
1. On the host computer, in Visual Studio, on the Driver menu, choose Test > Configure Computers .
2. Select the name of the target computer, and select Delete computer .
3. Select Remove provisioning and delete computer . Select Next .
4. When the removal process is complete, select Finish .
When you remove provisioning (WDK 8.0)
When you remove provisioning from the target computer, these items are removed:
Visual C++ Redistributable
Test Automation Framework
Debuggers
%SystemDrive%\DriverTest folder and contents
WDKRemoteUser account
Removing provisioning does not change these items:
AutoReboot setting
Kernel memory crash dump setting
Screen saver setting
Workstation lock policy
ForceGuest setting
Power policy
RTC Wake timer setting
Kernel debugging settings
Test signing setting
Troubleshooting Configuration of Driver
Deployment, Testing and Debugging
Provisioning a target computer is described in Provision a computer for driver deployment and testing (WDK
8.1). Here we give some troubleshooting tips for the provisioning process.
General tips
Configure Computers menu command is inactive
Provisioning fails
Provisioning fails
The network path was not found
The network name cannot be found
Could not access remote machine
Debugger won't connect or break in

Debugger network connection
Debugger 1394 connection
Debugger serial connection
Configure Computers menu command is inactive

When you first start Microsoft Visual Studio, the Test > Configure Computers command on the Driver menu
might be inactive (greyed out). If you wait about 20 seconds, and then select the Driver menu again, the Test >
Configure Computers command will be available.
Provisioning fails: General tips

If provisioning fails, read the sequence of messages in the Computer Configuration window. Typically, this
window also displays the location of the configuration log. View the log and make a note of its location so you
can refer to it later.
The path to the log might contain a hidden folder. For example, in the following path, AppData is a hidden folder.
C:\Users\currentUser\AppData\Roaming\Microsoft\DriverTest\Install
The log file will have a name similar to this:
Driver Test Computer Configuration 20121115130459167.log
Provisioning fails: The network path was not found

When you start to provision a target computer, you might see a message that says The network path was not
found .
On the target computer, make sure that you have turned on Network Discover y and that you have turned on
File and Printer Sharing for the appropriate network profile. For example, if the host and target computers
are joined to a network domain, you must turn on network discovery and file and printer sharing for the
Domain network profile. For more information, see Provision a computer for driver deployment and testing
(WDK 8.1).
Make sure you can ping the target computer from the host computer. On the host computer, open a Command
Prompt window, and enter ping targetComputerName, where targetComputerName is the name of the target
computer.
Note You might see several messages before you see the message The network path was not found . Some
of those messages might make you think that the network path was found and the first steps of provisioning
were succeeding. In fact, the network path was not found and no portion of provisioning succeeded. For
example, you might see this:
Connecting to computer "MyComputer"

Installing driver test automation service
Getting computer system information
Copying driver test automation files
The network path was not found.
Provisioning fails: The network name cannot be found

When you start to provision a target computer, you might see a message that says The network name cannot
be found . Double check the name of the target computer. If the computer name you entered originally was
incorrect, start the provisioning wizard again (Driver > Test > Configure Computers) . Select the incorrect
computer name, and select Next . For Computer name , enter the correct name of the target computer, and
complete the wizard.
Note You might see several messages before you see the message The network name cannot be found .
Some of those messages might make you think that the computer name was found and the first steps of
provisioning were succeeding. In fact, the computer name was not found, and no portion of provisioning
succeeded. For example, you might see this:
Connecting to computer "NonExistentComputer"

Getting computer system information
Copying driver test automation files
The network name cannot be found.
Note The messages that are displayed when you enter an incorrect target computer name can vary. For
example, you might see a message about enabling network discovery.
Connecting to computer "NonExistentComputer"

Could not access remote machine "NonExistentComputer" over the network.
Error:53. Automatic configuration of machines over the network requires
that network discovery and file and print sharing be enabled on the
target machine.
Or you might be prompted to enter credentials.
Enter your password to connect to: NonExistentComputer
Provisioning fails: Could not access remote machine

When you start to provision a target computer, you might see a message that says Could not access the
remote machine "computerName" over the network . This message can be displayed for several reasons.
Verify that your host and target computers are both joined to the same domain or the same workgroup. For
more information, see Provision a computer for driver deployment and testing (WDK 8.1). Verify that you
entered the correct name for the target computer. Verify that you have enabled network discovery and file and
print sharing on the target computer.
Debugger breakpoints are not triggered for kernel-mode driver

1. Deploy the driver with breakpoints disabled.
2. Manually break into the kernel-mode debugger.
3. Set an exception on load of the module:
sxe ld <DriverName>
4. Enable the breakpoint and resume execution.

5. On the target computer, disable the device node and then re-enable it.
Debugger won't connect or break in: Network connection

Verify that your debugging application is allowed through the firewall for all network types.
Check with network administrator about ports that allow network debugging.
If the target computer has more than one network adapter, you must specify the bus parameters of the network
adapter that you intend to use for debugging.
For more information, see Troubleshooting Tips for Debugging over a Network Cable
Debugger won't connect or break in: 1394 connection

If the target computer has more than one 1394 controller, you must specify the bus parameters of the 1394
controller that you intend to use for debugging. For more information, see Troubleshooting Tips for Debugging
over a 1394 Cable.
Debugger won't connect or break in : Serial connection

Check the COM port numbers on the host and target computer. Verify that you have configured the same baud
rate for debugging on both the host and target computers. For more information, see Troubleshooting Tips for
Debugging over a Serial Cable
Driver projects and packages

A driver project is the Microsoft Visual Studio project which produces a driver binary (such as a .sys file), and
potentially the driver's INF file.
A driver package is the collection of files used to install a driver. The package includes an INF file, and files and
binaries referred to by that INF. Visual Studio uses driver packages to automatically deploy and debug your
driver to a remote target.
A driver package is a separate project which collects output from one or more projects, such as driver projects.
The driver package's project, when built, then produces the driver package which Visual Studio uses to deploy
the driver.
Note
If you use a driver template to create a driver solution, then the template should automatically create a solution
that contains two projects. One for the driver, and another for the driver package.
Manually creating a driver package

If your solution does not have a driver package, you can manually create one in Visual Studio by choosing New
> Project from the File menu. For examples of how to create a driver package, see Writing Your First Driver.
To manually create a new driver package for an existing solution that does not already have one, use the "Driver
Install Package" template. Select File->New->Project . Then select Windows Drivers > Package > "Driver
Install Package" from the dialog. Then in the Solution drop-down, select Add to solution and select Ok .
Modifying an existing driver package
If your solution already contains a driver package, you can modify it to reference other projects in the solution.
In the Solution Explorer pane, open the driver package project, select and hold (or right-click) References ,
choose Add Reference... and select the project to reference.
To remove a reference to an existing project, select and hold (or right-click) the existing project you no longer
want to reference and select Remove .
Multiple drivers in a solution

You can add multiple drivers and their packages to your solution. Similar to "Modifying an existing driver
package" you can create a new driver solution, or add a reference to an existing one. If your solution already
contains a driver package, you can modify it to reference additional driver projects in the solution.
In the Solution Explorer pane, open the driver package project, select and hold (or right-click) References ,
choose Add Reference... and select the project to reference.
To remove a reference to an existing project, select and hold (or right-click) the existing project you no longer
want to reference and select Remove .
See the "Toaster Sample Driver" sample for an example of a single solution that contains multiple drivers:
Related topics
Signing a Driver
Creating a Device Metadata Package
You can create a Device Metadata Package for your device directly in Visual Studio. The Device Metadata
Authoring Wizard, located in the Driver menu, allows you to author specific information that appears to end
users in Windows, including the icon and name for your device. It also allows you to associate a UWP device app
to your device, which gets installed automatically when a user first connects the device.
For more information about how to use the Device Metadata Authoring Wizard, please see Device Metadata
Authoring Wizard.
Signing a Driver
All drivers running on 64-bit versions of Windows must be signed before Windows will load them. However,
driver signing is not required on 32-bit versions of Windows.
In order to sign a driver, a certificate is required. You can create your own certificate to sign your driver with
during development and testing. However, for a public release you must sign your driver with a certificate
issued by a trusted root authority.
Note A driver package project can package the output of other projects. If you build a driver package project,
Microsoft Visual Studio will build the other projects on which it has dependencies. The driver package project
has its own driver signing properties that are separate from any other dependent projects, and its driver signing
properties apply only to the catalog (if any) produced by the driver package project. That is, the driver package
project will not automatically add an embedded signature to driver binaries produced by other projects, as a
different certificate may be used to sign the other driver projects, for example, a test certificate, and the result in
such a case would be a driver package where the binaries are unintentionally signed with one certificate, while
the package catalog is signed with a different certificate. This can result in performance degradation. For
example, if a boot start driver binary's embedded signature is invalid, Windows cannot use certificate it was
signed with to validate the binary. Instead, Windows must validate the binary against the catalog's signature,
which would increase boot time.
This section describes how to use Visual Studio to sign a driver package.
Before you install a driver on a computer running a 64-bit version of Windows, you must sign the driver
package. For testing purposes, you can test sign the driver package, which is a more relaxed form of signing
than signing for public release.
In Microsoft Visual Studio, test signing is enabled by default. Suppose you have created a KMDF driver solution
as described in Writing a KMDF driver based on a template. When you build the solution, you can see in the
Output window that the driver package has been test signed.
Enabling test signing manually

To manually enable test signing, follow these steps.
1. In Visual Studio, open a solution that has a driver package project. Select and hold (or right-click) the
driver package project, and choose Proper ties .
2. In the property pages for the package, navigate to Configuation Proper ties > Driver Signing >
General . In the Sign Mode drop-down list, select Test Sign .
3. In the property pages for the package, navigate to Configuation Proper ties > Inf2Cat > General . In
the Run Inf2Cat drop-down list, select Yes .
Viewing the signed driver package

After you build your solution, navigate in File Explorer to the folder that contains your driver package. One of the
files in the package is a catalog file. The catalog file contains the digital signature for the package. For an
example of viewing the files in a signed package, see Writing a KMDF driver based on a template.
Sharing a signing certificate

When you test sign a driver package, Visual Studio creates a signing certificate (PFX file) and imports it into a
certificate store on your host computer. When you deploy your test-signed driver package to a test computer,
Visual Studio copies a verification certificate (CER file) to the test computer. If you want to share the certificate
with developers who are building drivers on other host computers, you must share the signing certificate, not
the verification certificate.
To share the signing certificate, follow these steps.
In Visual Studio, in the Solution Explorer window, select and hold (or right-click) your driver package
project, and choose Proper ties .
In the property pages for the package, navigate to Configuation Proper ties > Driver Signing >
General . In the Test Cer tificate field, choose Select From Store .
In the Select Certificate dialog box, locate your test-signing certificate. The name of the certificate will be
similar to WDKTestCert yourName. Select your test-signing certificate, and select Proper ties . In the
Details tab, select Copy to File .
Follow the instructions in the Certificate Export Wizard to export a PFX file. When you are asked whether
you want to export the private key, select Yes, expor t the private key .
Share the exported PFX file with the other developers.
Related topics
Writing Your First Driver
Building a Driver
Developing, Testing, and Deploying Drivers
Before you release a driver package to the public, we recommend that you submit the package for certification.
For more information, see Windows Hardware Certification and Hardware Dashboard Services. To submit a
driver package for certification, you must sign the package with a certificate that you obtain from a trusted
certification authority like VeriSign. For more information, see Get a VeriSign Certificate. You will also need a
cross certificate, which is provided by Microsoft.
Suppose you have obtained a pair of files from Verisign: a private key file (PVK) and a software publishing
certificate (SPC). Also suppose you have a Microsoft Visual Studio solution that contains a driver project named
MyDriver and a driver package project named MyDriver Package. To sign your driver package, follow these
steps.
1. Use the Pvk2Pfx tool to create a Personal Information Exchange (PFX) certificate. The Pvk2Pfx tool takes
your PVK and SPC files as input and creates a single PFX file. For this exercise, assume that your PFX file is
named MyCert.pfx.
Note Once you have created your PFX file, you can reuse it for other driver projects and on other driver
development computers.
2. To determine which cross certificate you need, see Cross-Certificates for Kernel Mode Code Signing.
Verify that the required cross certificate is in $(BASEDIR)\CrossCertificates, where $(BASEDIR) is the base
directory of the Windows kits (for example c:\Program Files (x86)\Windows Kits\8.0\CrossCertificates). If
the required cross certificate is not there, download the cross certificate from Microsoft, and copy it to
$(BASEDIR)\CrossCertificates.
3. In Visual Studio, open the solution that contains the MyDriver and MyDriver Package projects. If the
Solution Explorer window is not already open, choose Solution Explorer from the View menu. In the
Solution Explorer window, select and hold (or right-click) the package project, MyDriver Package , and
choose Proper ties .
4. In the property pages for the package, navigate to Configuration Proper ties > Driver Signing >
General . In the Sign Mode drop-down list, select Production Sign . For Production Cer tificate , do
one of the following:
Enter the path to your signing certificate (for example c:\Certs\MyCert.pfx).
Choose Select From File , and browse to your signing certificate.
Choose Select From Store and choose a certificate that you previously imported into a
certificate store.
Note To import a certificate into a store, select and hold (or right-click) the certificate file (PFX
file), and choose Install PFX . Follow the instructions in the Certificate Import Wizard.
Note If you decide to use a different certificate at a later time, be sure that your new certificate
gets imported into the certificate store. If you choose Select From File and browse to your new
certificate, the new certificate will be automatically imported into the certificate store. However, if
you manually enter the path to your new certificate, it will not be automatically imported into the
certificate store. In that case, you must select and hold (or right-click) your new certificate file and
choose Install PFX .
5. On the Driver Signing > General property page, for TimeStampSer ver , select one of the time stamp
servers in the drop-down list.
Note Using one of the time stamp servers in the drop-down list requires that you be connected to the
Internet when you build your driver package. If you need to be disconnected from the Internet when you
build your driver package, clear the TimeStampSer ver field.
6. In the property pages for the package, navigate to Configuration Proper ties > Inf2Cat > General . In
the Run Inf2Cat drop-down list, select Yes .
7. Close the property pages for the package.
8. Select and hold (or right-click) the driver project, MyDriver , and choose Proper ties
9. In the property pages for the driver, navigate to Configuration Proper ties > Driver Signing >
General . Set TimeStampSer ver to the same value that you used in the driver package properties. Set
Sign Mode to Production Sign , and set Production Cer tificate to the same value that you used in
the driver package properties.
10. When you are ready to build your driver package, press F5 . Visual Studio will automatically sign your
package and your driver file. If you have configured deployment, Visual Studio will also deploy your
signed driver package to a test computer. For more information, see Provision a computer for driver
deployment and testing (WDK 8.1).
Viewing the driver package files

After you build your solution, navigate in File Explorer to the folder that contains your driver package. One of the
files in the package is a catalog file. The catalog file contains the digital signature for the package. For an
example of viewing the files in a signed package, see Writing a KMDF driver based on a template.
Getting a WHQL release signature

When your driver package passes the certification tests, it can be signed by Windows Hardware Quality Labs
(WHQL). If your driver package is signed by WHQL, it can be distributed through the Windows Update program
or other Microsoft-supported distribution mechanisms.
To install on Windows 10, 8.1, 8, and 7, your driver package can have a single SHA1 signature.
Starting in Windows 10, you also need to submit any new Windows 10 kernel mode driver for digital signing on
the Windows Hardware Developer Center Dashboard portal. Both kernel and user mode driver submissions
must have a valid Extended Validation (“EV”) Code Signing Certificate.
** Note ** SHA1 deprecation does not apply to drivers. For info about the end of SHA1 support in Windows, see
Windows Enforcement of Authenticode Code Signing and Timestamping.
Signing a package compared to signing an individual driver file

A driver package contains several files. Typically a driver package has one or more driver files, an information
file (INF file), and a catalog file. The catalog file contains information about the other files in the package. When
you sign the catalog file, the signature in the catalog file serves as the signature for the entire driver package. In
other words, signing the catalog file is the same as signing the driver package.
In most cases, it is sufficient to sign the driver package, and it is not necessary to sign individual driver files.
Sometimes, however, you need to sign both the package and the individual driver files. For example, boot-start
driver files must be individually signed. Signing an individual driver file is referred to as embedding a signature
in the driver file.
Suppose you have a Visual Studio solution that contains a driver project named MyDriver and a driver package
project named MyDriver Package. Visual Studio provides two sets of property pages: one for My Driver and one
for My Driver Package. To sign the driver package, set the Driver Signing properties of My Driver Package. To
embed a signature in the individual driver file, set the Driver Signing properties of My Driver.
When you set the driver package properties for production signing, remember to adjust the signing properties
of the individual driver files accordingly. Either turn off signing for the individual driver files, or set the individual
driver files to use the same certificate that you specified for the package.
Note To see the hash (also called the thumb print) of a certificate, open a Command Prompt window and
navigate to the directory that contains your certificate. Enter the command cer tutil -dump CertName.pfx,
where CertName.pfx is the name of your certificate.
Related topics
Driver Signing changes in Windows 10
Availability of SHA-2 Code Signing Support for Windows 7 and Windows Server 2008 R2
Signing a Driver
Windows Hardware Certification
Hardware Dashboard Services
Driver Signing Requirements for Windows
Cross-Certificates for Kernel Mode Code Signing
Kernel-Mode Code Signing Walkthrough
Driver Signing
Installing a Boot-Start Driver
Tools for Signing Drivers
Driver Signing Properties
When a project is selected in Solution Explorer, the Proper ties dialog under the Driver Signing node, displays
two sections of properties:
Under General:
Sign Mode
Test Sign - Microsoft Visual Studio should sign the driver with the test certificate specified in Test
Cer tificate (default). If no certificate is specified in Test Cer tificate then Visual Studio will create one for
the driver. Note : Windows requires all 64-bit drivers to be signed.
Production Sign - Visual Studio should sign the driver with the production certificate specified in
Production Cer tificate .
Off - Visual Studio should not sign the driver with any certificate.
Test Cer tificate
Blank - No test certificate is selected (default).
<Edit...> - Selects the certificate to use when Sign Mode is set to Test Sign .
Production Cer tificate
Blank - No production certificate is selected (default).
<Edit...> - Selects the certificate to use when Sign Mode is set to Production Sign .
TimeStampSer ver
Verisign - Use Verisign to time stamp the driver (default).
GlobalSign - Use Globalsign to time stamp the driver.
None - Do not time stamp the driver.
Disable Warnings
No - Display warnings when signing the driver (default).
Yes - Do not display warnings when signing the driver.
Enable Diagnostic Verbosity
No - Do not display diagnostic verbosity when signing the driver (default).
Yes - Display diagnostic verbosity when signing the driver.
File Digest Algorithm
Blank - No file digest algorithm is selected (default).
<Edit...> - Select the file digest algorithm to use when signing the driver.
Under Command Line:

Additional Options
Additional options to specify when signing the driver.
Taking advantage of the Visual Studio development environment, the WDK provides a test feature that enables
you to build, deploy, and debug a driver on a test computer. To successfully deploy a driver to a test system
using the WDK, you must first set up and configure a test computer. You can set up and configure multiple
computers if you want to test your driver under different testing scenarios.
Setting up the test computer

Follow the instructions for Provision a computer for driver deployment and testing (WDK 10).
Note If you run into difficulties setting up the test computer, see Troubleshooting Configuration of Driver
Deployment, Testing and Debugging.
Setting deployment properties for your driver solution

From the property pages for your driver project, you have additional control over how you want your driver
deployed for testing. You can choose to deploy the driver automatically whenever you build the driver solution
in each configuration.
2. In the property pages for the driver project, select Configuration Proper ties , select Driver Install , and
then select Deployment .
3. Select a test computer that you have configured, or select the name of a computer that you want to
configure for testing. See Provision a computer for driver deployment and testing (WDK 10).
When you enable deployment for your driver package project, the driver is automatically deployed to the
test computer you have selected when you build your solution. You can use the Deployment property
page to configure options for driver installation and deployment. See Deployment Properties for Driver
Package Projects.
4. When you enable deployment on a test computer, you can also automatically enable and configure Driver
Verifier, KMDF Verifier, or UMDF Verifier on the test computer to enhance the effectiveness of testing. To
set these options for the driver package project, select Configuration Proper ties , select Driver Install ,
and then select the following property pages.
Driver Verifier Properties for Driver Package Projects
KMDF Verifier Properties for Driver Package Projects
UMDF Verifier Properties for Driver Package Projects
Building a driver and deploying the driver to test computer

1. Before you deploy your driver, make sure that you can build your driver solution. A driver solution must
include the driver and driver package so that the driver can be installed on the test computer. For more
information, see Creating a Driver Package and Building a Driver.
2. Before you deploy the driver to the test computer, you also need to sign the driver package. See Signing a
Driver During Development and Testing.
3. Select the test computer that you have configured.
4. To deploy the driver, select Build Solution or Deploy Solution from the Build menu, or press F5 to build,
deploy, and start debugging.
5. On the test computer, you might see a dialog box asking you to confirm that changes should be made. In this
case, deployment is paused until you confirm.
When you deploy a driver, the driver files are copied to the %Systemdrive%\drivertest\drivers folder on the test
computer. If something goes wrong during deployment, you can check to see if the files are copied to the test
computer. Verify that the .inf, .cat, test cert, and .sys files, and any other necessary files, are present
%systemdrive%\drivertest\drivers folder.
Troubleshooting driver deployment

Here are some tips for troubleshooting driver deployment to a test computer when you use Visual Studio and
the WDK.
Deployment fails due to Error code: 2
Add the following registry key:
HKLM\Software\Microsoft\DriverTest\Ser vice
Under this key, create a DWORD value DebugSession , and set it to 0.
You only need to set this value once, and it persists for future deployments.
Can't find the deployment proper ties for the driver project
The deployment properties are only available if you have a driver package. If your driver solution does not have
a driver package project, you need to add one. The driver package contains components, such as the INF file that
are needed for installation. For more information, see Driver Packages and Creating a Driver Package.
Afer you have added the driver package, you can select and hold (or right-select) the driver package project in
Solution Explorer and select Proper ties . In the property pages for the driver package, select Configuration
Proper ties , select Driver Install , and then select Deployment .
Problems selecting, configuring or locating the target computer
For instruction on how to set up the target computer, using Windows Driver Kit (WDK) 8.1 and Windows Driver
Kit (WDK) 8, see Provision a computer for driver deployment and testing (WDK 10). If you have problems with
provisioning the target computer, see Troubleshooting Configuration of Driver Deployment, Testing and
Debugging.
If the target computer is running an N or KN version of Windows, you must install the Media Feature Pack for N
and KN versions of Windows. See Provision a computer for driver deployment and testing (WDK 10) for more
information.
Problems installing the driver on 64-bit version of Windows
Starting with Windows Vista, all 64-bit versions of Windows require driver code to have a digital signature for
the driver to load. See Signing a Driver and Signing a Driver During Development and Testing.
Problems installing the driver (general)
The WDK can deploy and install a driver package on a test computer, but only if the driver has all the necessary
components for installation, such as an INF file. See Driver Packages more information. Make sure you can
install the driver outside of Visual Studio and the WDK. For example, use the Device Console utility, Devcon to
test whether you can install the driver. Make sure the device (if you have one) is connected to the target
computer. For more information, see Device and Driver Installation and Creating a Driver Package.
Deployment Properties for Driver Package Projects
You can configure the automatic deployment of a driver package on a remote test computer in each
configuration of your project. From the project property pages for your driver, you have additional control over
how you want to deploy your driver for testing. You can choose to deploy the driver automatically whenever you
build the driver solution in each configuration. For more information about deployment, see Provision a
computer for driver deployment and testing (WDK 8.1) and Deploying a Driver to a Test Computer.
Setting deployment properties for driver package projects

1. Open the property pages for your driver package. Select and hold (or right-click) the driver package
project in Solution Explorer and select Proper ties .
Note If your driver solution does not have a driver package project, you need to add one. See Creating a
Driver Package. The deployment properties are only available if you have a driver package.
2. In the property pages for the driver package, select Configuration Proper ties , select Driver Install ,
and then select Deployment .
3. Select the Enable deployment option. When this option is selected, you can select the test computer to
use, and you can configure options for driver installation and deployment.
Project Configuration and Platform

The configuration list and platform list enables you to apply different deployment settings for different project
configuration and platform combinations. For example, you can deploy a driver to one test computer using a set
of deployment options for debug builds and to a different test computer and deployment options for release
builds.
Enabling deployment
You can choose to deploy your driver package on a test computer by selecting Enable deployment . In
combination with the configuration list, you could choose to disable deployment for debug builds and enable it
for release builds.
To ensure that you are testing the latest version of the driver, select Remove previous driver versions
before deployment .
Target computer name

You can choose the target computer to use for deployment and testing. If you have already configured your test
computers, you can select one from this list. If you have not configured a test computer, you can configure one
using the Browse button. For more information about configuring a test computer, see Deploying a Driver to a
Test Computer. Make sure that the project configuration and platform match the target architecture of your test
system. A common deployment error occurs when you attempt to install an x86 (Win32) driver on a system
running an x64 version of Windows.
For information about working with the debugger, see Getting Started with Windows Debugging.
Driver installation options

Do not install - This is the default option. You can choose not to install if you are importing the driver package
to the Driver Store or if you are enabling and setting driver verifier options on the test computer.
Hardware ID Driver Update - To deploy a driver for an actual hardware device, use Install and Verify
instead. To deploy a driver for a root-enumerated driver, you can use either Hardware ID Driver Update or
Install and Verify . If you choose to use Hardware ID Driver Update, you must enter the same hardware ID that
appears in your INF file, and that hardware ID must have the form Root\Xxx. If you choose this option, the files
are copied to the %Systemdrive%\drivertest\drivers folder on the remote computer. The Device Console utility,
Devcon, installs the driver for that hardware ID and INF file from the package. For example, you can select
Hardware ID Driver Update and set the HWID to Root\ yourprojectname. Make sure to exclude any spaces in
your project name.
Custom Command Line - You can choose to run your own custom command scripts upon installation. If you
want to run a custom command script, make sure to add the necessary files under the Additional Files section.
The additional files are copied to the %Systemdrive%\drivertest\drivers folder on the remote computer.
Install and Verify - You can choose to test your installation using an automated test script. When you select
this option and specify the Default Driver Package Installation Task (possible reboot) or Default Printer
Driver Package Installation Task (possible reboot) , the test reads the driver's INF file and installs the driver.
The test then verifies that the driver is up and running. Upon completion, the test provides detailed information
about the success or failure of the installation task.
Optional Device Quer y - The default value is %PathToInf%. The path to the driver's INF files is substituted
automatically. There should be no need to change this value unless you have a need to place the INF files in a
different location.
Additional Files
You can use the Additional Files box to specify custom installation scripts or applications that you want to
copy to the remote test computer. The files that you specify here are added to the
%Systemdrive%\drivertest\drivers folder on the remote computer.
Related topics
Getting Started with Windows Debugging
Driver Verifier Properties for Driver Package
Projects
Driver Verifier is a run-time verification tool that increases the effectiveness of your driver testing. You can
enable and configure Driver Verifier to run on all test computers when you deploy your driver for testing.
You should always set up a kernel mode debugging connection with the test computer when you enable Driver
Verifier on the remote test computer. For information about configuring a target computer and setting up a
debug cable, see Getting Started with Windows Debugging.
Setting Driver Verifier properties for driver package projects

1. Open the property pages for your driver package. Select and hold (or right-click) the driver package project
in Solution Explorer and select Proper ties .
2. In the property pages for the driver package, select Configuration Proper ties , select Driver Install , and
then select Driver Verification .
3. Select the Enable Driver Verification option. When this option is selected, you can select the driver or
drivers to verify on the test computer and you can select the Driver Verifier options to use.
Project Configuration and Platform

The configuration list and platform list let you apply different deployment settings for different project
configuration and platform combinations. For example, you can deploy a driver to one test computer using a set
of deployment options for debug builds and to a different test computer using deployment options for release
builds.
Enable Driver Verifier

You can enable Driver Verifier on the test computer for all drivers on the computer, for the driver project only, or
for a list of specified drivers. For example, you might want to enable Driver Verifier for the set of drivers on the
stack for a particular device.
Verify Drivers
Specifies which driver or drivers to verify on the test computer.
All Drivers
Specifies that Driver Verifier verifies all installed drivers on the remote test computer.
Project Output
Specifies that Driver Verifier verifies the driver project installed on the remote test computer. This is the default
option.
Driver List
Specifies the driver or list of drivers that Driver Verifier verifies on the remote test computer. For example, you
could list all of the drivers associated with a particular device. Specify the drivers by binary name, for example,
Driver.sys. Use a semicolon to separate a list of drivers. Wildcard values, such as n*.sys, are not supported.
Driver Verifier Standard Flags
You can configure the following Driver Verifier options on the test computer.
DDI compliance checking (Windows 8)
When this option is active, Driver Verifier applies a set of device driver interface (DDI) rules that check for
the proper interaction between a driver and the kernel interface of the operating system.
Deadlock detection
When this option is active, Driver Verifier monitors the driver's use of spin locks, mutexes, and fast
mutexes. This detects whether the driver's code has the potential for causing a deadlock at some point.
DMA verification
When this option is active, Driver Verifier monitors the driver's use of direct memory access (DMA)
routines. This detects improper use of DMA buffers, adapters, and map registers.
Force IRQL checking
When this option is active, Driver Verifier places extreme memory pressure on the driver by invalidating
pageable code. If the driver attempts to access paged memory at the wrong IRQL or while holding a spin
lock, Driver Verifier detects this behavior.
I/O verification
When this option is active, Driver Verifier allocates the driver's Interrupt Request Packets (IRPs) from a
special pool, and monitors the driver's I/O handling. This detects illegal or inconsistent use of I/O
routines. Driver Verifier also monitors the calls of several I/O Manager routines and performs stress
testing of Plug-and-Play (PnP) IRPs, power IRPs and WMI IRPs.
Miscellaneous checks
When this option is active, Driver Verifier looks for common causes of driver crashes, such as the
mishandling of freed memory.
Pool tracking
When this option is active, Driver Verifier checks to see whether the driver has freed all of its memory
allocations when it is unloaded. This reveals memory leaks.
Security checks
When this option is active, Driver Verifier looks for common errors that can result in security
vulnerabilities, such as a reference to user-mode addresses by kernel-mode routines.
Special pool checking
When this option is active, Driver Verifier allocates most of the driver's memory requests from a special
pool. This special pool is monitored for memory overruns, memory underruns, and memory that is
accessed after it is freed.
Driver Verifier Scenario Specific Settings

Low resources simulation
When this option is active, Driver Verifier randomly fails pool allocation requests and other resource
requests. By injecting these allocation faults into the system, Driver Verifier tests the driver's ability to
cope with a low-resource situation.
Force pending I/O requests
When this option is active, Driver Verifier tests the driver's response to STATUS_PENDING return values
by returning STATUS_PENDING for random calls to IoCallDriver .
IRP logging
When this option is active, Driver Verifier monitors a driver's use of IRPs and creates a log of IRP use.
Invariant MDL Checking for Stack (Windows 8)
The Invariant MDL Checking for Stack option monitors how the driver handles invariant MDL buffers
across the driver stack. Driver Verifier can detect illegal modification of invariant MDL buffers. To use this
option, I/O Verification must be enabled on at least one driver.
Invariant MDL Checking for Driver (Windows 8)
The Invariant MDL Checking for Driver option monitors how the driver handles invariant MDL buffers on
a per-driver basis. This option detects illegal modification of invariant MDL buffers. To use this option, you
must enable I/O Verification on at least one driver.
Power Framework Delay Fuzzing (Windows 8)
When this option is active, Driver Verifier randomizes thread schedules to help flush out concurrency
errors in the driver.
Stack Based Failure Injection (Windows 8)
The Stack Based Failure Injection option injects resource failures in kernel-mode drivers. This option uses
a special driver, KmAutoFail.sys, in conjunction with Driver Verifier to penetrate driver error handling
paths.
Note You cannot combine Stack Based Failure Injection with Low resources simulation.
Driver Verifier options that require I/O Verification

There are four options that require you to first enable I/O Verification. If I/O Verification is not enabled, these
options are not enabled.
Force Pending I/O Requests
IRP Logging
Invariant MDL Checking for Stack
Invariant MDL Checking for Driver
Related topics
Driver Verifier
KMDF Verifier Properties for Driver Package
Projects
Sets the properties for the KMDF Verifier (or framework verifier) on a remote computer. You can use these
settings when you build and deploy a KMDF driver to a test computer. For information about KMDF drivers, see
Kernel-Mode Driver Framework.
For more information about the framework verifier, see Using the Framework's Verifier and WDF Verifier
Control Application.
Setting KMDF Verifier properties for driver package projects

then select KMDF Verifier .
3. Select the Enable KMDF Verifier option and select KMDF verifier is always on . When this option is
selected, you can configure the framework verification options for KMDF drivers.
Enable KMDF Verifier Enables the KMDF verifier on the test computer. The
choices are KMDF verifier is always on or KMDF
verifier is off . If the KMDF verifier is not enabled, basic
framework verification is enabled as part of Driver
Verifier if KMDF version is 1.9 or higher.
KMDF Ser vice Names Specifies the service names of the KDMF drivers to
monitor.
IRQL checks Enables IRQL checks and critical memory leak checks.
For ward Compatible Checks Enables checks created after the current driver version.
For ward Progress Handler Testing Specifies options for testing forward progress handling
of your driver.
No Allocation Failures No faults will be simulated to
test the forward progress handling of your driver.
Fail All Allocations All I/O requests destined for a
forward progress queue will appear to fail, relying on
your driver's forward progress handling.
Randomly Fail Allocations Randomly fail I/O requests
destined for a forward progress queue.
Track KMDF Object Handles Specifies the list of object handle types to track.
Enable KMDF Loader Messages Enables KMDF loader messages through the debugger.
A reboot of the target computer is required to enable
this.
Starting with Windows Vista, the operating system
suppresses DbgPrint output by default, which makes the
WDF Loader diagnostic messages unusable until the
suppression is overridden. KDMF Verifier can manage
this for you so that KMDF loader diagnostics are
available in the kernel debugger for these systems.
Verbose logging Enables verbose logging.
Memor y Pages for Logs Specifies the number of non-paged pool pages (1-10) to
allocate for kernel event trace logs. The options are
Runtime Choice or [1 -10 ]. If Runtime Choice , the
number of pages depends on the KMDF runtime.
Starting with KMDF 1.9, the runtime uses more pages
when verification is enabled with verbose logging.
Fail Memor y Allocations Specifies the number of successful memory allocations

allowed before the KMDF verifier starts to fail all
memory allocations.
Related topics
Kernel-Mode Driver Framework
Driver Verifier
UMDF Verifier Properties for Driver Package
Projects
Sets the properties for the UMDF Verifier on a test computer. You can use these settings when you build and
deploy a driver to a test computer.
For information about deployment, see Provision a computer for driver deployment and testing (WDK 8.1) and
For information about debugging UMDF drivers, see How to Enable Debugging of a UMDF Driver and WDF
Verifier Control Application.
Setting UMDF Verifier properties for driver projects

then select UMDF Verifier .
3. Select the Deploy UMDF Verifier option. When this option is enabled (Yes ), you can select the UMDF
Verifier options to use on the test computer to verify a UMDF driver.
Deploy UMDF Verifier Enables the UMDF verifier settings on the test computer.
UMDF Ser vice Names Specifies the service names of the UMDF drivers to
monitor.
Enable Object Tracking Tracks all created UMDF objects.
Enable Reference Count Tracking Tracks all UMDF object references.
Maximum Restar t Attempts Maximum number of times UMDF will restart a failed
host process.
UMDF Logging level Specifies the amount of information logged by the

UMDF verifier for the drivers it is hosting.
Only Critical and Fatal Errors - Logs only critical and
fatal errors.
All Errors - Logs all errors.
Warnings and all Errors - Logs warnings and all
errors.
Informational events, Warnings and all Errors -
Logs informational events, warnings, and all errors.
Verbose Output (All Events of any Sor t) - Logs all
events.
Log to Kernel Debugger Logs verifier output to the kernel debugger.
Break into Kernel Debugger Break into kernel debugger when the UMDF host
process fails.
Attach to Kernel Debugger Attaches to the kernel debugger if no user-mode

debugger is attached.
Timeout on Driver Load (sec) Specifies the time to wait (in seconds) before attaching
the debugger after the driver loads.
Timeout on Driver Star t (sec) Specifies the time to wait (in seconds) before attaching
the debugger after the driver starts.
Verify at Current Level Verifies drivers built using earlier versions of the
framework against current framework versions rules.
Related topics
User-Mode Driver Framework
Driver Verifier
Inf2Cat Properties for Driver Package Projects
Sets the properties for the Inf2Cat tool. The Inf2Cat tool can be used to create catalog files for any driver
package that has an INF file.
Setting Inf2Cat properties for driver package projects

2. In the property pages for the driver package, select Configuration Proper ties and then select Inf2Cat .
3. Select the Run Inf2Cat option. This option runs the Inf2Cat tool on any INF files in the project (for example,
.inf, .inx, or .inv files).
If the driver package is installed by using an INF file, use the Inf2Cat tool to create the catalog file. Inf2Cat
validates that files referenced in the INF file are present in the package. To add files to the package, use the
property pages for the package project and driver project. See Creating a Driver Package for more information.
Run Inf2Cat Runs the Inf2Cat tool on any INF files in the project (for
example, .inf, .inx, or .inv files).
Windows Version List Specifies a list of Windows versions supported by the .inf
file. Separate each Windows version with a comma. The
default setting is $(Inf2CatWindowsVersionList), a macro
that builds the driver for the active platform and
configuration.
This setting is equivalent to specifying the Inf2Cat
option /os: WindowsVersionList.
Include Page Hashes Include page hashes with files. Optionally followed by a
list of files.
option /pageHashes[: file1][, file2]...] .
Add PE Attribute Adds a PE catalog attribute to files. Optionally followed

by a list of files.
option /pe[: file1[, file2]...] .
Add Drm Adds a DRM-level catalog attribute to files. Optionally

followed by a list of files.
option /drm[: file1[, file2]...] .
Verbose Displays detailed information about tool output in the

Visual Studio Output window.
option /verbose .
No Catalog Prevents the creation of any catalog files.

option /nocat .
Use Local Time Use the local time zone while verifying the INF
DriverVer Directive directive. By default UTC, is used.
option /uselocaltime .
For more information about the Inf2Cat tool, see Using Inf2Cat to Create a Catalog File.
For information about property pages and projects, see the WDK and Visual Studio build environment.
Related topics
Creating a Catalog File for a PnP Driver Package
Inf2Cat
Signing a Driver
Using Inf2Cat to Create a Catalog File
WDK and Visual Studio build environment
How to create a custom driver installation script
If your deployment scenario requires more than installing the driver package on the test computers, you can
choose to run your own custom command scripts upon installation.
Prerequisites
Driver package that is test signed and ready to install. You must first create and build your driver and then
create a driver package for installation. For more information, see Building a Driver and Creating a Driver
Package.
Test computers that are configured and provisioned for deployment. See How to test a driver at runtime
using Visual Studio.
Instructions
Step 1: To run your own custom command scripts upon installation
From the project property pages for your driver package, you can configure whether you want to automatically
deploy a driver package on a test computer. You can also run a custom installation script from these pages. You
can choose to deploy the driver automatically whenever you build the driver solution in each configuration. For
more information about deployment, see Deploying a Driver to a Test Computer and Deployment Properties for
Driver Projects.
1. Open the property pages for your driver package project. Select and hold (or right-click) the driver
project in Solution Explorer and select Proper ties .
2. In the property pages for the driver package, select Configuration Proper ties , select Driver Settings ,
and then select Deployment .
3. Select Enable deployment and then select the test computer to use.
4. Select Custom Command Line . In the box, type custom command scripts that you want to run upon
installation.
5. In the Additional Files text box, add the command script and other installation files to be copied to the
test computer. When the driver is deployed, the additional files are copied to the
%Systemdrive%\drivertest\drivers folder on the remote computer.
Related topics
Deployment Properties for Driver Projects
Building a Driver
Installing a driver on Windows 10 Mobile
To install a driver on Windows 10 Mobile, use an .spkg file. An .spkg ("package file") is a standalone module that
contains your driver package.
WDK 10 includes PkgGen, a tool that generates package files. You run PkgGen in Visual Studio when you build
your driver, using the following procedure.
Using PkgGen to generate a package file
1. Select and hold (or right-click) the driver project and choose Add->New Item . Next, under Visual C++-
>Windows Driver , choose Package Manifest . Select Add .
2. Visual Studio adds a file called Package.pkg.xml to your driver project. You can select and hold (or right-click)
the file and choose properties to verify that the item type is PkgGen . (On this same property page, you can
set Excluded from Build to Yes if you decide later that you want to build this driver project and not
generate a package file.) Select OK .
3. Select and hold (or right-click) the driver project and choose Proper ties . Under Configuration Properties,
open the PackageGen node and change Version to any value you like.
4. Save your work and restart Visual Studio as administrator.
5. Build your driver. Visual Studio links against the required libraries and generates a .cat file, an .inf file, a driver
binary, and an .spkg file.
To view the contents of the package file, append a .cab suffix to the file name and then open the cab file in
Windows Explorer.
To learn about running PkgGen outside of Visual Studio, see Creating mobile packages.
To install a mobile driver package (.spkg file), you have two options.
If you are updating an existing package on a target system or adding a new package to the target, use
IUTool.exe to install an .spkg driver package.
If you are combining packages into a mobile OS image, use ImgGen to add the .spkg driver package to a full
flash update (FFU) image that can then be flashed to a mobile device.
Using IUTool to add a mobile driver package (.spkg) to a running device
1. IUTool.exe is in the \tools\bin\<architecture> subdirectory of WDK 10.
Attach your mobile device to the PC. Then, from an elevated command prompt, issue the following
command:
IUTool -p MyKmdfDriver.spkg
2. For more information, see Adding a driver to a test image.

Using ImgGen to add a driver package (.spkg) to a mobile OS image (.ffu)
1. After you install Visual Studio, on the Start screen, select the Visual Studio 2015 folder. Select and hold (or
right-click) Developer Command Prompt for VS2015 , and choose Run as Administrator .
Flashing a mobile OS image (.ffu)

To flash the image to the device, either use the Microsoft-supplied FFUTool, or develop custom OEM flashing
tools.
Debugging a Driver
Debugging a kernel-mode driver requires two computers. The debugger runs on the host computer, and the
code being debugged runs on the target computer. The target computer is also called the test computer. You can
debug a user-mode driver on the host computer or on a separate target computer. Before you can debug a
driver running on a target computer, you must configure the target computer for debugging.
For general information about debugging drivers, see Getting Started with Windows Debugging.
For information about configuring a target computer and setting up a debug cable using a network connection,
see Setting Up KDNET Network Kernel Debugging Automatically.
See Also
Windows Debugging.
Testing a Driver
The WDK adds a driver testing interface to Visual Studio that allows you to build, deploy, install, and test a driver
on a remote test computer on your network. The WDK also provides a collection of device driver tests that you
can use to test features and functions of your driver. You can also write customize or write your own driver tests
using the Driver Test Template in Visual Studio.
Video Demonstration
This video demonstrates the how to run driver-related tests in a test group.
This section describes some strategies for testing driver, and information about how you select and configure a
remote computer to use for testing.
To prepare a driver for public distribution, you should run the Windows Hardware Certification Kit (HCK). For
information about the Windows Certification program and how to obtain the HCK, see Windows Hardware
Certification Program.
The WDK provides the test binaries and tools which make it easy to run the Device Fundamentals tests from the
command-line. For more information, see Run the DevFund Tests via the command-line.
TO P IC DESC RIP T IO N
Tips for testing drivers during development When should you star t testing? As soon as you
have the requirements for your driver, you can begin to
design test cases to test that the critical requirements
have been implemented. Studies show that finding and
fixing defects in code becomes more expensive the
longer the defects remain in the code. Finding and fixing
defects early in the development cycle is less costly and
disruptive than finding defects after the code has been
released and distributed. Creating your test cases early
can also help you find problems in your design.
How to test a driver at runtime using Visual Studio The WDK extensions to Visual Studio provide a device
testing interface that enables you to conveniently build,
deploy, install, and test a driver on a test computer on
your network. The WDK provides a collection of device
driver tests that you can use to test the features and
functions of your driver.
How to write a driver test using a Driver Test template You can use the Windows Driver Kit (WDK) for
Windows 8 to create your own driver tests or to
customize some of the tests that are provided. You can
deploy the tests that you create to remote test
computers using the driver testing framework that the
WDK provides for Microsoft Visual Studio Ultimate 2012.
See Also
Tools for Verifying Drivers
Tips for testing drivers during development
When should you star t testing? As soon as you have the requirements for your driver, you can begin to
design test cases to test that the critical requirements have been implemented. Studies show that finding and
fixing defects in code becomes more expensive the longer the defects remain in the code. Finding and fixing
defects early in the development cycle is less costly and disruptive than finding defects after the code has been
released and distributed. Creating your test cases early can also help you find problems in your design.
Suggestions for testing during development

Use the following suggestions for testing your driver code and driver package.
To help you find bugs at compile time:
Declare your driver-supplied callback functions and dispatch routines using function-role types. This
helps to improve the accuracy of the code analysis and verification tools and the effectiveness of your test
time. For more information about how to declare your driver-supplied functions, see Using Function Role
Type Declarations.
Compile your code using the Level4 (/W4) Warnings option. Fixing warnings that are detected by the
compiler will increase the quality of the driver code and help eliminate additional defects earlier in the
development cycle.
Annotate your code using the Microsoft source code annotation language (SAL) 2.0. The annotations
describe how a function uses its parameters—the assumptions it makes about them, and the guarantees
it makes when it finishes. The annotations also improve the accuracy of the code analysis tools. For more
information about the driver-specific annotations, see SAL 2.0 Annotations for Drivers.
Use the tools for verifying drivers while you are developing your driver. For guidelines about when to use
specific verification tools, see Analyzing a Driver using Code Analysis and Verification Tools and the
Survey of Verification Tools.
To test your driver package:
Create the INF file and your driver package early in the development process and use it throughout
testing.
Use the InfVerif tool to verify the structure and syntax of the INF file, and to help you diagnose the INF file
and other installation related issues.
Use the Inf2Cat tool (with the /nocat option) to do additional INF file verification. Inf2Cat can verify
that the files referenced by the INF are present and placed in the package directory as the INF expects
them to be.
Sign drivers to facilitate the installation and testing of drivers, as described in Signing Drivers during
Development and Test.
Run the DriverInstall test that is included as part of the Device Fundamental tests that are provided in
the WDK. See How to test a driver at runtime using Visual Studio and How to select and configure the
Device Fundamental Tests. The DriverInstall test can be run after the driver has been deployed to the
test computer. You can add the DriverInstall test to a Driver Test Group. The DriverInstall test appears
in the Driver Test Categories under All Tests\Basic\Device Fundamentals\DriverInstall.
Troubleshoot device installation problems by using Device Manager to view system information about
drivers and devices and by consulting the SetupAPI log. The SetupAPI log contains information about the
sequence of operations that occurred during the installation of a device or driver.
Using Visual Studio and the WDK, you can test and troubleshoot driver package installation when you
deploy your driver to a test computer, see Deploying a Driver to a Test Computer. Select the Install and
Verify option from the Deployment Properties for Driver Package Projects. When you select this option
and specify the Default Driver Package Installation Task (possible reboot) or Default Printer
Driver Package Installation Task (possible reboot) , the test reads the driver's INF file and installs
the driver. The test then verifies that the driver is up and running. Upon completion, the test provides
detailed information about the success or failure of the installation task. The results show in the Driver
Test Group Explorer , under Driver Test Groups > Driver Installation. The task name is Default Driver
Package Installation Task .
To test your driver at run time:
Run the Device Fundamental tests that are included in the WDK. See How to test a driver at runtime using
Visual Studio and How to select and configure the Device Fundamental Tests.
Set up a debugger so that you can troubleshoot and debug the test results. For more information, see
Getting Started with Windows Debugging.
Enable Driver Verifier on the test computers you use for deployment, see Driver Verifier Properties for
Driver Projects. Select the DDI Compliance checking option. If your driver fails DDI Compliance checking,
run Static Driver Verifier and specify the rule or rules that caused the failure. The Static Driver Verifier can
help you locate the cause of the bug in your source files.
Test your driver and device on as many different hardware configurations as you possibly can. Varying
the hardware can help you find conflicts between devices and other errors in device interactions. For
example, you should test your driver and device on computers that have different processor architectures
and on computers that are running 32-bit and 64-bit versions of Windows.
Test your driver and device on multiprocessor systems. Race conditions and other timing problems
appear on multiprocessor systems that would not otherwise be found. See How to select and configure
the Device Fundamental Tests and Boot Parameters to Test Drivers for Multiple Processor Group Support.
Test your driver and device for specific system and hardware conditions, particularly edge conditions. For
example, these conditions might include "D3 hot" and "D3 cold." Make sure your driver and device can
return correctly from device power state "D3 hot" (without losing power) and "D3 cold" (when power is
removed from the device). For more information, see How to select and configure the Device
Fundamental Tests.
The WDK extensions to Visual Studio provide a device testing interface that enables you to conveniently build,
deploy, install, and test a driver on a test computer on your network. The WDK provides a collection of device
driver tests that you can use to test the features and functions of your driver.
Prerequisites
A Driver Package that is ready to install. You must first create and build your driver and then create a Driver
Package for installation. For more information, see Building a Driver and Creating a Driver Package.
The driver must be test signed. For more information, see Signing a Driver.
A test computer (or computers). The test computer must be on the same network as the computer that you
are using for development. Both computers must be connected to the same domain, or both connected to
the network under the same workgroup. The test computer should be running the version of Windows that
you want to target for testing.
A device to be tested.
(Recommended) Set up a kernel mode debugging connection to the test computer. To use a network
connection for kernel mode debugging, the target computer must be running Windows 8. On computers
running Windows 7 or Windows Vista, you can set up a USB, 1394, or a serial connection for kernel mode
debugging. For more information, see Provision a computer for driver deployment and testing (WDK 8.1).
Instructions
Step 1: Configure computers for testing
From Visual Studio, you can configure and provision computers for testing. When you configure the test
computers, the WDK driver test framework automatically enables the test computer for remote debugging and
transfers the necessary test binaries and support files.
1. If you have not already done so, follow the instructions to Provision a computer for driver deployment and
testing (WDK 8.1).
2. Connect the device that you want to test to the test computer or computers.
After you have configured and provisioned a test computer, you can use Visual Studio to deploy drivers,
schedule tests, and debug drivers on the test computer. For information about deployment and about how you
can deploy a driver automatically at build time, see Deploying a Driver to a Test Computer.
You can also enable and set options for Driver Verifier, the runtime verification tool for drivers. Driver Verifier
monitors your driver as you run tests on the test computer. For information about setting the Driver Verifier
options for deployment, see Driver Verifier Properties for Driver Projects.
You can also run tests outside of Visual Studio, for more information see How to test a driver at runtime from a
Command Prompt. Starting in WDK 8.1, you can copy and run the HCK Test Suites on test computers using
command scripts. See How to run the HCK Test Suites in WDK 8.1.
Step 2: Select an HCK Test Suite to run on the test computer (using WDK 8.1)
Starting with WDK 8.1, you can select HCK Test Suites to run on the test computer. The HCK Test Suites include
the Device Fundamentals Tests, and Windows Hardware Certification kit (HCK) Basic tests for graphics, imaging,
wireless LAN, mobile broadband (CDMA and GSM), and WiFi Direct devices.
See How to run the HCK Test Suites in WDK 8.1.
Step 3: Select the tests to run on the test computer (WDK 8 and WDK 8.1)
To make driver testing on different test targets easier, tests are scheduled to run against test systems in units
called test groups. A driver test group is a collection of tests that you select to run on the test computer. The
driver test groups help you organize your tests and test results from each test pass. You can save your test
results to separate folders. You can create and manage test groups, change parameters passed to the tests in the
test groups, and schedule them to run against your test systems.
1. From the Driver menu, select Test and then select Test Group Explorer .
2. In the Driver Test Group Explorer window, select the Create a new test group button. Or, select
New Test Group from the Driver menu.
3. In the Driver Test Group window for the group that you created, type a name in Test Group Name
text box to identify the group. The default name is Driver Test Group_nnnnn, where nnnnn represents the
number of the test group
4. Select Add/Remove Tests .
5. In the Add or Remove Driver Tests dialog box, you can specify the driver test category and
architecture (All, x86, x64, ARM). By default all tests are shown. To view the test categories, select the
folders in the Driver Test Categories drop-down list.
For example, in WDK 8, to select all of the Device Fundamentals tests that are used in the Windows
Hardware Certification Kit (HCK), select All Tests , Cer tification , and Device Fundamentals . For
information about the tests, see How to select and configure the Device Fundamentals Tests.
In WDK 8.1, the Device Fundamentals tests are under All Tests , HCK Tests , Cer tification , and Device
Fundamentals folder. In WDK 8.1 the Driver Test Categories include the HCK (Basic) Tests. See How to
run the HCK Test Suites in WDK 8.1 for more information.
6. Be sure that you select the tests that match the architecture of the intended test computer (x86, x64,
ARM). Use the Architecture Filter to show only those tests that will run on your test computer.
7. Select >> to add the selected tests.
Step 4: Configure test parameters
After you select the tests for your test group, you can configure any of the runtime parameters that are passed
to the driver tests. For example, many of the Device Fundamentals Tests have a parameter DQ, which stands for
Device Query. This is a Simple Data Evaluation Language (SDEL) query. The Windows Driver Test Framework
provides SDEL as a query language to simplify the task of collecting targets based on attributes or relationships.
For example, to run the tests for USB devices only, use the device query: class='usb'. You can change the value of
each test parameter in the test group.
1. You can view and edit the all of the runtime test parameters for a test by selecting on the name of the test
in the Driver Test Group window. The Driver Test Group window provides a description of the
selected test and also provides a description of the test parameters that you select. For information about
setting the test parameters, see How to select and configure the Device Fundamentals Tests
2. After you select the tests, set the parameters, and name the group, select Save .
When you save the test group, the test group will become the currently selected test group, and the name
of the test group will appear in the Driver Test toolbar. You can now run tests against the currently
selected remote test computer (also shown in the Driver Test toolbar).
Step 5: Build and deploy the driver
From the Build menu, select Deploy Solution .
For information about deploying a driver automatically at build time, see Deploying a Driver to a Test Computer.
For information about automatically setting the Driver Verifier options on the test computer, see Driver Verifier
Properties for Driver Projects. You should always enable Driver Verifier on your test computer.
Step 6: Run the tests on the test computer
From the Driver menu, select Test > Run test . By default, the Run test command runs all of the tests in the
currently selected test group.
Remarks
For information about the driver tests and test categories, see How to select and configure the Device
Fundamentals Tests. For information about the testing framework, see Test Authoring and Execution Framework
(TAEF) and Windows Driver Test Framework (WDTF).
You can write your own driver tests and deploy those tests on test computers. For more information, see How to
write a driver test.
Running the Device Fundamentals tests in Visual Studio early in the development cycle will help you when are
finally ready to test your driver using the Windows Hardware Certification Kit (HCK).
Related topics
How to select and configure the Device Fundamentals Tests
Hardware Certification Program
Windows Hardware Certification Kit (HCK)
To make testing Windows drivers easier in the WDK, starting with WDK 8.1 you can now select HCK test suites to
run on the test computers. The HCK test suites include the device fundamentals tests, and tests for graphics,
imaging, wireless LAN, mobile broadband (CDMA and GSM), and WiFi Direct devices. These are the same tests
that are used in the Windows Hardware Certification kit (Windows HCK). See Windows Certification Program
for Hardware for information about the Windows HCK.
You can run the HCK test from a Command Prompt window or from Visual Studio. In addition, you can copy
these tests to a new location—which might be another computer or a USB key drive—and run the tests from
that location. Launching the tests automatically sets any local configuration needed to run the tests.
Running the HCK Test Suites on a test computer using Visual Studio
Running the HCK Test Suites from a Command Prompt window
Running the HCK Test Suites on a test computer using Visual Studio
If you have not already done so, follow the instructions in Provision a computer for driver deployment and
testing (WDK 8.1). After you have configured a test computer, the name of the test computer appears in the
toolbar. Be sure you have select the test computer that you have configured for device you are testing with the
HCK Test Suite.
Prepare the test computer as needed, by installing the device and driver and any additional requirements for
test topology (see the HCK test prerequisites for the device you are testing). In place of the HCK Studio and HCK
controller, you run the tests using Visual Studio and WDK 8.1.
To select an HCK Test Suite to run on a test computer
1. From the Driver menu, select Test and then select Test Group Explorer .
2. In the Driver Test Group Explorer window, select one of the HCK Test Suites.
When you select a Test Suite, the Test Suite appears in the Driver Test Group window.
3. Be sure you have selected the test computer that you have configured for device you are testing with the
HCK Test Suite.
4. To use the HCK test suites, you must also follow the configuration requirements for the device you are
testing.
5. You can use the check boxes to select the tests that match the architecture of the intended test computer
(x86, x64, ARM).
6. From the Driver menu, select Test > Run test . By default, the Run test command runs all of the tests in
the currently selected test group.
You can also copy one of the provided HCK Test Suites and export it, along with the necessary test support files
so that you can run the test suite from a Command Prompt window.
To expor t a Test Suite
1. In the Test Group Explorer , select and hold (or right-click) the HCK Test Suite you want to copy and select
Expor t Test Suite... from the short-cut menu. (The command runs the CopyMe.cmd script).
2. Select a destination folder for the test suite. You can export the test suite to a network share or to a USB flash
drive.
3. To run the HCK Test Suite, open a Command Prompt window on the test computer with elevated permissions.
Navigate to the destination directory and run the RunMe.cmd script. For more information, see To run the
HCK Test Suite from a Command Prompt window.
Running the HCK Test Suites from a Command Prompt window

Copy the HCK Test Suite
1. Open a Visual Studio Command Prompt window. Navigate to the %WindowsSdkDir%\Testing\Tests\HCK
Tests\Basic directory. For example, C:\Program Files (x86)\Windows Kits\8.1\Testing\Tests\HCK Tests\Basic
2. Run the CopyMe.cmd script and specify the name of test suite and destination directory. The script has
the following syntax:
CopyMe.cmd testSuite destinationPath
The testSuite is one of the following:

Device.Device Fundamentals
Device.Graphics
Device.Imaging
Device.Network.MobileBroadband.CDMA
Device.Network.MobileBroadband.GSM
Device.Network.WLAN
The destinationPath can be any valid path, including UNC paths. For example, you can copy an HCK Test
Suite to a USB flash drive, or to a share on a server.
C:\Program Files (x86)\Windows Kits\8.1\Testing\Tests\HCK Tests\Basic>CopyMe "De

vice.Device Fundamentals" d:\temp\devfund
Copying test target setup installers
Copying TAEF and WDTF infrastructure
Copying debuggers infrastructure
Copying x86 tools
Copying x64 tools
Copying arm tools
Copying test suite
Copy complete!
Run on any computer using an administrator command prompt in the same folder as
the RunMe.cmd script.
"RunMe.cmd <infFileName>"
Note If the test computer is running Windows 7, you need to download and install the Microsoft .NET
Framework 4.5 before you can run the HCK Test Suite.
To run the HCK Test Suite from a Command Prompt window
1. On the test computer that you have configured for testing, open a Command Prompt window with
elevated privileges (Run as administrator ) and navigate to the directory where you copied the HCK
Test Suite.
2. Run the RunMe.cmd script and specify the path and name of the INF file. The script has the following
syntax:
RunMe.cmd infFileName
For example:
RunMe.cmd myDriver.inf
Note The Device.Graphics test suite does not make use of an INF file, however, the RunMe.cmd script
requires an INF file. You can provide the name of substitute INF file if necessary.
HCT Test Suites

HCK Tests.Basic.Device.Device Fundamentals Test Suite
HCK Tests.Basic.Device.Graphics Test Suite
HCK Tests.Basic.Device.Imaging Test Suite
HCK Tests.Basic.Device.Network.MobileBroadband.CDMA Test Suite
HCK Tests.Basic.Device.Network.MobileBroadband.GSM Test Suite
HCK Tests.Basic.Device.Network.WLAN Test Suite
For information about specifying test parameters, see Device Fundamentals Test Parameters. If the device under
test under test or one of its child devices is a WiFi adapter or a network device, you might need to set the
Wpa2PskAesSsid, Wpa2PskPassword, or WDTFREMOTESYSTEM parameters.
HCK Tests.Basic.Device.Device Fundamentals Test Suite
Use this test suite for general reliability testing of all device types. You must follow the hardware, software, and
test requirements for the HCK tests as described in the Device.Fundamentals Reliability Testing Prerequisites. In
place of the HCK Studio and HCK controller, you run the basic tests using Visual Studio and WDK 8.1.
H C K T EST S. B A SIC . DEVIC E. DEVIC E F UN DA M EN TA L S T EST

SUIT E
Hardware, software, and test requirements Device.Fundamentals Reliability Testing Prerequisites
Test descriptions DF - PNP (disable and enable) with IO Before and After
(Basic)
DF - Sleep with IO Before and After (Basic)
HCK Tests.Basic.Device.Graphics Test Suite

Use this test suite to test graphics adapters or chipsets. You must follow the hardware, software, and test
requirements for the HCK tests as described in the Graphic Adapter or Chipset Testing Prerequisites. In place of
the HCK Studio and HCK controller, you run the basic tests using Visual Studio and WDK 8.1.
H C K T EST S. B A SIC . DEVIC E. GRA P H IC S T EST SUIT E
Hardware, software, and test requirements Graphic Adapter or Chipset Testing Prerequisites
Test descriptions Graphic Adapter or Chipset Tests
HCK Tests.Basic.Device.Imaging Test Suite

Use this test suite to test printers. The test suite uses tests that are part of the HCK Device.Imaging Testing. In
place of the HCK Studio and HCK controller, you run the basic tests using Visual Studio and WDK 8.1.
H C K T EST S. B A SIC . DEVIC E. IM A GIN G T EST SUIT E
Hardware, software, and test requirements Printer Testing Prerequisites
Test descriptions Printer Tests
HCK Tests.Basic.Device.Network.MobileBroadband.CDMA Test Suite

Use this test suite to test Mobile Broadband CDMA devices. Follow the guidelines for setting up and configuring
your device as described in the Mobile Broadband Testing Prerequisites. In place of the HCK Studio and HCK
controller, you run the basic tests using Visual Studio and WDK 8.1.
HCK
T EST S. B A SIC . DEVIC E. N ET W O RK . M O B IL EB RO A DB A N D. C DM A
T EST SUIT E
Hardware, software, and test requirements Mobile Broadband Testing Prerequisites
Test descriptions CDMA Tests
HCK Tests.Basic.Device.Network.MobileBroadband.GSM Test Suite

Use this test suite to test Mobile Broadband GSM devices. Follow the guidelines for setting up and configuring
your device as described in the Mobile Broadband Testing Prerequisites. In place of the HCK Studio and HCK
controller, you run the basic tests using Visual Studio and WDK 8.1.
HCK
T EST S. B A SIC . DEVIC E. N ET W O RK . M O B IL EB RO A DB A N D. GSM
T EST SUIT E
Hardware, software, and test requirements Mobile Broadband Testing Prerequisites
Test descriptions GSM Tests
HCK Tests.Basic.Device.Network.WLAN Test Suite

Use this test suite to test Wireless LAN (802.11) devices. Follow the guidelines for setting up and configuring
your device as described in the Wireless LAN (802.11) Testing Prerequisites for the HCK. In place of the HCK
Studio and HCK controller, you run the basic tests using Visual Studio and WDK 8.1.
H C K T EST S. B A SIC . DEVIC E. N ET W O RK . W L A N T EST SUIT E
Hardware, software, and test requirements Wireless LAN (802.11) Testing Prerequisites
Test descriptions WLAN L1 Tests
Related topics
How to test a driver a runtime using Visual Studio
How to select and configure the Device Fundamentals Tests
Windows Hardware Certification Kit (HCK)
How to select and configure the Device
Fundamentals tests
The WDK for Windows 8 provides a driver testing framework that includes a set of tests called the Device
Fundamentals tests. The Device Fundamentals tests are a collection of tests that are used both internally at
Microsoft for testing the drivers and driver samples that ship with Windows and the WDK, and externally as part
of the Windows Certification Program for Hardware. You can run the tests from your development environment.
When you run the tests, you can use the same parameters that are used for Windows Certification testing, or
you can configure and customize the run-time parameters according to your testing and debugging needs.
Getting the most from the Device Fundamentals tests

To get the most benefit from the Device Fundamentals tests, your device must be supported by the default I/O
plug-ins. To see whether your device type is supported and to determine whether there are specific
requirements for testing, refer to Provided WDTF Simple I/O plug-ins. The Device Fundamentals test also include
a utility you can use to test your device to see whether it is supported. If your device is not supported, you can
create a WDTF Simple I/O plug-in. in Visual Studio. For more information, see How to customize I/O for your
device using the WDTF Simple I/O Action Plug-in.
About the Device Fundamentals Tests

The WDK provides the Device Fundamentals tests in two configurations, Basic and Certification. In both
configurations, you can edit the test parameters to vary the length of the test, the number of test cycles to
perform, and other test parameters, depending upon how you want to test the targeted devices or drivers. The
Basic configuration is intended for general driver and device testing and debugging. Use the Basic configuration
early on and throughout the development cycle. The tests in the Basic configuration have the same settings that
are used in the Windows Certification testing, with the exception of having a shorter run time. In the
Certification configuration, the tests have the same settings that are used in the Windows Certification testing.
Use the Certification configuration to verify readiness for testing your device or driver for the Windows
Certification Program for Hardware.
The Device Fundamentals Tests include tests in the following categories.
CHAOS Tests (Device Fundamentals)
Coverage Tests (Device Fundamentals)
CPUStress Tests (Device Fundamentals)
Driver Install Tests (Device Fundamentals)
I/O Tests (Device Fundamentals)
Penetration Tests (Device Fundamentals)
PNP Tests (Device Fundamentals)
Reboot Tests (Device Fundamentals)
Sleep Tests (Device Fundamentals)
Utility
Driver Verifier
Setting the run-time test parameters
You can edit the run-time parameters for many of the Device Fundamentals tests. In the Driver Test Group
window, an arrow (») next to a test name indicates that the test has parameters that you can change. Select the
arrow (») to display the run-time parameters.
One of the most useful parameters is DQ, which specifies the target device to test. The default value (IsDevice )
tests all of the devices on the target computer. The DQ parameter takes a WDTF SDEL query that identifies the
target devices. You can specify a particular device for testing, for example:
DeviceID=’USB\ROOT_HUB\4&1CD5D022&0’ selects only the device for testing with the specified
DeviceID .
For more information about DQ and the other run-time parameters, see Device Fundamentals test parameters.
Device Fundamentals Test Parameters

PA RA M ET ER DESC RIP T IO N
DQ Identifies the device or devices that should be used for

testing. The DQ parameter takes a WDTF SDEL query
that identifies the target devices. This query can be very
flexible and it can be used to express any number of
devices, from a single device to all devices in the system.
Common examples:
To test all devices that were installed with a specific INF File:
INF::FileName= INF_File_Name
For example,
INF::OriginalInfFileName='KMDFTest.inf'
Inf::OriginalInFileName can be used with any
INF.
To test a device with a specific Device Id:
DeviceId=’ DeviceId’
For example,
DeviceID=’USB\ROOT_HUB\4&1CD5D022&0’
To test a device with a specific interface:
Interfaces:: InterfaceGUID
To test a device with a specific driver letter:
Volume::DriverLetter=’ DriveLetter’
For example, Volume::DriverLetter=’c:\’
To test a device with a specific driver:
DriverBinar yNames= mydriver.sys
Where KMDFTest.inf is the inf used to install the driver.
You can also use the folloiwng target the devices(s) that
use KMDFTest.sys driver.
(DriverBinar yNames ='KMDFTest.sys ') works.
After setting the SDEL correctly you should see the
following output on the console when you run a test.
WDTF_TARGETS : INFO : - Query("IsDevice AND
((Inf::OriginalInfFileName='KMDFTest.inf'))")
WDTF_TARGETS : INFO : Target: KMDFTest Device
ROOT\SAMPLE\0000 WDTF_TEST : INFO : WARNING:
The test is not enforcing that Driver Verifier is enabled.
WDTF_TEST : INFO : DV is enabled with Flag:=0x209bb
WDTF_TEST : INFO : DV is successfully enabled for all
drivers of this devnode(UniqueTargetName):=KMDFTest
Device ROOT\SAMPLE\0000 WDTF_TARGET : INFO : -
GetInterface("Support") WDTF_TARGET : INFO : Target:
DESKTOP-2OVFH3G WDTF_TARGETS : INFO : -
Query("IsDevice") WDTF_TARGETS : INFO : Target:
KMDFTest Device ROOT\SAMPLE\0000 WDTF_TARGETS
: INFO : - GetRelations("below-or-self/","IsDevice")
ROOT\SAMPLE\0000 WDTF_TARGETS : INFO : -
GetInterfacesIfExist("SimpleIOStressProc")
WDTF_SIMPLE_IO : INFO : - For Target:KMDFTest Device
ROOT\SAMPLE\0000 no Simple IO Interface was found.
WDTF_SIMPLE_IO : INFO : - For Target:KMDFTest Device
ROOT\SAMPLE\0000 WDTF will use the ANY Simple IO
Interface.
See attached files config and log files for more details.
ROOT\SAMPLE\0000 WDTF_TEST : INFO : Perform 1
cycle(s) of I/O termination test WDTF_TEST : INFO : I/O
termination cycle #1 WDTF_SIMPLEIO_STRESS_PROC :
INFO : - StartAsync(KMDFTest Device
ROOT\SAMPLE\0000 ) WDTF_SIMPLEIO_STRESS_PROC :
INFO : - WaitAsyncCompletion(KMDFTest Device
ROOT\SAMPLE\0000 ) WDTF_SIMPLE_IO : INFO : - For
Target:KMDFTest Device ROOT\SAMPLE\0000 no Simple
IO Interface was found. WDTF_SIMPLE_IO : INFO : - For
Target:KMDFTest Device ROOT\SAMPLE\0000 WDTF will
use the ANY Simple IO Interface. WDTF_SIMPLE_IO :
INFO : - Open(KMDFTest Device ROOT\SAMPLE\0000 )
Try count 1 WDTF_SUPPORT : INFO : - WaitForMinutes :
1 WDTF_SIMPLE_IO : INFO : - PerformIO(KMDFTest
Device ROOT\SAMPLE\0000 ) Count 1
WDTF_SIMPLEIO_STRESS_PROC : INFO : -
Terminate(KMDFTest Device ROOT\SAMPLE\0000 )
process
To test all device of a specific device Class:
For example, Class=CDROM would test all device of
class CDROM.
For example, ClassGUID= {36fc9e60-c465-11cf-
8056-444553540000} would test all the devices
whose class GUID matches the specified GUID. In this
case, the GUID is for the USB class.
DoPoolCheck True or False. Monitors the driver's use of the paged and
nonpaged system memory pools by using pool tags and
lookaside lists. This option also monitors changes in the
number of exceptions handled which might indicate
errors in exception handling.
ChangeBufferProtectionFlags True or False. Changes the memory protection flags of

buffers passed to the tested device. The memory
protection flags alternates between no access, read-only,
and read-only with page guard.
DoSimpleIO True or False. Runs SimpleI/O (if found) on test devices

before and after performing PNP operations.
DoConcurrentIO True or False. Uses WDTF concurrent I/O interface to

send I/O requests to target device stacks while
performing PnP operations.
FillZeroPageWithNull True or False. Maps the zero page and fills it with NULL
values. This test identifies drivers that do not verify a
pointer reference before dereferencing the pointer.
FuzzTestPeriod Fuzz test period in minutes.
HPU Specifies the high processor utilization percentage.
Impersonate True or False. Runs the test as a user without

administrator privileges.
IOPeriod Specifies the I/O period in minutes.
IOType Specifies the type of I/O stress test: SimpleIOStressEx or

SimpleIOStressProc (I/O in a separate process).
LPU Specifies the low processor utilization percentage
MaxInBuffer Specifies the maximum size, in bytes, of the input buffers

that the test passes to the driver in FSCTLs (or IOCTLs
for IOCTL tests).
MinInBuffer Specifies the minimum size, in bytes, of the input buffers

that the test passes to the driver in FSCTLs (or IOCTLs
for IOCTL tests).
MaxOutBuffer Specifies the maximum size, in bytes, of the output

buffers that the test passes to the driver in FSCTLs (or
IOCTLs for IOCTL tests).
MinOutBuffer Specifies the minimum size, in bytes, of the output

buffers that the test passes to the driver in FSCTLs (or
IOCTLs for IOCTL tests).
MaxRandomCalls Specifies the maximum number of calls that the test

issues.
MaxTailoredCalls Specifies the maximum number of calls that the test

issues during the tailored random test.
MaxDeviceType Specifies the maximum value of the DeviceType field in

the FSCTLs (or IOCTLs for IOCTL tests). The maximum
possible value is 65535.
MinDeviceType Specifies the minimum value of the DeviceType field in

the FSCTLs (or IOCTLs for IOCTL tests). The minimum
MaxFunctionCode Specifies the maximum value of the FunctionCode field

in the FSCTLs (or IOCTLs for IOCTL tests). The maximum
MinFunctionCode Specifies the minimum value of the FunctionCode field in

the FSCTLs (or IOCTLs for IOCTL tests). The minimum
PU Specifies the processor utilization percentage
PingPongPeriod Specifies the ping pong period in minutes; the time the
processor alternates between high (HPU) and low (LPU)
processor utilization levels.
ResumeDelay The delay time (in seconds) after the machine resumes
from sleep mode and before the next I/O cycle starts.
The delay time is necessary to allow devices to restore
their working state (renew IP address for network card
and so on).
TestCycles Specifies the number of test cycles (iterations) to

perform.
WDTFREMOTESYSTEM This parameter is required only if the device under test,

or one of its child devices, is a wired network adapter
that does not have an IPv6 gateway address. If this
parameter is required on your network, you must
provide an IPv6 address that the test network adapter
can ping to test network.
Example: fe80::78b6:810:9c12:46cd
Wpa2PskAesSsid This parameter is required only if the device under test

or one of its child devices is a WiFi adapter. Provide the
SSID of a WPA2 AES WiFi network that the test can use
to test the WiFi adapter.
Default value: kitstestssid
Wpa2PskPassword This parameter is required only if the device under test

or one of its child devices is a WiFi adapter. Provide
password of the WPA2 AES WiFi network that is
specified by using the Wpa2PskAesSsid parameter.
Default value: password
Utility tests
T EST DESC RIP T IO N
Display devices that have WDTF Simple I/O plug-ins Parameters: None
Display devices that have Driver Verifier enabled Parameters: None
Display devices Parameters: None
Driver Verifier
T EST DESC RIP T IO N
Disable Driver Verifier Disables Driver Verifier on the test computer.

Parameters: None
Enable Driver Verifier You can use this test to enable Driver Verifier for all
drivers of a device (or devices) on the test computer.
Parameters: - See Driver Verifier Options.
Related topics
How to How to test a driver at runtime using Visual Studio
Device Fundamentals Tests
Provided WDTF Simple I/O plug-ins
How to customize I/O for your device using the WDTF Simple I/O Action Plug-in
How to test a driver package
You can use Visual Studio to deploy and install a driver package on a test computer, and then verify that the
driver is installed and running.
Prerequisites
A driver package that is ready to install. You must first create and build your driver and then create a driver
package for installation. For more information, see Building a Driver and Creating a Driver Package.
If you have not already done so, follow the instructions to Provision a computer for driver deployment and
testing (WDK 8.1).
After you have configured and provisioned a test computer, you can use Visual Studio to deploy drivers,
schedule tests, and debug drivers on the test computer. For information about deployment and about how
you can deploy a driver automatically at build time, see Deploying a Driver to a Test Computer.
Instructions
Step 1: To test the driver installation on a test computer
After you have configured and provisioned a test computer, you can configure the driver package project so that
it is automatically deployed and installed on the test computer.
1. Open the property pages for your driver project. select and hold (or right-click) the driver project in Solution
Explorer and select Proper ties .
2. In the property pages for the driver, select Configuration Proper ties , select Driver Install , and then select
Deployment .
3. Select the Enable deployment option. For more information, see Deployment Properties for Driver
Projects.
4. Select the test computer you have configured as the Remote Computer .
5. Under Driver Installation Options , select Install and Verify , and then select the Default Driver
Installation Task .
Related topics
Provision a computer for driver deployment and testing (WDK 8.1)
Testing a Driver
How to read the driver test results log
From the Driver Test Group Explorer , you can display the results from driver tests, save the test results to a
folder, or load the results from a folder.
Open the test results
1. In the Driver Test Group Explorer window, select the Driver Test Group you are interested in.
2. Select the results from a specific test run.
The results for the test group are shown as a folder titled Results ( computer - date:time)
3. The results for the tests in that test run are listed. Select the name of the test to view the results log.
The results log provides a summary of the tests that were run, along with the details generated by the test cases.
The information recorded included the time and date that each test was run, the name of the remote test
computer that ran the test, and the test results (number of tests run, passed, failed).
Save the test results to a folder

1. In the Driver Test Group Explorer window, select and hold (or right-click) the results from the test run that
you are interested in.
2. Select Save to open a dialog box to save the results to a folder.
How to test a driver at runtime from a Command
Prompt
The WDK provides device testing components that enable you to test a driver on a test computer on your
network. You can use these components outside of Visual Studio by copying and installing the necessary files.
You can use these components to run the same collection of device driver tests that are available in Visual Studio
to test the features and functions of your driver.
Starting in WDK 8.1, you can copy and run the HCK Test Suites on test computers using command scripts. See
How to run the HCK Test Suites in WDK 8.1.
Prerequisites
Install Visual Studio and the WDK on the computer you use for development.
From Visual Studio, you can configure and provision computers for testing. When you configure the test
computer, the WDK driver test framework automatically enables the test computer for remote debugging
and transfers the necessary test binaries and support files. If you have not already done so, follow the
instructions in Provision a computer for driver deployment and testing (WDK 8.1)
Although it is not recommended, you can also install the necessary test components manually. Follow the
instructions to install the Test Authoring and Execution Framework (TAEF) and WDTF on the test computer.
See Manually installing and uninstalling TAEF on a test computer and WDTF Quick Start.
Instructions
Step 1: Copy the tests to the test computer
Copy the Device Fundamentals Tests from the computer you use for development. Copy the folder
%ProgramFiles%\Windows Kits\8.0\Testing\Tests\Device Fundamentals to the test computer.
Step 2: Run the tests
The TAEF command to run the tests uses the following syntax:
Te.exe [/name:<Test Method>] [<Test Name>.dll | <Test Name.wsc> ] [/rebootStateFile=<file> ]

[/enablewttlogging] [/P:"DQ= <>" ]
Remarks
You must specify the test binary (.dll) or script (.wsc) file. The test method (/name:<test method>) is optional.
For the test names and test methods, see the Device Fundamentals Tests. For information about specifying test
parameters, see Device Fundamentals Test Parameters and Te.exe Command Options .
For example, to run all PnP tests in the Devfund_PnPDTest.dll on a device with a specific device ID.
Te.exe Devfund_PnPDTest.dll /P:"DQ=DeviceID='USB\ROOT_HUB\4&1CD5D022&0'"
For example, to run PnP Surprise Remove test on a device with a specific device ID.
Te.exe /name:"*PNPSurpriseRemoveAndRestartDevice" Devfund_PnPDTest.dll
/P:"DQ=DeviceID='USB\ROOT_HUB\4&1CD5D022&0'"
Related topics
Device Fundamentals Tests
Device Fundamentals Test Parameters
Test Authoring and Execution Framework (TAEF)
Te.exe Command Options
How to write a driver test using a Driver Test
template
NOTE
This topic describes functionality that is only available in Visual Studio 2013. For info on previous WDK and Visual Studio
editions, see Other WDK downloads.
You can use the Windows Driver Kit (WDK) for Windows 8 to create your own driver tests or to customize some
of the tests that are provided. You can deploy the tests that you create to remote test computers using the driver
testing framework that the WDK provides for Microsoft Visual Studio Ultimate 2012.
The WDK provides templates that create starter code for a Windows Driver test project in C++, C#, and Script
(JScript). You can select the test cases that you want to include, or you can start with a blank project. You can
customize the code to add new test cases for your driver. You can deploy your tests from Visual Studio using the
driver test framework.
To customize a driver test using the Driver Test template for C++
1. From the File menu, select New > Project .
2. From the list of installed templates in the New Project dialog box, select Visual C++ > Windows Driver
> Tests .
3. Select Windows Driver Test in C++ .
4. Provide a name for your driver test project and a location (or use the default).
5. From the Windows Driver Test dialog box, select the test cases that you want to include or choose an
empty (blank) driver test. For more information about the test cases, see Windows Driver test cases.
6. Add the required test metadata. For more information, see How to add test metadata.
7. Build your driver test.
To customize a driver test using the Driver Test template for C#

2. From the list of installed templates in the New Project dialog box, select Visual C# > Windows Driver .
3. Select Windows Driver Test in C# .
empty (blank) driver test. For information about the test cases, see Windows Driver test cases.
To customize a driver test using the Driver Test template for Script
2. From the list of installed templates in the New Project dialog box, select Script > Windows Driver .
3. Select Windows Driver Test Script .
empty (blank) driver test. For information about the test cases, see Windows Driver test cases.
Making the driver tests you create available for deployment on test
computers
When you build your driver test, the new test will be available for deployment to a test computer. By default, the
tests that you create will appear in the test category My Test Categor y . The names of the tests are based upon
the test cases that you choose, and they will have names such as My Plug and Play Surprise Remove Test .
During each build of the test, the test will be overwritten. The latest build of the test will be available to deploy
and run on the test computer.
Windows Driver test cases

The WDK provides starter code for a Windows Driver test project in C++, C#, and Script. You can select test
cases that you want to include, or you can start with a blank project. Not all test cases are available in every
language.
T EST C A SES T H AT F O RC E A DRIVER TO H A N DL E M O ST O F

P L UG A N D P L AY T EST C A SES T H E P L UG A N D P L AY ( P N P ) - REL AT ED IRP S
Disable/Enable Provides code for test cases that disable and enable a PnP
device.
Remove Provides code for test cases that remove a PnP device.
Surprise Remove Provides code for test cases that perform a surprise remove
of a PnP device.
Power Management Test Cases Provides test cases that force a driver to handle system sleep
states.
System Sleep States Provides code for test cases that perform device I/O while
the system cycles through sleep and power state.
Stress and Functionality Test Cases Provides test cases that perform I/O stress and function
testing of IOCTL and WMI interfaces.
I/O Stress Provides test cases that perform device I/O stress.
Functional IOCTL Interface Provides a template for creating functional test cases for the
IOCTL interface. (only available for C++ ).
Functional WMI Interface Provides a template for creating functional test cases for the
Windows Management Interface (WMI). (only available in
Script)
Empty Test Case
Provides a blank template for creating a Windows Driver test

project.
Related topics
Test Authoring and Execution Framework
For Windows 8, the Windows Driver Kit (WDK) uses the Test Authoring and Execution Framework (TAEF) for
creating test content. A TAEF test is an object implemented as a dynamic-link library (DLL) that contains multiple
methods, where each method maps to a specific test scenario. The TAEF object combines related methods into a
group of tests. For each test, there is a set of metadata that describes the test. To improve test portability and
encapsulation, TAEF stores test metadata within the test object itself. When you create your own driver tests
using the Driver Test templates, you need to add this metadata so that your driver tests are available and can be
deployed using Visual Studio.
Prerequisites
The source code for a driver test written by using one of the Driver Test templates. For information, see How
to write a driver test using a Driver Test template.
To add test metadata attributes
1. Add the required test property metadata to the source files for your test.
2. For example, if you use the Driver Test template to create your version of the SurpriseRemove test, the
following metadata is added. Edit the test description, display name, category, and results file attributes.
C ++
// Declare the test class method DoSurpriseRemove - the main test method within this class
BEGIN_TEST_METHOD(DoSurpriseRemove)
// Required properties for driver tests
TEST_METHOD_PROPERTY(L"Kits.Drivers", L"TRUE")
TEST_METHOD_PROPERTY(L"Kits.Parameter", L"DQ")
TEST_METHOD_PROPERTY(L"Kits.Parameter.DQ.Description", L"A WDTF SDEL query that is used to
identify the target device(s) - https://go.microsoft.com/fwlink/p/?linkid=232678")
TEST_METHOD_PROPERTY(L"Kits.Parameter.DQ.Default",
L"INF::OriginalInfFileName='%InfFileName%'")
TEST_METHOD_PROPERTY(L"RebootPossible", L"true")
// TODO: Required properties to be customized to match your test requirements
TEST_METHOD_PROPERTY(L"Description", L"Plug and Play Surprise Remove Generated Template")
TEST_METHOD_PROPERTY(L"Kits.DisplayName", L"My Plug and Play Surprise Remove Test")
TEST_METHOD_PROPERTY(L"Kits.Category", L"My Test Category")
// Optional properties for driver tests
TEST_METHOD_PROPERTY(L"Kits.Drivers.ResultFile", L"TestTextLog.log")
// TODO: (see Windows Driver Kit documentation for additional optional properties)
END_TEST_METHOD()
C#
//
// DoSurpriseRemove is a test method as identified by the [TestMethod] tag.
// More methods can be added by following this basic pattern.
// The name of the function defines the name of the test.
//
[TestMethod]
// Required properties (see Windows Driver Kit documentation for more information):
[TestProperty("Kits.Drivers", "TRUE")]
[TestProperty("Kits.Parameter", "DQ")]
[TestProperty("Kits.Parameter.DQ.Description", "A WDTF SDEL query that is used to identify
the target device(s) - https://go.microsoft.com/fwlink/p/?linkid=232678")]
[TestProperty("Kits.Parameter.DQ.Default", "INF::OriginalInfFileName='%InfFileName%'")]
// TODO: Required properties to be customized to match your test requirements.
[TestProperty("Description", "Plug and Play Surprise Remove Generated Template")]
[TestProperty("Kits.DisplayName", "My Plug and Play Surprise Remove Test")]
[TestProperty("Kits.Category", "My Test Category")]
[TestProperty("RebootPossible", "true")]
// Optional properties (see Windows Driver Kit documentation for additional optional
properties):
[TestProperty("Kits.Drivers.ResultFile", "TestTextLog.log")]
Windows Script Component (.wsc)


<method name="PlugAndPlaySurpriseRemoveTest">

<TestMethodProperty name="Kits.Drivers" value="TRUE"/>
<TestMethodProperty name="Kits.Parameter" value="DQ"/>
<TestMethodProperty name="Kits.Parameter.DQ.Description" value="A WDTF SDEL query that is
used to identify the target device(s) - https://go.microsoft.com/fwlink/p/?linkid=232678"/>
<TestMethodProperty name="Kits.Parameter.DQ.Default"
value="INF::OriginalInfFileName='%InfFileName%'"/>
<TestMethodProperty name="RebootPossible" value="true" />

<TestMethodProperty name="Description" value="Plug and Play Surprise Remove Generated
Template"/>
<TestMethodProperty name="Kits.DisplayName" value="My Plug and Play Surprise Remove Test"/>
<TestMethodProperty name="Kits.Category" value="My Test Category"/>

<TestMethodProperty name="Kits.Drivers.ResultFile" value="TestTextLog.log"/>

</method>
3. The following table describes the test property attributes. Use the examples for guidance as you edit or
add the metadata for your tests.
Description
A short description of what the test does.
[Script]
< TestProperty name="Description" value= "This test cycles the system through various sleep
states and performs IO on devices before and after each sleep state cycle"/>
C ++
[C++]
TEST_METHOD_PROPERTY(L"Description", L"Plug and Play Surprise Remove Generated Template")
DisplayName
The name of the test as it shown in Driver Test.
[Script]
< TestProperty name="Kits.DisplayName" value="Sleep with IO Before and After"/>
C ++
[C++]
TEST_METHOD_PROPERTY(L"Kits.DisplayName", L"My Plug and Play Surprise Remove Test")
Kits.Parameter
A standard parameter for a method call. A test can have multiple parameters.
[Script]
<ModuleProperty name="Kits.Parameter" value="TM"/>
C ++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Parameter", L"DQ")
Kits.Parameter.<ParameterName>.Description
The description for the parameter.
[Script]
< TestProperty name="Kits.Parameter.TM.Description" value="Test mode parameter: Logo or

Simple"/>
C ++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Parameter.DQ.Description", L"A WDTF SDEL query that is used to
identify the target device(s)")
Kits.Parameter.<ParameterName>.Default
The default value for the parameter.
[Script]
< TestProperty name="Kits.Parameter.TM.Default" value="Logo"/>
C ++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Parameter.DQ.Default",
L"INF::OriginalInfFileName='%InfFileName%'")
Kits.Drivers
This attribute marks the test for inclusion in the WDK.
[Script]
< TestProperty name="Kits.Drivers" value=""/>
C ++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Drivers", L"TRUE")
Kits.Categor y
Describes the category of a test.
[Script]
< TestProperty name="Kits.Category" value="Logo\Device Fundamentals"/>
C ++
[C++]
TEST_METHOD_PROPERTY(L"Kits.Category", L"My Test Category")
Deploymentitem
Identifies files and/or folders as test dependencies. These may contain any resources needed to run the
tests. For more information about using this metadata, see DeploymentItem Metadata.
Related topics
How to write a driver test using a Driver Test template
Static Driver Verifier Known Issues - Windows 10
Version 1809
This page describes common issues you may encounter when using the Static Driver Verifier (SDV) tool in the
Windows Driver Kit (WDK). The information below pertains specifically to the version of the tool that ships with
Windows 10 October 2018 Update (Version 1809).
Please see WDK Known Issues for known SDV issues with the latest official WDK.
InterceptedBuild failures
Primary symptom: SDV fails with FATAL ERROR: Unrecoverable error in InterceptedBuild stage .
When examining the DVL file, you will see an AssessmentScore value with
ScoreName="[driverName].[architecture].SDV.NA.Reason" and
ScoreUnit="Unrecoverable error in InterceptedBuild stage."
For InterceptedBuild failures, perform the following steps to diagnose the issue.
1. Rerun SDV from the Visual Studio 2017 Native Tools Command Line with the /debug flag. For details on
command options, see Static Driver Verifier commands.
a. First, run SDV's library function on any dependent library projects. For example:
msbuild /p:Configuration=Release /p:Platform=x64 /t:sdv /p:inputs="/lib /debug" .
b. Then run SDV on the driver project itself. For example:
msbuild /p:Configuration=Release /p:Platform=x64 /t:sdv /p:inputs="/check /debug"
2. Confirm that the failure again occurs in the InterceptedBuild stage.

3. Navigate to the sdv folder that is generated in the driver folder when you run SDV.
4. Open smvcl.log and search for the phrase "internal compiler error".
a. If an error message containing internal compiler error and a phrase similar to fatal error C1001:
An internal error has occurred in the compiler. (compiler file 'msc1.cpp', line 1511) is present,
this is a known issue which requires errata (errata ID 40705). If you need further assistance, please email
stlogohelp@microsoft.com.
b. If an error message containing internal compiler error is present but does not look like the above,
this will likely require an errata but may not be an existing known issue. Email
stlogohelp@microsoft.com.
c. If you do not see any lines containing internal compiler error , search for any lines beginning with
error . These may or may not be issues requiring errata. Email stlogohelp@microsoft.com.
5. Open smvlink1.log and search for the phrase internal compiler error .
a. If an error message containing internal compiler error and slamcl: error : at phase 2: out of
memor y is present, this is a known issue which requires errata.
b. If you do not see any lines containing internal compiler error , search for any lines beginning with
error . These may or may not be issues requiring errata. Email stlogohelp@microsoft.com.
c. If you do not see any of the above, reach out to MSFT for support.
To reach out to MSFT for support, please ensure source code is not shared by running the following:
1. Run SDV with the /debug flag enabled, and pipe the output to a text file.
2. Navigate to the sdv folder in the driver directory and run the following commands to clear build results
that might expose sources:
del /s *.obj
del /s *.rawcfg*
del /s *.li
del /s *.pdb
del /s *.sys
3. Send the following files to stlogohelp@microsoft.com:

a. The text file with the output of running SDV
b. The smexecute-NormalBuild.log file
c. The smvexecute-InterceptedBuild.log file
d. The "sdv" subfolder
Visual Studio C++ 2013 runtimes not present

Primary symptom: When running SDV on a system that does not have the Visual Studio C++ 2012 and 2013
runtimes, the user may see errors in pop-up boxes such as The code execution cannot proceed because
[MSVCR110.dll or VCOMP110.dll] was not found. Reinstalling the program may fix this problem.
In this case, the solution is to install both the x86 and x64 Visual C++ Redistributable for Visual Studio 2012 and
2013.
Best practice: use Visual Studio 2017 Version 15.8

By default, code analysis does not automatically build the driver in Visual Studio 15.7. If the driver depends on
binaries being generated, this can lead to a failure in the Output pane. Instead, we recommend using version
15.8 instead.
DVL generation failure after removing configuration from a project

Primary symptom: After removing a configuration from a project via the Configuration Manager window, the
user sees the following message when selecting Create Driver Verification Log :
Please select a driver project. Driver Verification Log cannot be created for the selected platform tool set:
'v100'"
Workaround:
1. Back up your project file, and then open the project file in a text editor.
2. Under the section, find two XML tags: one with the format
\<PropertyGroup Label="Globals"\>
\<Configuration\>\[Configuration type\]\</Configuration\> and one with the format
\<Platform Condition="'$(Platform)' == ''"\>\[Architecture\]\</Platform\> , where
\[Configuration type\] and \[Architecture\] are the default configuration and release for this type of
project.
3. Update \[Configuration type\] and \[Architecture\] to values appropriate for your project. For
example, if you removed the Win32 platform, you might update \[Architecture\] to x64 instead.
Alternative workaround:
1. Open a Visual Studio 2017 Native Tools Command Prompt.
2. Navigate to the driver folder.
3. Run msbuild [Your Project] /p:Configuration=[Configuration type] /p:Platform=[Architecture] /t:dvl ,
where \[Your Project\] is the vcxproj file, \[Configuration type\] is a valid configuration such as
Release, and \[Architecture\] is a valid architecture such as x64.
DVL generation does not work on ServerCore, use Server GUI

The Static Tools Logo test fails when run. Reviewing the test logs shows a failure similar to
Failed to load 'C:\hlk\JobsWorkingDir\Tasks\WTTJobRun4749E809-0166-E811-8368-
F4521454FFE1\Devfund_DvlTest.dll'. (Could not load managed test module because RoMetadata.dll could not be
found)
Make sure the TAEF package is deployed or RoMetadata.dll is deployed to a location in your PATH environment
variable.
The key symptom is the failure to load RoMetadata.dll.
If you have a Server GUI installation with the same architecture and Windows version as your ServerCore
installation, copy the RoMetadata.dll file from Server GUI to ServerCore. The DLL can be found in the System32
folder (for example, C:\Windows\System32 ) and should be placed in the same folder on the ServerCore machine.
This should enable the test to run on ServerCore. If you are still experiencing issues, please refer to the next
workaround.
The second workaround is to run on Server GUI and then merge the package with the package containing the
results from Server Core. For info on merging packages, see Merge packages.
Static Driver Verifier fails with exiting lib.exe/iwrap.exe with

0xc0000142 error
The smvbuild.log file contains a message similar to this error:
c:\Program Files\Microsoft Visual

Studio\2017\BuildTools\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(1144,5): error MSB6006:
"Lib.exe" exited with code -1073741502.
Done executing task "LIB" -- FAILED.
This is a known issue. If this issue is blocking your WHCP certification, please use errata 41600.
Creating a Driver Verification Log
Certain programs of the Windows Hardware Certification Program require a Driver Verification Log (DVL) for all
driver submissions. The DVL contains a summary of the results from the Code Analysis (CA), Static Driver
Verifier (SDV), and CodeQL log files. The DVL does not contain any source information. You must run the Code
Analysis tool and Static Driver Verifier prior to creating a DVL for your driver.
To create a driver verification log
1. Before running the Code Analysis tools, be sure that you can build and link your driver using the latest
Windows Driver Kit (WDK).
2. For the Driver Solution, make sure that you have selected a Release configuration as the Solution
Configuration and x64 as the Solution Platform.
3. Run Static Driver Verifier. For information about creating the log file, see Creating a log file for Static Driver
Verifier and Using Static Driver Verifier to find defects in drivers.
4. Run the Code Analysis tool for drivers. Address and fix any defects that are found. See Creating a log file for
the code analysis tool and How to run Code Analysis for Drivers. For more information about code analysis,
see Analyzing C/C++ Code Quality by Using Code Analysis.
5. Run CodeQL. Address and fix defects that are found. Certification will fail if defects that are deemed "Must-
Fix" are not corrected. For more information about CodeQL and the Static Tools Logo Test, see CodeQL and
the Static Tools Logo Test.
6. Create the Driver Verification Log. From the Driver menu, select Create Driver Verification Log....
7. Verify that the Code Analysis Log, Static Driver Verifier Log, and CodeQL Log files are detected. Select Create .
The driver verification log has the file name extension .DVL.XML. The log is created in the project folder, for
example, \myDriverProject\myDriverName.DVL.XML.
Note SDV performs a clean rebuild of the driver, which removes the Code Analysis log. As such, please be sure
to run SDV before running CA.
Note When you are ready to test your driver using the Windows Hardware Lab Kit, you need to copy the driver
verification log to the %systemdrive%\DVL directory on the test computer. Be sure to delete the contents of the
directory on the test computer before you copy the new driver verification log.
Remarks
For the most up-to-date information about the Code Analysis tool, Static Driver Verifier, and the Driver
Verification Log, refer to the WDK Release Notes. The Release Notes are available on the Windows Driver Kit
(WDK) download page.
Impor tant Timeouts, spaceouts, and other non-successful results in the DVL file are acceptable for
certification submission. This will not cause the Static Tools test in HLK to fail.
You can also create the driver verification log from a Visual Studio Command Prompt window, either by the
Visual Studio Native Tools Command Prompt installed with Visual Studio or via the Enterprise Windows Driver
Kit (EWDK):
msbuild.exe <vcxprojectfile> /target:dvl /p:Configuration="Release" /P:Platform=x64

Creating a Driver Verification Log Outside of msbuild or Visual Studio
Microsoft ships as part of the Windows Driver Kit (WDK) and Enterprise WDK (eWDK) a component called
dvl.exe which can be used to generate Driver Verification Logs (DVLs) via command-line. Starting in WDK/eWDK
preview versions 21342 and above, it is possible to generate a DVL from the command line outside of the
context of msbuild or Visual Studio. Follow the steps below to create the DVL via command-line:
1. Place the results that need to be consumed to create the DVL in a single directory. Typically for drivers
intended to be certified for Windows Client, this is the CodeQL SARIF file. For Windows Server certification,
this may also include the Code Analysis and Static Driver Verifier (SDV) results files. Check the WHCP
requirements documents for specific details on which tools are required to be run for device driver
certification.
2. CodeQL SARIF files and Code Analysis XML files should be placed in the top level of the directory. The SDV
DVL.xml file should be placed in a “sdv” subfolder.
3. From the command line, navigate to the top-level directory which contains the CodeQL SARIF file.
4. Locate dvl.exe from the WDK or a mounted eWDK.
5. Call dvl.exe by passing the /manualCreate flag, a driver name, and a desired architecture. For example:
"C:\Program Files (x86)\Windows Kits\10\Tools\dvl\dvl.exe" /manualCreate driverName driverArchitecture
One of the following strings should be used for your driverArchitecture string:
X86
X64
ARM
ARM64
Do not include ".sys" as par t of your driverName string
6. Inspect the generated DVL to ensure that it was generated correctly
This usage is primarily intended for generating DVLs with CodeQL results, but can also be used for SDV and CA
results.
Related topics
Analyzing Driver Quality by Using Code Analysis Tools
Using Static Driver Verifier to find defects in drivers
CodeQL and the Static Tools Logo Test
The Windows Server 2012 Hardware Certification Program requires a Driver Verification Log (DVL) for all
applicable driver submissions. You must run the Code Analysis tool prior to creating a DVL for your driver. The
DVL contains a summary of the results from the Code Analysis and Static Driver Verifier log files. The log files do
not contain source code information.
To run code analysis on the driver
1. In Microsoft Visual Studio Ultimate 2012, select the driver project file and then select and hold (or right-click)
to open the project properties. Select Windows 8 Release as the Configuration and x64 as the Platform .
2. From the Analyze or Build menu, select Run Code Analysis on Solution .
3. If errors or warnings are found, use the Code Analysis Repor t window to investigate the cause of the
errors. Use the warning messages to fix those problems. For more information about the Code Analysis tool,
see How to run Code Analysis for drivers and Analyzing C/C++ Code Quality by Using Code Analysis.
The Code Analysis tool for drivers writes the results to the file vc.nativecodeanalysis.all.xml in the build
configuration and platform sub-directory of your project, for example, \Windows 8Release\x64.
Remarks
Code Analysis for Drivers is a compile-time static verification tool that detects basic coding errors in C and C++
programs and includes a specialized module that is designed to detect errors in (primarily) kernel-mode driver
code. In previous versions of the WDK, the driver-specific module for code analysis was part of a stand-alone
tool called PREfast for Drivers (PFD).
You can also run the Code Analysis tool from a Visual Studio Command Prompt window. Set up the
environment by running one of the following batch files.
"C:\Program Files\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x64
-Or-
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x64
Run the Code Analysis tool.
msbuild.exe <vcxprojectfile> /p:Configuration="Win8 Release" /P:Platform=x64 /target:clean

msbuild.exe <vcxprojectfile> /p:Configuration="Win8 Release" /P:Platform=x64 /P:RunCodeAnalysisOnce=True
For the most up-to-date information about the requirements for the Driver Verification Log, refer to the WDK
Release Notes.
Related topics
Creating a driver verification log
Code Analysis for Drivers
Analyzing C/C++ Code Quality by Using Code Analysis
The Windows Server 2012 Hardware Certification Program requires a Driver Verification Log (DVL) for all
applicable driver submissions. You must run Static Driver Verifier (SDV) prior to creating a DVL for your driver.
The DVL contains a summary of the results from the Code Analysis and Static Driver Verifier log files. The log
files do not contain source code information.
For best results, run the Code Analysis tool before you run Static Driver Verifier.
Create the log file

1. In Microsoft Visual Studio Ultimate 2012, select the driver project file and then select and hold (or right-click)
to open the project properties. Select Windows 8 Release as the Configuration and x64 as the Platform .
2. If you have already run the Code Analysis tool, follow these instructions for running Static Driver Verifier. For
more information about using SDV, see Using Static Driver Verifier to Find Defects in Drivers
3. If SDV finds defects in your driver, select the defect in the Results pane to view a trace of the code path that
led to the rule violation. Fix any defects found in the driver and run SDV again.
Static Driver Verifier writes the results to the file SDV.DVL.xml in the SDV sub-directory of your project, for
example, \myDriverProject\SDV.
Remarks
For the most up-to-date information about Static Driver Verifier and the Driver Verification Log, refer to the
WDK Release Notes. The Release Notes are available on the Windows Driver Kit (WDK) download page.
IMPORTANT
Timeouts, spaceouts, and other non-successful results in the DVL file are acceptable for certification submission. This will
not cause the Static Tools test in HCK to fail. For HCK 2.0, the Static Tools Test only requires the presence of DVL file to
show Code Analysis and SDV had been run, and does not require all rules to pass.
You can also run Static Driver Verifier from a Visual Studio Command Prompt window. Set up the environment
by running one of the following batch files.
"C:\Program Files\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x64
-Or-
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x64
Run Static Driver Verifier.
msbuild.exe <vcxprojectfile> /p:Configuration="Win8 Release" /p:Platform=x64 /target:sdv /p:inputs="/clean"

msbuild.exe <vcxprojectfile> /p:Configuration="Win8 Release" /p:Platform=x64 /target:sdv
/p:inputs="/check:default.sdv"
Related topics
Creating a driver verification log
Static Driver Verifier
Using Static Driver Verifier to Find Defects in Drivers
Distributing a driver package
This topic describes how to securely distribute your driver package. This information includes how to distribute
a driver package through the Microsoft Windows Update program. This topic also describes how Windows
protects system files.
Windows Update
Driver packages that pass Windows Hardware Certification Kit (HCK) testing can be digitally-signed by
WHQL. If your driver package is digitally-signed by WHQL, it can be distributed through the Windows
Update program or other Microsoft-supported distribution mechanisms.
Obtaining a WHQL release signature is part of the Windows Hardware Certification Kit (HCK). A WHQL release
signature consists of a digitally-signed catalog file. The digital signature does not change the driver binary files
or the INF file that you submit for testing.
You can distribute a driver package through the Windows Update program if the driver package:
Passes the WHQL test program and receives a WHQL release signature.
Qualifies for the Windows Certification Program.
Meets additional requirements that ensure that Windows Update can determine the correct driver
package for the user's device, can legally distribute it, and can automatically download it.
Because the requirements of the Windows Update program are frequently updated, you should regularly check
the Windows Update driver publishing Web site.
Protection for System Files

Windows File Protection (WFP) protects Windows operating system files from being replaced with unknown or
incompatible versions.
WFP prevents programs from replacing critical Windows system files. Programs must not overwrite these files
because they are used by the operating system and by other programs. Protecting these files prevents problems
with programs and the operating system.
The types of system files that WFP protects include .sys, .exe, .ocx, and .dll files that ship "in the box" with the
operating system.
During WHQL testing, the Signability program checks a driver's INF file to ensure that it does not attempt to
replace system files. A driver package that attempts to replace system files cannot receive a digital signature. A
driver package can, however, contain updated versions of files that the vendor supplied to Microsoft to ship with
Windows 2000 or later versions of the operating system.
For additional information about Windows File Protection, see the Windows SDK documentation.

Microsoft Windows Driver Development and Inf File Constructiont

Uploaded by

Copyright:

Available Formats

You might also like

Microsoft Windows Driver Development and Inf File Constructiont

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microsoft Windows Driver Development and Inf File Constructiont

Uploaded by

Copyright:

Available Formats

Contents

Windows Drivers Requirements

Windows Drivers vs. Windows Desktop Drivers

F EAT URE W IN DO W S DRIVERS W IN DO W S DESK TO P DRIVERS

Run on Windows 10 Desktop Yes Yes

Run on Windows 10X Yes No

Must be certified with WHCP Yes No

WDK & HLK are primary vehicles for Yes Yes

Adhere to stricter reliability and Yes No

DCH Design Principles

N O N - ISO L AT ED DRIVER ISO L AT ED DRIVER

Run From Driver Store

Using Device Interfaces

Reading and Writing State

Device Interface Registry State

DriverData and ProgramData

Validating API Layering

Converting an existing driver project to a Windows driver project

Creating a New Windows Driver Project in Microsoft Visual Studio

Creating a New Universal Application or DLL Project in Microsoft

infverif /k <INF file>

Driver Verifier Driver Isolation Checks

verifier /rc 33 36 /driver myDriver1.sys myDriver2.sys

To configure DV to bugcheck when a violation occurs, use the following syntax:

verifier /onecheck /rc 33 36 /driver myDriver1.sys

Here are a few examples of error messages:

Fixing validation errors

ApiValidation: Error: FlexLinkTest.exe has a dependency on 'wtsapi32.dll!WTSEnumerateSessionsW' but is

Running ApiValidator from the Command Prompt

apivalidator.exe -DriverPackagePath:"C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2\_fx2\Debug" -

The command produces the following output:

ApiValidator.exe Driver located at C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\Debug is NOT a

Use this workaround:

2. Rebuild the solution.

Use declarative sections/directives and properly isolate INF

Use extension INFs to componentize a driver package

In [ osrfx2_DCHU_base.inx ], Fabrikam specifies the following entries:

Install a service from an INF file

Allow communication with a hardware support app

Tightly coupling multiple INF files

Run from the driver store

Inflight Trace Recorder

TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DRIVER, "%!FUNC! Entry");

Case 1: The documentation for your technology recommends UMDF.

Case 2: The documentation for your technology recommends KMDF.

Case 4: The documentation for your technology recommends WDM.

Case 5: The documentation for your technology does not have a

The need for device filter driver ordering

Implementing device filter driver ordering

Default filter level

FilterLevel OR FilterPosition may be specified in one of two ways:

This can be done in both Base and Extension INF's.

This can only be done by a base driver.

Legacy-equivalent filter registration

Case 1: You want to use KMDF

Case 2: You want to use the legacy NT model

3. Fill in the Name and Location boxes, and select OK .

Case 3: You want to use WDM

int __cdecl wmain(int /* argc /, PCWSTR / argv */ [])

int __cdecl wmain(int /* argc /, PCWSTR / argv */ [])