Introduction

This document introduces the tools used to test Windows Kernel Drivers. These are not functional tests, these tools know nothing about the intended function of the driver, they test its fitness from a Windows perspective.

Build:

The driver will need to be built in debug mode so optimisations are off, ie, the code lines up with the binary, making debugging easier.

...

It works in a number of ways, but as an example, memory allocation. When Verified, a driver request for memory will create a chunk that is surrounded by guard memory, which has a pattern written to it. When that memory is freed, any under or overwrite is detected, and the machine crashed, with a Verifier error message, and the driver code pointed to.

Another example if the test is for accessing paged code or data at elevated levels, such as during an interrupt or timer expiry. Very often this wont cause a page fault, as the memory with the pageable data hasn't been paged. But if memory starts becoming scare, you get a crash. Verifier will check for this even though the memory hasn't been paged yet, and crash the machine, with the relevant error message and the driver code pointed to.

Therefore Verifier should be run on any driver being stress tested, or tested with python scripts, or any other functional testing.

Verifier is very easy to set up and should be used every time a driver is tested, and developed. it is set up by running verifier.exe from a command prompt, and selecting:

...