Windows Driver Testing Basics: Tools, Features, and Examples

One tiny bug missed in the driver code can crash the entire system. Given many technical complexities and high standards for driver performance, not every QA team knows how to and can test efficiently this type of software. This process requires expertise with specific QA tools and driver development.

In this article, Apriorit experts share the basics of driver testing for Windows, including key types of drivers and testing utilities you can use. We also go over some of the issues you can encounter, from having to test drivers without signatures to being unable to localize code errors. 

This article will be helpful for QA engineers and technical leaders who want to start a driver development project and need more information about the testing process.

Definition and types of Windows drivers

A driver is a software component that provides an interface for a physical or virtual device. A driver interprets high-level requests coming from user software and the operating system into low-level commands recognized by a device.

In Windows, drivers are stored as binary files with the .sys extension along with optional supplementary files with .inf and .cat extensions.

.inf files are driver installation files that describe the type of device that a driver is designed for, the location of driver files, and any dependencies. During driver installation, data is entered in the system registry from the .inf file. This registry serves as a database for a driver’s configuration.

.cat files contain a list of cryptographic hash sums of all driver files. In Windows, installed drivers are usually located in the %SystemRoot%System32drivers system catalogue, but they can also be stored in any other place. After installation, a driver is loaded in the system and is ready to work. Some driver types require a reboot after installation.

Drivers can be divided into user-mode and kernel-mode types depending on their mode of execution.

User-mode drivers provide an interface between user applications and other operating system components such as kernel-mode drivers. A printer driver is an example of a user-mode driver.

Kernel-mode drivers are executed in the privileged kernel mode. They are usually stored in the form of a chain formed during driver execution. The location of each driver in this chain is defined by its task. In this article, we’ll focus on kernel-mode drivers.

Queries from user applications to a device pass through several drivers. Each of these drivers processes and filters the query, which is called an IRP packet (I/O request packet) according to Windows driver terminology. If a driver is loaded in the wrong place in the chain, the query will be processed incorrectly and, as a result, the system may crash.

Figure 1 below represents a simplified model of such a query for disk-based I/O. A user app creates a query to read a file on the disk. This query passes through a chain of drivers, each of which processes incoming and outgoing packets.

Each kernel-mode driver works with a specific device, represented in Windows as a device object. This means that the final destination for an I/O query coming through a driver is always a physical or virtual device. This applies to both drivers of physical PnP devices as well as non-PnP software drivers. While testing drivers, it’s important to understand that more than one driver exists between a user application and a device. In the chain, each driver can influence the final result of the query to the device.

Kernel-mode drivers can be divided into the following types:

• Plug and play (PnP) device drivers ensure access to physical PnP devices and manage device power. 
• Non PNP device drivers enhance user application functionality and provide access to kernel-mode features that are unavailable via standard API calls. These drivers don’t work with physical devices. 
• File system drivers provide access to the file system. They transform high-level queries for reading and writing files to low-level commands for a disk driver (reading and writing a sector on a physical disk).

There is a driver development model called the Windows Driver Model (WDM) as well as a Windows Driver Framework (WDF), which consists of the Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). Both the WDM and WDF simplify the process of making driver code compatible across Windows versions. 

The WDM includes the following driver types:

• Bus drivers. These drivers support a specific PCI, SCSI, USB, or other port, controlling the connection of new devices to the bus.
• Functional drivers. These drivers ensure the functionality of a specific device. They usually support read-write operations and device power management.
• Filter drivers. These drivers modify queries to a device. They can be situated either above or below a functional driver in the chain of drivers.

The main aspects of Windows driver testing

There are certain tests that are required for Windows driver testing in Linux and Windows regardless of driver type. So before covering the nuances of testing different types of drivers, we’ll consider their common aspects.

Operating systems

First, you always have to keep in mind that a particular driver can behave differently on different operating systems. Furthermore, you need to take different kernel versions into account because they can differ even within the same operating system. Windows 10 and 11 through different major updates have different kernels. Therefore, you must test as many systems as possible. It’s worth mentioning that Microsoft officially supports Windows 10 and 11, with Windows 10 being the most widely used version. However, enterprises may still use older systems like Windows 8.1.

Updates

It’s necessary to check critical situations for a driver such as shutdown, reboot, and reset. You should also keep a system’s security systems in mind: firewalls, data execution prevention, user account control, and antivirus software. Operating system updates can also influence driver functionality. Therefore, it’s crucial to perform testing with the latest updates. In addition, you also need to test driver updates.

Hardware dependency

Besides software dependency, there’s also hardware dependency. That’s why you have to check how a driver works with various processor and kernel configurations with an enabled and disabled page file. While testing a driver, you have to enable a driver verifier, which will create an additional load for the driver. During a testing process, check the correctness of driver installation and uninstallation, system reset, and hibernation.

How to test Windows drivers

Testing a driver using a real machine isn’t always secure since incorrect operation can lead to serious consequences. That’s why you should test a driver in a virtual machine until it’s stable. 

Testing different types of drivers requires different approaches and activities. Let’s examine testing for three common drivers: file system filters, virtual storage, and USB devices.

File system filter drivers

As the name suggests, system filter drivers work with file systems. Therefore, while testing such drivers, you should use file systems such as NTFS, FAT32, exFAT, and ReFS. You can also use various file managers can be used besides Explorer, such as FAR or Total Commander. And don’t forget about complex file system changes in addition to simple operations such as copying, deleting, and renaming.

Complex file system changes include:

• Mounting and unmounting new disks: ISO images, network disks, virtual hard disks, USB flash drives
• Making sector configuration changes (changing drive letter or name)
• Actions performed on a disk:
  • Formatting sectors
  • Shrinking sectors
  • Defragmenting sectors
  • Checking for errors
  • Compressing sectors
  • Deleting sectors
  • Making a disk dynamic
  • Converting a disk in GPT/MBR
  • Creating a new sector.

You also have to check:

• Various hardware configurations (SSDs and HDDs with different capacities)
• Driver behavior when stopping and starting services or installing/uninstalling an app
• How a driver works with an encrypted disk using Windows tools
• Driver compatibility with antivirus software, as such software is also a filter driver

Virtual storage driver

Before testing a Windows driver created for virtual storage, you should understand that your file system will be stable. For virtual storage drivers, check how your driver:

• Works when opening, creating, editing, saving, copying, removing, renaming, and deleting files and folders
• Searches in files and folders
• Works with files that have names containing lots of characters, digits, special symbols, spaces, hieroglyphs, non-unicode symbols, and cyrillic 
• Works with files of different formats like texts, images, archives, and Microsoft Office files 
• Works with files with various attributes: read-only, hidden, system, and archive 
• Handles changing file permissions and using compression and encryption 
• Creates correct shortcuts (symlink and hard link) and hidden copies 
• Handles files of different sizes and many files
• Works with folders that contain more than five subfolders
• Handles conflicts like copying a file with the name of a file that already exists in the destination or canceling copying or deleting. 
• Saves a file downloaded from the internet or a shared network disk 
• Mounts and unmounts in both standard situations and edge cases. For instance, try unmounting while copying to storage, then check whether the disk has been successfully mounted after rebooting the system.

Also, check the disk’s read-write speed. 

USB device driver

With USB driver testing, you should try to cover as many USB devices as possible. You can start with the most popular, such as flash drives, printers, scanners, mice, keyboards, portable hard drives, smartphones, and card readers. But you should also test less popular devices such as Bluetooth devices, Ethernet devices, USB hubs, microphones and headsets, and webcams.

Take various USB interfaces into account: USB 1.0, 2.0, 3.0, and 3.1. In addition, don’t forget about unplugging and plugging devices, disabling safe and unsafe devices, and deleting devices in the device manager. Furthermore, check the device driver installation and uninstallation.

Utilities for driver testing and analysis

There are numerous tools for testing Windows drivers that allow you to monitor the status of the driver in the system, verify its functionality, and perform testing.

Built-in Windows utilities are enough to get basic information regarding a driver’s status (e.g. whether it’s loaded in the system).

Built-in Windows utilities:

• Msinfo32
• Driverquery
• PNPUtil
• Sc Driver Verifier

Sc Driver Verifier is a built-in utility that allows you to verify driver functionality. To deeply analyze test drivers, you’ll need additional tools available in the Windows Driver Kit (WDK).

Windows System Information (msinfo32)

Msinfo32 allows you to get a list of all registered drivers in the system, the type of each driver, its current status (loaded/not loaded), and start mode (System/Manual).

To call the System Information console, call the Run dialog using Win+R and launch msinfo32. On the left sidebar of the System Information console, choose the following tabs: Software Environments > System Drivers.

This utility allows you to review and store information about registered drivers. It also lets you view a list of drivers from a remote computer if you have access to its Windows Management Instrumentation (WMI). This option is located in View > Remote Computer.

Driverquery

This command line utility provides information similar to that found in msinfo32. It can be launched through cmd using the driverquery command:

Additional parameters allow you to modify the output to the console:

• /V for detailed output with driver status information similar to that shown by msinfo32
• /SI for information about signed drivers 
• /S to get information about a driver on a remote system

PNPUtil 

PNPUtil is a command line tool that lets an administrator interact with driver packages. With this tool, you can: 

• Add a driver package to the driver store 
• Install a driver package on the computer 
• Delete a driver package from the driver store 
• Enumerate the driver packages that are currently in the driver store. Only driver packages that are not in-box packages are listed. An in-box driver package is included in the default installation of Windows or its service packs. 

Examples of commands: 

• pnputil /add-driver C:\Drivers\example.inf /install 
• pnputil /delete-driver oem10.inf /uninstall /force 
• pnputil /enum-drivers

The PNPUtil is a perfect tool for regression, compatibility, stress, and reliability testing. This tool can help you speed testing by:

• Running automated driver tests and complex scripts
• Quickly configuring new test environments and re-configuring them for issue localizations
• Managing scale testing of remote systems

The sc command

Executing this command allows you to review a driver’s status and launch or stop the driver. To see a list of drivers, run the following command:

sc query type= driver

Windows Driver Kit (WDK)

This is a wide set of tools for driver testing that you can use as independent utilities or as part of MS Visual Studio. The WDK contains a set of testing modules and utilities that allow you to manage devices and drivers, monitor resource usage, implement verification, and so on.

A Device Fundamentals Test set consists of the following tests:

• Concurrent Hardware and Operating System (CHAOS) test
• Coverage test
• CPU stress test
• Driver installation test
• I/O test
• Penetration test
• Plug and play test
• Reboot test
• Sleep test

To perform testing, WDTF Simple I/O plugins must support your tested device. Follow Microsoft recommendations to learn more about WDTF Simple I/O plugins.

Device Fundamental Tests are organized in the form of dll libraries and are situated in the %ProgramFiles%Windows Kits10TestingTestsAdditional Test directory (in Windows 10). These tests can be launched by the TE.exe utility that’s part of the Text Authoring and Execution Framework (TAEF), and they have to be installed with the WDK. You can find TE.exe in the %ProgramFiles%Windows Kits10TestingRuntimesTAEF directory.

Here’s an example of how we might launch a test:

TE.exe Devfund_Device_IO.dll /P:”DQ=DriverBinaryNames=testdriver.sys”

At this stage, we launch a device I/O test with a test driver called testdriver.sys as a parameter. Device Fundamentals Tests and TAEF are both perfectly suitable for automated driver testing.

Windows Device Console (devcon)

The console is a command-line utility that provides information about plug-and-play devices and their system drivers, manages devices, and filters drivers for specific device classes. Using devcon, you can install, remove, connect, disconnect, and configure devices. Devcon allows you to set a template while searching for a specific device. An asterisk (*) can replace one or several symbols in queries.

Examples of commands:

• devcon.exe hwids * displays a list of names and IDs of all devices
• devcon.exe classes displays a list of all device classes
• devcon.exe driverfiles * displays a list of driver files for all system devices
• devcon.exe classfilter USBDevice upper displays filter drivers for the DiskDrive device class
• devcon.exe /r classfilter DiskDrive upper !OldFilter +NewFilter replaces a filter driver for the DiskDrive device class

Memory Pool Monitor (PoolMon)

The Memory Pool Monitor displays information about the allocation of downloadable and non-downloadable core memory. This utility is used for detecting memory leaks while testing.

The memory allocation statistics for a driver are sorted by tag rather than by driver name. This tag should be set in the driver code using the ExAllocatePoolWithTag and ExAllocatePoolWithQuotaTag procedures. If a tag is not set in the code, then the system sets a None tag. Because of this, localization of memory issues can be complicated.

Windows Hardware Lab Kit (HLK)

You can use this framework for testing many devices based on Windows 10 and newer versions. To test devices with Windows 7, Windows 8, and Windows 8.1, use Windows HLK’s predecessor, the Windows Hardware Certification Kit (HCK).

While testing with Windows HLK, you should use an environment consisting of two components: an HLK test server (controller) and a test system (client). An HLK controller manages a set of tests, connects them with a test system, and defines an execution schedule. The controller allows you to manage testing on a set of client machines.

The client system configures devices and drivers for further testing and executes test scenarios.

The preparation and testing process can be completed with the following steps:

1. Install the HLK controller on a dedicated machine.
2. Install the agent on one or several test machines.
3. Create a set of test machines that connects one or several machines in a logical manner.
4. Create a controller-based project that defines the elements to be tested.
5. Choose a test target, such as external devices of a test machine or software components such as filter drivers.
6. Choose and launch tests. You can use playlists to perform a specific set of scenarios.
7. Review and analyze test results.

Driver Verifier

This built-in Windows utility created to verify kernel-mode drivers and detect driver bugs that can damage the operating system. Driver Verifier is most effective with manual or automated testing using WDK tools. This utility is stored as a binary Verifier.exe file in the %WinDir%system32 directory.

This utility can be launched in two modes: via command line and via the Driver Verifier Manager. To launch the command line version, run the Command Prompt as administrator and enter the verifier command with minimum one parameter, for instance help - verifier /?). To open the Driver Verifier Manager, run verifier without parameters.

Let’s look at a driver verification procedure using the Driver Verifier Manager as an example:

1. Run the Driver Verifier Manager: Win + R > verifier.
2. Choose a set of standard tests or create custom tests. The manager also can display and delete current settings as well as display information about verified driver.
3. Choose one or several drivers to verify.
4. Reboot the computer. The driver will be tested according to the chosen settings until it is removed from the list of verified drivers.

The list of standard and supplementary settings for Driver Verifier may be different in different Windows versions. Here are the standard options for Windows 10: 

• Special pool allows the Driver Verifier to access the released memory and allocate memory for a driver in a special place that’s monitored for memory damage.
• Force IRQ checking detects issues where a driver cannot access unloaded memory with high IRQL if the spin lock option is enabled.
• Pool tracking helps detect memory leaks by monitoring driver’s memory allocation and checking that the allocated memory eventually gets released.
• I/O verification option detects whether a driver uses input/output procedures incorrectly. In modern Windows, this option also contains an Enhanced I/O Verification function that performs stress testing for the following elements: PnP IRPs, power IRPs, and WMI IRPs.
• Deadlock detection allows the Driver Verifier to monitor synchronization objects such as mutexes and spin locks used by a driver.
• DMA verification monitors the use of Direct Memory Access procedures and allows devices to work directly with memory without the CPU.
• Security checks help detect security issues such as calls of kernel-mode procedures with user-mode memory addresses or incorrect parameters.
• Miscellaneous checks test the driver for potential errors that can lead to a driver or system crash – for example, if a driver releases memory that still contains working driver structures. 
• DDI compliance checking searches for potential errors in the communication (Device Driver Interface) with a kernel interface of the operating system.

To efficiently detect bugs with Driver Verifier, you should follow the recommendations below:

1. Don’t verify several drivers at the same time except if that’s precisely your goal.
2. Enable memory dump collection for cases where the operating system crashes (BSOD).
3. If needed, enable debug mode and connect to the test system with a debugger using the network or COM/USB port.

Now that you have the essential toolset for Windows driver testing, let’s focus on other important testing aspects and start with digital driver signatures.

Working with digital driver signatures 

A driver signature is a digital key that verifies the validity of this driver package and confirms that it hasn’t been altered. In Windows 8, 8.1, 10, and 11, you can’t install a driver package without a package signature encrypted with SHA-2. 

For a driver to be recognized as coming from a trusted publisher, the driver package has to be signed with a Windows Hardware Quality Labs (WHQL) signature in Windows XP.  In Windows Vista and Windows 7, a driver package has to be signed with a Trusted Root CA certificate.

In old unsupported systems such Windows XP, Windows Vista, and Windows 7, there is no strict requirement for a package signature in order to install a driver package. Therefore, you can easily install a driver without a signature. However, if a package isn’t signed, you’ll see this warning:

Before running a driver in kernel mode, Windows checks the digital signature of the driver’s binary .sys file. It’s worth noting that Windows XP and Windows Vista 32-bit don’t require a digital driver signature. Windows Vista 64-bit, Windows 7, Windows 8, and Windows 8.1 require a signature with a certificate containing the Microsoft Code Verification Root in its root or with another certificate trusted by the kernel. Windows 10 version 1607 and newer requires a driver to be signed with the Windows Hardware Developer Center Dashboard portal.

To start a Windows driver test, you can temporarily disable the digital driver signature check. In Windows 10, you can do this the following way:

1. Hold the Shift button and choose the Restart option in the main Windows menu.
2. Select Troubleshoot -> Advanced Options -> Startup Settings -> Restart
3. In Startup Settings, push F7 to choose the Disable driver signature enforcement option.

To test drivers in Windows with the Secure Boot option enabled, you must ensure that your drivers have valid signatures.

Error localization

An existing bug in a driver can lead to a system crash. That’s why, besides defining specific steps, localizing a bug means understanding whether your driver has caused the BSOD or not. In order to determine that, you have to review the system memory dump. This is collected automatically after the BSOD and you can find it in the C:WindowsMemory.dmp directory. To review the full kernel dump, you should tell the system to collect it. The kernel dump also contains necessary information regarding free memory on the disk. To get this information, you should open Advanced system settings > Startup and Recovery and click Settings.

Check whether the Complete memory dump or Kernel memory dump option is enabled.

In these settings, you can change the storage directory for the memory dump.

Once you have the full dump, you should analyze it. This is where WinDbg will be useful. Before using this tool, you have to download the specific Microsoft symbols. You can read this guide on how to do it.

Open the dump and run the !analyze –v command. Pay attention to the stack and you’ll see the reason for the BSOD. In some cases, you won’t be able to get the dump file from the system because it’s continually crashing. In this case, you should use the Windows advanced startup options. You can then run the system in several special modes. The simplest and most reliable one is afe mode. In safe mode, your options within the system will be limited. But the only thing you need to get is the dump file from the C:Windows folder, and this mode allows you to get it.

You can also try to disable automatic restart on system failure, which may help prevent continual restarts. In case of a system crash, you should check whether a driver verifier was involved. This information can be very helpful for developers when they try to reproduce the bug. Besides a system crash, you can also face other issues such as those related to functionality or performance.

To localize functionality issues, you should take the following actions:

Try to recreate the same issue in another environment (in a different operating system, without antivirus software, on another file system, using a real machine, etc.).
You also can try other conditions, such as different types of files and different file sizes.
If the issue is related to your USB device, check other devices of different types.
If the network is a potential cause of an error with a network device driver, check various network settings (latency, bandwidth, enable or disable the firewall).
When the issue appears solely for users with specific permissions, use different permissions (administrator or standard) to localize the issue.

If the issue is related to performance, your actions will depend on the element whose performance you are trying to improve:

• If the issue is in the network device driver, emulate network latencies or try recreating this issue in a high-speed network.
• If the issue is related to file operations, then check it using a different number of files of different sizes.
• If the issue is related to the USB camera, check its performance with different applications.

These steps will help you test driver performance in different scenarios, locate the bug, and describe it in detail. In the next section, we’ll provide an example of a testing report that Apriorit QA team always provides to developers after testing.

Driver testing report sample

We at Apriroit have a highly experienced team of QA professionals who help us ensure the ultimate quality of the products we deliver to our clients. We also use the results of QA tests for internal quality improvements.

When working with us, you’ll also receive QA reports with the results of your product’s testing. Usually, these reports look like this:

Testing type	Regression testing
Driver	DriverFsfilter.sys (file system filter driver)
Version	1.0.0.1
Windows versions	Windows 11, Windows 10 x64
Tests performed	Installation/Uninstallation Processing of read-write operations: Sectors with the following file systems: NTFS, FAT32, exFAT, ReFS Different file sizes (1Kb to 10 Gb). On physical mounted and network disks A stress test with unsafe disk disconnection Compatibility with Windows 10 updates (from 1607 to 1703) Driver Verifier: standard settings plus the Randomized low resources simulation option
Errors	Periodic BSOD emerging with Randomized low resources simulation enabled in Driver Verifier
Result	With the Randomized low resources simulation option enabled in Driver Verifier, the driver periodically causes the BSOD in Windows 10 x64. In other situations, the driver is stable.
Application	Windows 11 full memory dump attached: MEMORY.dmp

Such reports help the development team understand exactly what causes a bug and how they can fix it. A detailed report is invaluable for clear communication between the development and QA teams, efficient bug fixing, and seamless releases of high-quality products.

Conclusion

Testing a Windows device driver is a complex yet necessary part of releasing a reliable device and firmware for it. If a device driver contains a bug, it can influence not only device performance, but cause BSOD of the whole operating system. Detecting, localizing, and eliminating driver errors significantly decreases the risk of unstable system behavior for end-users. 

QA process for a driver depends on the type of driver you have, its target OS, device, and environment. You also need to select relevant tools and utilities to get the most valuable insights into your driver’s performance and determine the best ways to improve it.

Apriorit not only offers comprehensive Windows driver development. Our QA team has decades of experience testing kernels and device drivers and will be happy to help you ensure flawless quality of your next driver.