Contents

Developing Drivers
Universal Drivers
Getting Started with Universal Drivers
Driver Package Isolation
Building a Universal Windows driver
Validating Universal Drivers
Building for OneCore
Universal Driver Scenarios
Debugging a Universal driver
Target platform on driver reference pages
Driver convergence model for Windows 10
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 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
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
Attestation Signing a Kernel Driver for Public Release
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
Troubleshooting the Device Fundamentals tests using the WDK
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
 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 here. Debugging Tools for Windows is included when you
install the WDK.
The WDK uses [Link], 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:
What's New in HID
Capture and view USB traces with Microsoft Message Analyzer
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
 minutes to read • Edit Online

Universal Windows drivers enable developers to create a single driver package that runs across multiple device
types, from embedded systems to tablets to desktop PCs.
A Universal Windows driver package contains 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.
The driver binary can use KMDF, UMDF 2, or the Windows Driver Model (WDM).
A universal driver consists 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.
An IHV follows the design best practices of driver package isolation to ensure the driver is reliable and robust to
servicing operations.
After the IHV has certified the base driver, it can be deployed on all OEM systems. Because a base driver can be
used across all systems that share a hardware part, Microsoft can test the base driver broadly by using Windows
Insider driver flighting instead of limiting distribution to specific machines.
After 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.
Universal drivers are distributed through Windows Update, and hardware support apps are distributed through
Microsoft Store.

Design principles
When you write a universal driver package, there are four design principles to consider:
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 universal 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.
Universal API compliance (U) : Binaries in the universal driver package call only those APIs and DDIs that are
included in UWP-based editions of Windows 10. These DDIs are marked as Universal on the
corresponding documentation reference pages. INF files use only universal INF syntax.
Additionally, Universal drivers also benefit from the principles of driver package isolation. You'll find detailed
guidance on how to follow these best practices in the Driver Package Isolation page.
In the documentation, we use the DCHU acronym to refer to these principles. Later in this article, you'll find
guidance to make your driver package DCHU-compliant. Also check out Universal driver scenarios, which
describes how the DCHU universal driver sample applies the DCHU design principles.

Requirements
When you write a universal driver package, follow these steps:
Create a universal INF file for your driver:
1. Review the list of INF sections and directives that are valid in universal driver packages.
2. Use the InfVerif tool to verify that your driver package's INF file is universal.
Use the ApiValidator tool to verify that the APIs your binaries call are valid for a universal driver package.

Best practices
If you're using the Windows Driver Kit (WDK) with Visual Studio, set the Target Platform value in the driver
project properties to Universal . This automatically adds the correct libraries, and it runs the Universal 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 Universal .
Driver Package Isolation:
To maximize reliability and serviceability of your Universal driver, ensure your driver follows the
principles of driver package isolation
Driver package isolation is a new concept that allows your driver to be self-contained and robust to OS
changes
See more details on the Driver Package Isolation page
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.
Submit your universal driver package for certification in the Windows Hardware Compatibility Program.
See the following topics for more details:
Create a new hardware submission
Managing hardware submissions in the Windows Hardware Dev Center dashboard
Get drivers signed by Microsoft for multiple Windows versions
Driver flighting
 minutes to read • Edit Online

Driver package isolation describes a set of best practices that make drivers more resilient to external changes,
easier to update, and more straightforward to install.
The following table shows legacy driver practices that are no longer recommended in the left column along with
the recommended best practice 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 and needs to access other files from its driver
package could use IoQuer yFullDriverPath to find its path, get the directory path it was loaded from, and look for
configuration files relative to that path.
Alternatively, on Windows 10, version 1803 and later, call IoGetDriverDirector y with DriverDirectoryImage as
the directory type to get the directory path that the driver was loaded from.
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.
For more information about finding and loading files from the driver store, see Universal Driver Scenarios.

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 [Link] section, as shown below:
 [[Link]]
AddReg = Example_DDInstall.AddReg

[Example_DDInstall.AddReg]
HKR,,ExampleValue,,%13%\[Link]

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:

[[Link]]
Addservice = ExampleService, 0x2, Example_Service_Inst

[Example_Service_Inst]
DisplayName = %[Link]%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %13%\[Link]
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)
WdfDriverOpenParametersRegistr yKey (WDF)
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)
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)
IoGetDriverDirector y (KMDF)
WdfDriverRetrieveDriverDataDirector yString (UMDF)
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.
DriverData
The DriverData directory is available in Windows 10, version 1803 and later. This directory is accessible by both
user-mode and kernel-mode components through different mechanisms.
kernel-mode drivers should access the DriverData directory by using a system-supplied symbolic link called
\DriverData . user-mode programs should 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.
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 .
 minutes to read • Edit Online

You can use Microsoft Visual Studio 2015 in conjunction with Windows Driver Kit (WDK) 10 to build drivers for
desktop, mobile, or universal. 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 Universal Windows driver, as long as the driver
does not work with any user-mode components. Legacy WDM and KMDF drivers should recompile as Universal
Windows drivers targeting Windows 10 with no conversion required.
In contrast, existing user-mode drivers may require modification to compile as Universal 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 Universal Windows driver

project
1. In Visual Studio 2015, open the existing driver project.
2. In the Solution Explorer pane, right-click the solution and choose Configuration Manager . Set the target
operating system to Windows 10.
3. Right-click the driver project and choose Proper ties . Under Configuration Proper ties->Driver , verify that
Target Platform is set to Universal . Other choices include Desktop , to build a driver that runs on
Windows 10 for desktop editions only, and Mobile , to build a driver that runs on Windows 10 Mobile only.
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 Universal Windows driver Project in Microsoft Visual

Studio
1. Create a new driver from a template (File>New Project->Templates->Visual C++->Windows
Drivers->WDF ) and choose either User Mode Driver (UMDF V2) or Kernel Mode Driver (KMDF) .
2. After you create the project, in the Solution Explorer pane, 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, right-click the driver project and choose Properties. Under Configuration
Proper ties->Driver Settings->General , find the Target Platform entry. Choose Universal , Desktop ,
or Mobile . Microsoft Visual Studio uses this setting to determine what libraries to link against.
Note You cannot build a Universal Windows driver for Windows versions earlier than Windows 10.
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->Templates->Visual C++->Windows Drivers )
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, 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, 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.
 minutes to read • Edit Online

You can use the [Link] tool to verify that the APIs that your binaries call are valid for a Universal
Windows driver. The tool returns an error if your binaries call an API that is outside the set of valid APIs for
Universal Windows drivers. This tool is part of the Windows Driver Kit (WDK) for Windows 10.

Running ApiValidator in Visual Studio

If the Target Platform property of your driver project is set to Universal , 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 [Link] is not supported. [Link] calls this API.
C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Warning 2 warning : API DisableThreadLibraryCalls in [Link] is not supported. [Link] calls
this API. C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Warning 3 warning : API EncodePointer in [Link] is not supported. [Link] calls this API.
C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Warning 4 warning : API GetCurrentProcessId in [Link] is not supported. [Link] calls this
API. C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Warning 5 warning : API GetCurrentThreadId in [Link] is not supported. [Link] calls this API.
C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Warning 6 warning : API GetSystemTimeAsFileTime in [Link] is not supported. [Link] calls this
API. C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Warning 7 warning : API IsDebuggerPresent in [Link] is not supported. [Link] calls this API.
C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Warning 8 warning : API IsProcessorFeaturePresent in [Link] is not supported. [Link] calls
this API. C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Warning 9 warning : API QueryPerformanceCounter in [Link] is not supported. [Link] calls this
API. C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\driver\[Link] osrusbfx2um
Error 10 error MSB3721: The command ""C:\Program Files (x86)\Windows Kits\10\bin\x64\[Link]" -
DriverPackagePath:"C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\Debug\\" -
SupportedApiXmlFiles:"C:\Program Files (x86)\Windows Kits\10\build\universalDDIs\x86\[Link]" -
ApiExtractorExePath:"C:\Program Files (x86)\Windows Kits\10\bin\x64"" exited with code -1. C:\Program Files
(x86)\Windows Kits\10\build\[Link] 1531 5 osrusbfx2um

Fixing validation errors

1. If you switched a legacy desktop UMDF driver project to universal, verify that you are including the correct
libraries when building your binaries. Right click the project and choose properties. Navigate to Linker-
>Input . The Additional Dependencies should contain:

%AdditionalDependencies);$(SDK_LIB_PATH)\[Link]

To review other linker options for targeting OneCore SKUs, see Building for OneCore.
2. Remove or replace the non-universal API calls 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. If you cannot find a suitable replacement, please submit feedback. You may have to code
a workaround if there is not a suitable replacement. If you need to, write a new Universal 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: [Link] has a dependency on '[Link]!WTSEnumerateSessionsW' but is

missing: IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0")
ApiValidation: Error: [Link] has a dependency on '[Link]!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 [Link] from the command prompt. In your WDK installation, navigate to C:\Program
Files (x86)\Windows Kits\10\bin\<arch>.
Use the following syntax:
[Link] -DriverPackagePath:<driver folder path>
-Suppor tedApiXmlFiles:<path to XML files containing supported APIs for universal 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:
[Link] -DriverPackagePath:"C:\Program Files (x86)\Windows
Kits\10\src\usb\umdf2_fx2\Debug\\" -Suppor tedApiXmlFiles:"c:\Program Files (x86)\Windows
Kits\10\build\universalDDIs\x64\[Link]"
The command produces the following output:

[Link]: Warning: API DecodePointer in [Link] is not supported. [Link] calls this API.
[Link]: Warning: API DisableThreadLibraryCalls in [Link] is not supported. [Link]
calls this API.
[Link]: Warning: API EncodePointer in [Link] is not supported. [Link] calls this API.
[Link]: Warning: API GetCurrentProcessId in [Link] is not supported. [Link] calls
this API.
[Link]: Warning: API GetCurrentThreadId in [Link] is not supported. [Link] calls this
API.
[Link]: Warning: API GetSystemTimeAsFileTime in [Link] is not supported. [Link] calls
this API.
[Link]: Warning: API IsDebuggerPresent in [Link] is not supported. [Link] calls this
API.
[Link]: Warning: API IsProcessorFeaturePresent in [Link] is not supported. [Link]
calls this API.
[Link]: Warning: API QueryPerformanceCounter in [Link] is not supported. [Link] calls
this API.

[Link] Driver located at C:\Program Files (x86)\Windows Kits\10\src\usb\umdf2_fx2\Debug is NOT a

Universal Driver

The XML files that enumerate the valid APIs for Universal Windows drivers are located in C:\Program Files
(x86)\Windows Kits\10\build\universalDDIs\<arch>.

Troubleshooting
If [Link] 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\[Link]
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 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.
 minutes to read • Edit Online

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 [Link] 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 [Link] . The following table
shows the scenarios applicable to each library:

L IB RA RY SC EN A RIO

[Link] All editions of Windows 7 and later, no UWP support

[Link] 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 U requirement of DCHU, 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 U part of DCHU with the following ApiValidator errors:

ApiValidation: Error: [Link] has a dependency on '[Link]!WTSEnumerateSessionsW' but is

missing: IsApiSetImplemented("ext-ms-win-session-wtsapi32-l1-1-0")
ApiValidation: Error: [Link] has a dependency on '[Link]!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 U part of DCHU 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
Validating Universal Windows drivers
OneCore
 minutes to read • Edit Online

This topic describes how the DCHU universal driver sample applies the DCHU design principles (Declarative,
Componentized, Hardware Support Apps [HSA], and Universal API compliance). You can use it as a model for your
own universal driver package.
If you would like a local copy of the sample repo, clone from Windows-driver-samples.
This sample is intended to be used with Windows 10 Version 1703 and later.

Prerequisites
Before you read this section, check out the requirements and best practices for universal driver packages described
in Getting Started with Universal Windows drivers.

Overview
The DCHU 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 Universal Windows Driver 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 non-universal 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 decides to
refactor the code and create a universal driver package instead.

Use only declarative sections and directives

First, Fabrikam reviews the list of INF sections and directives that are invalid in universal driver packages. During
this exercise, Fabrikam notices that they're using many of these sections and directives in their driver package.
Their non-universal 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-universal sections and directives and uses the InfVerif tool to verify that the new driver
package's INF file is universal.

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:

[OsrUsbFx2_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 :

[OsrUsbFx2Extension_AddReg]
HKR, OSR, "OperatingParams",, "-Extended"
HKR, OSR, "OperatingExceptions",, "x86"

Note that extensions are always processed after the base INF 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_UserSvcCopyFiles

[OsrFx2_Install.[Link]]
AddService = osrfx2_DCHU_usersvc, 0x00000800, UserSvc_ServiceInstall

[UserSvc_ServiceInstall]
DisplayName = %UserSvcDisplayName%
ServiceType = 0x00000010
StartType = 3
ErrorControl = 1
ServiceBinary = %13%\osrfx2_DCHU_usersvc.exe

[OsrFx2_UserSvcCopyFiles]
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.[Link]]
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.[Link]]
AddSoftware = osrfx2_DCHU_componentsoftware,, OsrFx2Component_SoftwareInstall

[OsrFx2Component_SoftwareInstall]
SoftwareType = 1
SoftwareBinary = osrfx2_DCHU_componentsoftware.exe
SoftwareArguments = <<DeviceInstanceId>>
SoftwareVersion = [Link]

[OsrFx2Component_CopyFiles]
osrfx2_DCHU_componentsoftware.exe

The source code for the Win32 app is included in the DCHU 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 universal driver package. Because
Win32-based companion applications cannot be part of a universal 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.yourCustomCapabilityNameTBD_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 DCHU 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.

Registering a COM component in an INF file

Fabrikam needs to register a COM component without using a co-installer. In order to accomplish this in a
universal INF file, they use the Reg2inf tool distributed in the WDK. After building their COM server project (taken
from the In-process ATL COM server sample, they provide the COM .dll as an input to the Reg2inf tool. The tool
then generates the following INF directives that Fabrikam includes in their base INF ( osrfx2_DCHU_base.inx ):
 ; Add all registry keys to successfully register the
; In-Process ATL COM Server MSFT Sample.
[OsrFx2_AddReg_COM]
HKCR,AppID\[Link],AppID,,"{9DD18FED-55F6-4741-AF25-798B90C4AED5}"
HKCR,AppID\{9DD18FED-55F6-4741-AF25-798B90C4AED5},,,"ATLDllCOMServer"
HKCR,[Link],,,"SimpleObject Class"
HKCR,[Link]\CLSID,,,"{92FCF37F-F6C7-4F8A-AA09-1A14BA118084}"
HKCR,[Link]\CurVer,,,"[Link].1"
HKCR,[Link].1,,,"SimpleObject Class"
HKCR,[Link].1\CLSID,,,"{92FCF37F-F6C7-4F8A-AA09-1A14BA118084}"
HKCR,CLSID\{92FCF37F-F6C7-4F8A-AA09-1A14BA118084},,,"SimpleObject Class"
HKCR,CLSID\{92FCF37F-F6C7-4F8A-AA09-
1A14BA118084}\InprocServer32,,%REG_EXPAND_SZ%,"%%SystemRoot%%\System32\[Link]"
HKCR,CLSID\{92FCF37F-F6C7-4F8A-AA09-1A14BA118084}\InprocServer32,ThreadingModel,,"Apartment"
HKCR,CLSID\{92FCF37F-F6C7-4F8A-AA09-1A14BA118084}\ProgID,,,"[Link].1"
HKCR,CLSID\{92FCF37F-F6C7-4F8A-AA09-1A14BA118084}\Programmable,,%FLG_ADDREG_KEYONLY%
HKCR,CLSID\{92FCF37F-F6C7-4F8A-AA09-1A14BA118084}\TypeLib,,,"{9B23EFED-A0C1-46B6-A903-218206447F3E}"
HKCR,CLSID\{92FCF37F-F6C7-4F8A-AA09-1A14BA118084}\VersionIndependentProgID,,,"[Link]"

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_UserSvcCopyFiles = 13 ; copy to Driver Store
A kernel mode driver that is running from the Driver Store can call IoQuer yFullDriverPath and use that path to
find configuration files relative to it. 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) {
winErr = GetModuleFileNameW(handleModule,
path,
pathLength);
…

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 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 [Link] , 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:

[[Link]]
AddReg = Example_DDInstall.AddReg

[Example_DDInstall.AddReg]
HKR,,ExampleValue,,%13%\[Link]

An INF example for setting this as device interface state would be:

[[Link]]
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]
HKR,,ExampleValue,,%13%\[Link]

The above 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.

Summary
The following diagram shows the driver packages that Fabrikam and Contoso created for their Universal Windows
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
Getting Started with Universal Windows drivers
Using an Extension INF File
 minutes to read • Edit Online

For general information about debugging universal 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. Universal 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.
 minutes to read • Edit Online

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 .
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 Universal Windows driver can call this

device driver interface (DDI).
A Universal 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 Mobile
Windows 10 IoT Core
Windows Server 2016
For more info, see Getting Started with Universal
Windows drivers.

Desktop A driver binary for Windows 10 for desktop editions or

Windows Server 2016 can call this DDI.

Mobile A driver binary for Windows 10 Mobile can call this DDI.
 minutes to read • Edit Online

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 editions
and Windows 10 Mobile.
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.
 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

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
both Windows 10 for desktop
editions and Windows 10 Mobile.
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
both Windows 10 for desktop
editions and Windows 10 Mobile.
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.
 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

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

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
Universal 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.
 minutes to read • Edit Online

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 click 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.
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 WDF .
3. In the middle pane, select Kernel Mode Driver (KMDF) .
4. Fill in the Name and Location boxes, and click 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.
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 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 , click 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
 click 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.
1. In Visual Studio, on the File menu, choose New | Project .
2. In Visual Studio, in the New Project dialog box, under Windows Driver , select WDM.
3. Fill in the Name and Location boxes, and click OK .
4. At this point, you have an empty WDM driver project. In the Solution Explorer window, 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 click 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.
 minutes to read • Edit Online

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.

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 click 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.

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 WDF .
3. In the middle pane, select Kernel Mode Driver (KMDF) .
4. Fill in the Name and Location boxes, and click 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 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 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.
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 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 , click 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
click 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.

1. In Visual Studio, on the File menu, choose New | Project .
2. In Visual Studio, in the New Project dialog box, under Windows Driver , select WDM.
3. Fill in the Name and Location boxes, and click OK .
4. At this point, you have an empty WDM driver project. In the Solution Explorer window, 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 click OK .
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.
2. In Visual Studio, on the File menu, choose New | Project .
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 characters
or less. This length limit is defined in wdfglobals.h.
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.
 minutes to read • Edit Online

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
 [[Link]]
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.

[[Link]]
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

[[Link]]
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:
 [[Link]]
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:

[[Link]]
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.
 minutes to read • Edit Online

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

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 WDF .
3. In the middle pane, select Kernel Mode Driver (KMDF) .
4. Fill in the Name and Location boxes, and click 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 software driver.

Case 2: You want to use the legacy NT model

1. In Visual Studio, on the File menu, choose New | Project .
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.

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

4. At this point, you have an empty WDM driver project. In the Solution Explorer window, 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 click OK .

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.
1. In Visual Studio, on the File menu, choose New | Project .
2. In Visual Studio, in the New Project dialog box, under Windows Driver , select WDM.
3. Fill in the Name and Location boxes, and click OK .
4. At this point, you have an empty WDM driver project. In the Solution Explorer window, 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 click OK .

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
4/7/2020 • 4 minutes to read • Edit Online

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 comply with Universal requirements.
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 [Link], 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]
AddService = MyService,, MyService_Install

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

[[Link]]
AddService = MyService,, MyService_Install

[DefaultInstall.NTx86]
CopyFiles = MyCopyFiles_x86
AddReg = MyAddReg

[[Link]]
AddService = MyService,, MyService_Install
 minutes to read • Edit Online

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 ([Link]) 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
Creating a New Device Function Driver
Creating a New Filter Driver
Creating a New Software Driver
 minutes to read • Edit Online

This topic describes how you can build a driver with the Windows Driver Kit (WDK). WDK 10 is fully integrated
with Microsoft Visual Studio. You can build a driver using the Visual Studio development environment, or you can
build a driver directly from the command line by using the Microsoft Build Engine (MSBuild).
You can use any edition of Microsoft Visual Studio 2015, including Microsoft Visual Studio Community 2015, to
build drivers for:
Windows 10
Windows 8.1
Windows 7
Impor tant Starting in Windows Driver Kit (WDK) 8, MSBuild replaced the Windows Build Utility ([Link]). 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 2015. 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. 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. 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, click 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 VS2015 window.
From this window you can use [Link] 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 [Link] using the
default Platform and Configuration, navigate to the project directory and enter the following MSBuild
command:

msbuild /t:clean /t:build .\[Link]

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 Universal Windows driver for the "Debug" configuration,
"Win32" platform, and for Windows 10.

msbuild /t:clean /t:build .\[Link] /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 a Signing properties for driver packages (see Signing a
Driver) Driver)

Counters Manifest Preprocessor Properties for Driver Projects Deployment Properties for Driver Package Projects (see
(for CTRPP) Deploying a Driver to a Test Computer)

Driver Model Settings Properties for Driver Projects Driver Verifier Properties for Driver Package Projects

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. Click Tools > Options .
2. Click the Project and Solutions folder and click 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
Building Drivers for Different Versions of Windows
Using the Microsoft C Runtime with User-Mode Drivers and Desktop Apps
ProjectUpgradeTool
MSBuild
Creating a Driver From Existing Source Files
WDK and the Visual Studio build environment
Signing a Driver
Deploying a Driver to a Test Computer
 minutes to read • Edit Online

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 [Link], which is not available in earlier Windows versions. For
Windows 7 and Vista, you must link with [Link] 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\[Link]" /p:platform=x64 /p:Configuration="Win8 Release"
[Link]
 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)\[Link]</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>
<KernelBufferOverflowLib>$(DDK_LIB_PATH)\[Link]</KernelBufferOverflowLib>
<PlatformToolset>WindowsKernelModeDriver8.1</PlatformToolset>
<ConfigurationType>Driver</ConfigurationType>
<DriverType>KMDF</DriverType>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8.1 Release|Win32'"
Label="Configuration">
<TargetVersion>WindowsV6.3</TargetVersion>
<UseDebugLibraries>false</UseDebugLibraries>
<KernelBufferOverflowLib>$(DDK_LIB_PATH)\[Link]</KernelBufferOverflowLib>
<PlatformToolset>WindowsKernelModeDriver8.1</PlatformToolset>
<ConfigurationType>Driver</ConfigurationType>
<DriverType>KMDF</DriverType>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8 Debug|Win32'"
Label="Configuration">
<TargetVersion>Windows8</TargetVersion>
<UseDebugLibraries>true</UseDebugLibraries>
<KernelBufferOverflowLib>$(DDK_LIB_PATH)\[Link]</KernelBufferOverflowLib>
<PlatformToolset>WindowsKernelModeDriver8.1</PlatformToolset>
<ConfigurationType>Driver</ConfigurationType>
<DriverType>KMDF</DriverType>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8 Release|Win32'"
Label="Configuration">
<TargetVersion>Windows8</TargetVersion>
<UseDebugLibraries>false</UseDebugLibraries>
<KernelBufferOverflowLib>$(DDK_LIB_PATH)\[Link]</KernelBufferOverflowLib>
<PlatformToolset>WindowsKernelModeDriver8.1</PlatformToolset>
<ConfigurationType>Driver</ConfigurationType>
<DriverType>KMDF</DriverType>
</PropertyGroup>

The <KernelBufferOverflowLib> elements must appear in the driver project file before the element that
imports [Link], 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
6/25/2019 • 2 minutes to read • Edit Online

Starting with version 1709, Windows 10 Desktop (Pro and S editions) can run on machines that are powered by
ARM64 processors. However, because Windows 10 on ARM does not support x86 emulation of kernel-mode
drivers, you must recompile kernel-mode drivers to ARM64 using the instructions below.

Setup
1. Download Visual Studio 2017 Preview. You'll need at minimum version 15.4.0 Preview 2.0.
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. Click on 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 . Click 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
 minutes to read • Edit Online

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 [Link]
Basic MSBuild commands for projects and solutions:
Msbuild [Link] /p:configuration=[release | debug] /p:platform=[arm | Win32 | x64]
To create a desktop shortcut:
%comspec% /k pushd <drive\dir> && [Link]
Where <drive\dir> is the location that the files were extracted to, for example, d:\ewdk
%comspec% /k pushd "d:\ewdk" && [Link]

See Also
MSBuild Reference
 minutes to read • Edit Online

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,
click Run and then select the download option and specify the download path as C:\VSSetup (this makes the
later steps easier). Click 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 [Link], click Run and then
specify the download location as C:\Kits\SDK . Click 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 [Link], click Run and then
specify the download location as C:\Kits\WDK . Click 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, click 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 [Link].
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 <[Link]>

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.
<[Link]> 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 [Link].
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 [Link]

4. Build Windows driver projects and solutions

Using the build environment command script
1. Open a Command Prompt window. Locate the [Link] file located in the target directory (for
example, C:\BuildLabInstall).
2. Launch the build environment by running [Link] .
3. Use MSBuild commands to build your driver projects and solutions. For example:

msbuild /t:clean /t:build .\[Link] /p:Configuration="Win8.1 Debug" /p:Platform=Win32

Related topics
Building a Driver
MSBuild
 minutes to read • Edit Online

[This topic applies only to desktop drivers and not universal drivers.]
This topic provides information about distributing the C Runtime Libraries with applications and drivers for
Windows 8 and Windows 8.1. It provides guidelines for user-mode driver and desktop application writers to
compile their code, and package it for redistribution with the necessary C Runtime libraries.

The C runtime libraries (CRT) are no longer shipped as a Windows

shared component
In the past, Microsoft distributed the C runtime libraries (CRT) as a Window shared system component. In previous
versions of the WDK, you could link your code with the Windows System version of the CRT when you built your
driver or traditional Windows app. With the release of Windows 8, the C Runtime libraries are no longer
considered a system component, and you must ship a redistributable version of the CRT with your user-mode
driver or desktop application. This topic discusses the reasons for this change, the new components of the C
Runtime, and strategies for building your desktop app or driver and redistributing the CRT.

Why did Microsoft make this change?

There are now two separate versions of the C Runtime. One is an internal Windows component, and the other is for
use by application and driver developers and ships with Visual Studio. The primary reasons for this change are for
consistency and to support servicing of the CRT for customers.
In the past, applications were sometimes linked to versions of the CRT on computers that did not have the correct
versions of the CRT DLL installed. Using a common public version of the CRT will help eliminate this problem.
In addition, servicing the CRT can be complex. The Visual C team plans to ship periodic updates of the CRT included
with Visual Studio. By using the recommended redistribution strategies, you can easily pick up these changes for
your application. Also, you will not have to worry about a change in the Windows System version of the CRT
breaking your application.
The [Link] is now a system component owned and built by Windows. It is intended for use only by system-level
components. The files [Link] (Visual Studio 2012) or [Link] (Microsoft Visual Studio 2013) are the
new public versions of the CRT and are for use by Desktop application and user-mode driver developers.

Building your code with the C runtime

Visual C++ installs the latest version of the CRT in the System32 directory on a development system. This is
installed as a convenience for the developer. Otherwise, all projects that are built with Visual C++ that link with the
shared CRT require a copy of the DLL in the build directory for debugging and execution. The [Link] can be
used for drivers that target Windows 8.1 and Windows 8 and previous versions of Windows (starting with
Windows Vista).

Redistributing the C Runtime

When you build a user-mode driver or traditional Desktop application in Microsoft Visual Studio, and the
application uses the C run-time libraries (CRT), you must distribute the appropriate CRT dynamic-link libraries.
The recommended strategy for redistributing the CRT depends on the type of application or driver you are
building. For Windows 8 and Windows 8.1, Microsoft provides a Visual C++ Redistributable Package
(VCRedist_x86.exe, VCRedist_x64.exe, VCRedist_arm.exe) that is included with Visual Studio. Developers can chain
the redistributable package in with their other binaries. If you use the redistributable package, the C/C++ Runtime
can be serviced on the customer's computer automatically. If you want to achieve isolation, you can either link
statically, or copy the specific Visual C/C++ DLLs to the application local folder along with their other binaries. An
application local folder is a folder that contains an executable application file. DLLs must be deployed to the
application local folder.
The Visual C/C++ Redistributable Package (VCRedist_*.exe ) is serviced as an application. If your installation
includes the redistributable package, the latest version is installed in System32 upon initial setup, and updates are
enabled using the Microsoft Update service, as a complete package. All components of the Visual C/C++
Redistributable Package are updated as a single unit.
If you copied individual CRT components to System32, without using redistributable package, these would not be
serviced automatically, and may be overwritten accidentally.
A potential problem exists if a driver copies CRT components to System32 and another program runs the
redistributable package, the version installed by the driver will be overwritten. The opposite case is also a potential
problem. If a program ran redistributable package and a driver copies an earlier version of CRT components into
System32, this might break the application. The INF installation process simply checks the version number of the
library to install against the one already in System32, and overwrites it if they are different.

Recommended Strategies
Use the following strategies when redistributing the C/C++ run time components with your drivers and
applications.
For applications installed under Program Files:
Use the Visual C++ Redistributable Package (VCRedist_x86.exe, VCRedist_x64.exe, VCRedist_arm.exe), which
deploys the CRT under System32. In this case, the redistributable package can be updated automatically.
Alternatively, install the DLL(s) to the application local directory (copied directly to the directory where the
application is installed), or link statically to the CRT. In this case, the CRT would need to be serviced manually.
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, you should 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
[Link]
; other files

* [SourceDisksFiles]
[Link] = 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

The following libraries contain the C run-time library functions.

T ERM DESC RIP T IO N

[Link] C runtime.

[Link] C++ runtime.

[Link] Debug version of C runtime. No redistribution allowed.

[Link] Debug version of C++ runtime. No redistribution allowed.

To determine which DLLs you must redistribute with your application, you should collect a list of the DLLs that your
application depends on. One way to collect the list is to run Dependency Walker ([Link]).
When you have the list of dependencies, compare it to the list of files described in Redistributable Code for Visual
Studio 2013 Preview and Visual Studio 2013 SDK Preview. 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.

Summary - What you need to do

Use the Visual C++ Redistributable Package (VCRedist_x86.exe, VCRedist_x64.exe, VCRedist_arm.exe)[Link]
as part of your installation process, if at all possible.
For printer drivers, use desktop application local deployment of the CRT to the driver store.
For UMDF drivers, use static linking of the CRT with your driver code.

Related topics
Determining Which DLLs to Redistribute
Redistributable Code for Visual Studio 2013 Preview and Visual Studio 2013 SDK Preview
Choosing a Deployment Method
 minutes to read • Edit Online

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 [Link] /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.
 minutes to read • Edit Online

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. Right-click the driver project in Solution Explorer and select
Proper ties .
2. In the property pages for the driver project, click Configuration Proper ties and then click 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 )
 O P T IO N DESC RIP T IO N

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 [Link].

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
 minutes to read • Edit Online

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

1. Open the property pages for your driver project. Right-click the driver project in Solution Explorer and select
Proper ties .
2. In the property pages for the driver project, click Configuration Proper ties and then click Driver Model
Settings .
3. Set the properties for the project.
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
 minutes to read • Edit Online

Sets the properties for the Message Compiler ([Link]) 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

1. Open the property pages for your driver project. Right-click the driver project in Solution Explorer and select
Proper ties .
2. In the property pages for the driver project, click Configuration Proper ties and then click Message
Compiler .
3. Set the properties for the project.
This property page is available if you add a message text file (.mc) or a manifest (.man) to your solution.

O P T IO N DESC RIP T IO N

Additional Options Specifies additional options to pass to the Message

Compiler ([Link]) 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.
O P T IO N DESC RIP T IO N

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 names Use this option to specify the folder into which you want
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)
 O P T IO N DESC RIP T IO N

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 ([Link])
WDK and Visual Studio build environment Message compiler task
Event Tracing for Windows (ETW)
 minutes to read • Edit Online

The Managed Object Format (MOF) compiler ([Link]) 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 [Link] and WMI, see mofcomp , Compiling MOF Files, and
Compiling a Driver's MOF File.

Setting Managed Object Format (MOF) Compiler properties for driver

projects
1. Open the property pages for your driver project. Right-click the driver project in Solution Explorer and select
Proper ties .
2. In the property pages for the driver project, click Configuration Proper ties and then click Mof Compiler .
3. Set the properties for the project.
This property page is available if you add a Managed Object Format (MOF) file (.mof) to your solution.

O P T IO N DESC RIP T IO N

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)
 O P T IO N DESC RIP T IO N

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
 minutes to read • Edit Online

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

1. Open the property pages for your driver project. Right-click the driver project in Solution Explorer and select
Proper ties .
2. In the property pages for the driver project, click Configuration Proper ties and then click Stampinf .
3. Set the properties for the project.
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, "[Link]$ARCH$" becomes
"[Link]".

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 .
STA M P IN F O P T IO N DESC RIP T IO N

Driver Version Number Specifies the time that is written in the INF DriverVer
directive for the version number. The format for the time
is [Link] (for example,
[Link]). 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 .
STA M P IN F O P T IO N DESC RIP T IO N

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 .
This setting is equivalent to specifying the Stampinf 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).
This setting is equivalent to specifying the Stampinf option
-k KMDFversion.
 STA M P IN F O P T IO N DESC RIP T IO N

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).
This setting is equivalent to specifying the Stampinf 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.
This setting is equivalent to specifying the Stampinf option
-c catalogfile.

Verbose Shows verbose Stampinf output.

This setting is equivalent to specifying the Stampinf 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.
This setting is equivalent to specifying the Stampinf 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
 minutes to read • Edit Online

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, [Link] installs in
Windows Kits\10\bin\x86.
Visual Studio opens a Review Solution Actions dialog with the title Upgrade VC++ Compiler and
Libraries . Click 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, right-click the driver project name and choose Proper ties . Click 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. Click 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.
 minutes to read • Edit Online

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
 minutes to read • Edit Online

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\[Link]).
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, 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.
 minutes to read • Edit Online

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 click Delete computer .
3. Select Remove provisioning and delete computer . Click Next .
4. When the removal process is complete, click 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
 minutes to read • Edit Online

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 click Delete computer .
3. Select Remove provisioning and delete computer . Click Next .
4. When the removal process is complete, click 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
Windows Driver Testing Framework
%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
 minutes to read • Edit Online

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 click 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 [Link]

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 click 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"

Installing driver test automation service
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"

Installing driver test automation service
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
 minutes to read • Edit Online

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 click 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, right-click References , choose Add Reference...
and select the project to reference.
To remove a reference to an existing project, right-click the existing project you no longer want to reference and
click 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, right-click References , choose Add Reference...
and select the project to reference.
To remove a reference to an existing project, right-click the existing project you no longer want to reference and
click Remove .
See the "Toaster Sample Driver" sample for an example of a single solution that contains multiple drivers:
Related topics
Signing a Driver
 minutes to read • Edit Online

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.
 minutes to read • Edit Online

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.
Signing a Driver During Development and Testing
Signing a Driver for Public Release
2 minutes to read
 minutes to read • Edit Online

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. 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, 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 click Proper ties . In the Details
tab, click 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
 minutes to read • Edit Online

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 [Link].
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, 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\[Link]).
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, 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 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. 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 [Link], where
[Link] 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
 minutes to read • Edit Online

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.
 minutes to read • Edit Online

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.
1. Open the property pages for your driver project. Right-click the driver project in Solution Explorer and
select Proper ties .
2. In the property pages for the driver project, click Configuration Proper ties , click Driver Install , and
then click 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, click Configuration Proper ties , click Driver Install ,
and then click 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, click 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 right-click the driver package project in Solution Explorer and
select Proper ties . In the property pages for the driver package, click Configuration Proper ties , click Driver
Install , and then click 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.
 minutes to read • Edit Online

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. 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, click Configuration Proper ties , click Driver Install , and
then click 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
Deploying a Driver to a Test Computer
How to test a driver at runtime using Visual Studio
Getting Started with Windows Debugging
 minutes to read • Edit Online

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. Right-click the driver package project in Solution Explorer
and select Proper ties .
2. In the property pages for the driver package, click Configuration Proper ties , click Driver Install , and then
click 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,
[Link]. 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, [Link], 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
How to test a driver at runtime using Visual Studio
Deploying a Driver to a Test Computer
Getting Started with Windows Debugging
 minutes to read • Edit Online

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

1. Open the property pages for your driver package. Right-click the driver package project in Solution Explorer
and select Proper ties .
2. In the property pages for the driver package, click Configuration Proper ties , click Driver Install , and then
click KMDF Verifier .
3. Click 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.

O P T IO N DESC RIP T IO N

Enable KMDF Verifier Enables the KMDF verifier on the test computer. The
choices are KMDF verifier is always on or KMDF
verifer 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.
 O P T IO N DESC RIP T IO N

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
Deploying a Driver to a Test Computer
 minutes to read • Edit Online

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
Deploying a Driver to a Test Computer
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

1. Open the property pages for your driver package. Right-click the driver package project in Solution Explorer
and select Proper ties .
2. In the property pages for the driver package, click Configuration Proper ties , click Driver Install , and then
click 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.

O P T IO N DESC RIP T IO N

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.
 O P T IO N DESC RIP T IO N

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
Deploying a Driver to a Test Computer
 minutes to read • Edit Online

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

1. Open the property pages for your driver package. Right-click the driver package project in Solution Explorer and
select Proper ties .
2. In the property pages for the driver package, click Configuration Proper ties and then click 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.

O P T IO N DESC RIP T IO N

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.
This setting is equivalent to specifying the Inf2Cat option
/pageHashes[: file1][, file2]...] .

Add PE Attribute Adds a PE catalog attribute to files. Optionally followed by

a list of files.
This setting is equivalent to specifying the Inf2Cat option
/pe[: file1[, file2]...] .

Add Drm Adds a DRM-level catalog attribute to files. Optionally

followed by a list of files.
This setting is equivalent to specifying the Inf2Cat option
/drm[: file1[, file2]...] .
 O P T IO N DESC RIP T IO N

Verbose Displays detailed information about tool output in the

Visual Studio Output window.
This setting is equivalent to specifying the Inf2Cat option
/verbose .

No Catalog Prevents the creation of any catalog files.

This setting is equivalent to specifying the Inf2Cat option
/nocat .

Use Local Time Use the local time zone while verifying the INF DriverVer
Directive directive. By default UTC, is used.
This setting is equivalent to specifying the Inf2Cat 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
Creating a Driver Package
Signing a Driver
Using Inf2Cat to Create a Catalog File
WDK and Visual Studio build environment
 minutes to read • Edit Online

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. Right-click the driver project in Solution Explorer
and select Proper ties .
2. In the property pages for the driver package, click Configuration Proper ties , click Driver Settings , and
then click Deployment .
3. Click Enable deployment and then select the test computer to use.
4. Click 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
Deploying a Driver to a Test Computer
Deployment Properties for Driver Projects
How to test a driver at runtime using Visual Studio
Building a Driver
Creating a Driver Package
 minutes to read • Edit Online

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. Right-click the driver project and choose Add->New Item . Next, under Visual C++->Windows Driver ,
choose Package Manifest . Click Add .
2. Visual Studio adds a file called [Link] to your driver project. You can 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.) Click
OK .
3. 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 [Link]
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. [Link] 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 [Link]

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, click the Visual Studio 2015 folder. 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.
 minutes to read • Edit Online

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.
 minutes to read • Edit Online

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.
[Link]
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
 minutes to read • Edit Online

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 ChkINF 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. You can also use the
IWDTFDriverPackageAction2 interface to write you own tests.
 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.
 minutes to read • Edit Online

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, click Test and then select Test Group Explorer .
2. In the Driver Test Group Explorer window, click the Create a new test group button. Or, click 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. Click 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, click 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), click 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. Click >> 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 clicking 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, click 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, click 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, click 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 run the HCK Test Suites in WDK 8.1
How to select and configure the Device Fundamentals Tests
Deploying a Driver to a Test Computer
Getting Started with Windows Debugging
Hardware Certification Program
Windows Hardware Certification Kit (HCK)
How to test a driver at runtime from a Command Prompt
 minutes to read • Edit Online

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, click Test and then select Test Group Explorer .
2. In the Driver Test Group Explorer window, click 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, click 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 , right-click the HCK Test Suite you want to copy and click Expor t Test Suite...
from the short-cut menu. (The command runs the [Link] 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 [Link] 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 [Link] script and specify the name of test suite and destination directory. The script has the
following syntax:

[Link] testSuite destinationPath

The testSuite is one of the following:

[Link] Fundamentals
[Link]
[Link]
[Link]
[Link]
[Link]
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

[Link] 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 [Link] script.
"[Link] <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 [Link] script and specify the path and name of the INF file. The script has the following
syntax:
 [Link] infFileName

For example:

[Link] [Link]

Note The [Link] test suite does not make use of an INF file, however, the [Link] script
requires an INF file. You can provide the name of substitute INF file if necessary.

HCT Test Suites

HCK [Link] Fundamentals Test Suite
HCK [Link] Test Suite
HCK [Link] Test Suite
HCK [Link] Test Suite
HCK [Link] Test Suite
HCK [Link] 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 [Link] 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 [Link] 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 [Link] 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 [Link] 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 [Link] Test Suite

Use this test suite to test printers. The test suite uses tests that are part of the HCK [Link] 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 [Link] 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 [Link] 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 [Link] 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
Deploying a Driver to a Test Computer
Getting Started with Windows Debugging
Hardware Certification Program
Windows Hardware Certification Kit (HCK)
How to test a driver at runtime from a Command Prompt
 minutes to read • Edit Online

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. Click 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
devi
ces
that
wer
e
inst
alled
with
a
spec
ific
INF
File:
INF::FileName= INF_File_Name
For example,
INF::OriginalInfFileName='[Link]'
Inf::OriginalInFileName can be used with
any INF.
To
test
a
devi
ce
with
a
spec
ific
Devi
ce
Id:
DeviceId=’ DeviceId’
For example,
DeviceID=’USB\ROOT_HUB\4&1CD5D022&0’
To Interfaces:: InterfaceGUID
test
a
 devi
PA RA M ET ER DESC RIP T IO N
ce
with
a
spec
ific
inter
face:
To Volume::DriverLetter=’ DriveLetter’
test
a For example, Volume::DriverLetter=’c:\’
devi
ce
with
a
spec
ific
driv
er
lette
r:
To
test
a
devi
ce
with
a
spec
ific
driv
er:
DriverBinar yNames= [Link]
Where [Link] is the inf used to install the
driver. You can also use the folloiwng target the
devices(s) that use [Link] driver.
(DriverBinar yNames ='[Link] ') 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='[Link]'))")
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") WDTF_TARGETS : INFO : Target:
KMDFTest Device 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
PA RA M ET ER DESC RIP T IO N
WDTF will use the ANY Simple IO Interface.
See attached files config and log files for more
details. WDTF_TARGETS : INFO : Target: KMDFTest
Device 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
devi
ce
of a
spec
ific
devi
ce
Clas
s:
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.
PA RA M ET ER DESC RIP T IO N

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.
PA RA M ET ER DESC RIP T IO N

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
possible value is 0.

MaxFunctionCode Specifies the maximum value of the FunctionCode field in

the FSCTLs (or IOCTLs for IOCTL tests). The maximum
possible value is 4095.

MinFunctionCode Specifies the minimum value of the FunctionCode field in

the FSCTLs (or IOCTLs for IOCTL tests). The minimum
possible value is 0.

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
 PA RA M ET ER DESC RIP T IO N

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
 minutes to read • Edit Online

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. Right-click the driver project in Solution Explorer and select
Proper ties .
2. In the property pages for the driver, click Configuration Proper ties , click Driver Install , and then click
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 , click Install and Verify , and then select the Default Driver Installation
Task .

Related topics
Provision a computer for driver deployment and testing (WDK 8.1)
Deploying a Driver to a Test Computer
Testing a Driver
 minutes to read • Edit Online

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, click the Driver Test Group you are interested in.
2. Click 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. Click 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, right-click the results from the test run that you are interested in.
2. Click Save to open a dialog box to save the results to a folder.
 minutes to read • Edit Online

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 Manually installing WDTF on a test computer.

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:

[Link] [/name:<Test Method>] [<Test Name>.dll | <Test [Link]> ] [/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 [Link] Command Options .
For example, to run all PnP tests in the Devfund_PnPDTest.dll on a device with a specific device ID.

[Link] 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.

[Link] /name:"*PNPSurpriseRemoveAndRestartDevice" Devfund_PnPDTest.dll

/P:"DQ=DeviceID='USB\ROOT_HUB\4&1CD5D022&0'"
Related topics
Device Fundamentals Tests
Device Fundamentals Test Parameters
How to run the HCK Test Suites in WDK 8.1
Test Authoring and Execution Framework (TAEF)
[Link] Command Options
 minutes to read • Edit Online

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 click 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 [Link]

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 click 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"

Installing driver test automation service
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"

Installing driver test automation service
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
 minutes to read • Edit Online

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, click 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#

1. From the File menu, click New > Project .
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# .
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 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 Script
1. From the File menu, click New > Project .
2. From the list of installed templates in the New Project dialog box, select Script > Windows Driver .
3. Select Windows Driver Test Script .
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 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.

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
Windows Driver Testing Framework
How to add test metadata
 minutes to read • Edit Online

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"[Link]", L"TRUE")
TEST_METHOD_PROPERTY(L"[Link]", L"DQ")
TEST_METHOD_PROPERTY(L"[Link]", L"A WDTF SDEL query that is used to
identify the target device(s) - [Link]
TEST_METHOD_PROPERTY(L"[Link]", 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"[Link]", L"My Plug and Play Surprise Remove Test")
TEST_METHOD_PROPERTY(L"[Link]", L"My Test Category")
// Optional properties for driver tests
TEST_METHOD_PROPERTY(L"[Link]", L"[Link]")
// 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("[Link]", "TRUE")]
[TestProperty("[Link]", "DQ")]
[TestProperty("[Link]", "A WDTF SDEL query that is used to identify the
target device(s) - [Link]
[TestProperty("[Link]", "INF::OriginalInfFileName='%InfFileName%'")]
// TODO: Required properties to be customized to match your test requirements.
[TestProperty("Description", "Plug and Play Surprise Remove Generated Template")]
[TestProperty("[Link]", "My Plug and Play Surprise Remove Test")]
[TestProperty("[Link]", "My Test Category")]
[TestProperty("RebootPossible", "true")]
// Optional properties (see Windows Driver Kit documentation for additional optional
properties):
[TestProperty("[Link]", "[Link]")]

Windows Script Component (.wsc)

<!-- Define a test method with metadata: -->

<method name="PlugAndPlaySurpriseRemoveTest">
<!-- Required properties for ERT-->
<TestMethodProperty name="[Link]" value="TRUE"/>
<TestMethodProperty name="[Link]" value="DQ"/>
<TestMethodProperty name="[Link]" value="A WDTF SDEL query that is used
to identify the target device(s) - [Link]
<TestMethodProperty name="[Link]"
value="INF::OriginalInfFileName='%InfFileName%'"/>
<TestMethodProperty name="RebootPossible" value="true" />
<!-- TODO: Properties to be customized to match your test requirements -->
<TestMethodProperty name="Description" value="Plug and Play Surprise Remove Generated
Template"/>
<TestMethodProperty name="[Link]" value="My Plug and Play Surprise Remove Test"/>
<TestMethodProperty name="[Link]" value="My Test Category"/>
<!-- Optional properties for ERT-->
<TestMethodProperty name="[Link]" value="[Link]"/>
<!-- (see Windows Driver Kit documentation for additional optional properties) -->
</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="[Link]" value="Sleep with IO Before and After"/>

C ++

[C++]
TEST_METHOD_PROPERTY(L"[Link]", L"My Plug and Play Surprise Remove Test")

[Link]
A standard parameter for a method call. A test can have multiple parameters.

[Script]
<ModuleProperty name="[Link]" value="TM"/>

C ++

[C++]

TEST_METHOD_PROPERTY(L"[Link]", L"DQ")

[Link].<ParameterName>.Description
The description for the parameter.
 [Script]

< TestProperty name="[Link]" value="Test mode parameter: Logo or

Simple"/>

C ++

[C++]
TEST_METHOD_PROPERTY(L"[Link]", L"A WDTF SDEL query that is used to
identify the target device(s)")

[Link].<ParameterName>.Default
The default value for the parameter.

[Script]
< TestProperty name="[Link]" value="Logo"/>

C ++

[C++]
TEST_METHOD_PROPERTY(L"[Link]", L"INF::OriginalInfFileName='%InfFileName%'")

[Link]
This attribute marks the test for inclusion in the WDK.

[Script]
< TestProperty name="[Link]" value=""/>

C ++

[C++]

TEST_METHOD_PROPERTY(L"[Link]", L"TRUE")

[Link] y
 Describes the category of a test.

[Script]
< TestProperty name="[Link]" value="Logo\Device Fundamentals"/>

C ++

[C++]
TEST_METHOD_PROPERTY(L"[Link]", 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
 minutes to read • Edit Online

This page describes common issues you may encounter when using the Static Driver Verifier tool in the WDK. The
information below pertains specifically to the version of the tool that ships with Windows 10 October 2018 Update
(Version 1809).

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].[Link]" 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 [Link] 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 '[Link]', line 1511) is present, this is
a known issue which requires errata (errata ID 40705). If you need further assistance, please email
stlogohelp@[Link].
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@[Link].
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@[Link].
5. Open [Link] 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@[Link].
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@[Link]:

a. The text file with the output of running SDV
b. The [Link] file
c. The [Link] 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
[[Link] or [Link]] 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 [Link] could not be found)

Make sure the TAEF package is deployed or [Link] is deployed to a location in your PATH environment
variable.
The key symptom is the failure to load [Link].
If you have a Server GUI installation with the same architecture and Windows version as your ServerCore
installation, copy the [Link] 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 [Link]/[Link] with 0xc0000142

error
The [Link] file contains a message similar to this error:

c:\Program Files\Microsoft Visual

Studio\2017\BuildTools\Common7\IDE\VC\VCTargets\[Link](1144,5): error MSB6006: "[Link]"
exited with code -1073741502.

Done executing task "LIB" -- FAILED.

Please use errata 41600 for this issue.

 minutes to read • Edit Online

The Windows Server Hardware Certification Program requires a Driver Verification Log (DVL) for all driver
submissions. The DVL contains a summary of the results from the Code Analysis (CA) and Static Driver Verifier
(SDV) 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. Create the Driver Verification Log. From the Driver menu, click Create Driver Verification Log....
6. Verify that both the Code Analysis Log and the Static Driver Verifier Log files are detected. Click Create .
The driver verification log has the file name extension .[Link]. The log is created in the project folder, for
example, \myDriverProject\[Link].
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 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 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):

[Link] <vcxprojectfile> /target:dvl /p:Configuration="Release" /P:Platform=x64

Related topics
Creating a log file for Static Driver Verifier
Creating a log file for the code analysis tool
Hardware Certification Program
Analyzing Driver Quality by Using Code Analysis Tools
How to run Code Analysis for drivers
Using Static Driver Verifier to find defects in drivers
 minutes to read • Edit Online

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 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, click 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 [Link] 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\[Link]" x64

-Or-

"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\[Link]" x64

Run the Code Analysis tool.

[Link] <vcxprojectfile> /p:Configuration="Win8 Release" /P:Platform=x64 /target:clean

[Link] <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
Creating a log file for Static Driver Verifier
Code Analysis for Drivers
Hardware Certification Program
Analyzing C/C++ Code Quality by Using Code Analysis
How to run Code Analysis for drivers
 minutes to read • Edit Online

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.
To create a log file for Static Driver Verifier
1. In Microsoft Visual Studio Ultimate 2012, select the driver project file and then 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, click 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 [Link] 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.
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 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\[Link]" x64

-Or-

"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\[Link]" x64

Run Static Driver Verifier.

[Link] <vcxprojectfile> /p:Configuration="Win8 Release" /p:Platform=x64 /target:sdv /p:inputs="/clean"

[Link] <vcxprojectfile> /p:Configuration="Win8 Release" /p:Platform=x64 /target:sdv
/p:inputs="/check:[Link]"

Related topics
Creating a driver verification log
Static Driver Verifier
Using Static Driver Verifier to Find Defects in Drivers
Hardware Certification Program
 minutes to read • Edit Online

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.