Section 15: Debugging Drivers

The Big Picture: Being a Detective After the Crash

When a PC blue-screens, Windows leaves evidence behind: the stop code, a crash dump (a snapshot of memory at the moment of the crash), and entries in the event log. Debugging is detective work with that evidence. You ask: what was running, what did it touch, and who is the most likely culprit?

This section gives a beginner's map of the tools: WinDbg, minidump analysis, Event Viewer, simple command-line tools, and the Verifier as a stress-testing partner. You do not need to become an expert. Knowing the basic steps is enough to read a crash report and find a driver name.

15.1 WinDbg Overview

What it is: WinDbg is Microsoft's free debugger (a program for looking inside other programs, or inside Windows itself). It is the main tool for kernel and driver debugging. It is available from the Microsoft Store (called WinDbg) or as part of the Windows SDK / WDK.

What WinDbg can do:

Symbols. Compiled code is just numbers. Symbol files (.pdb) give the names of functions and variables. Microsoft provides symbols for Windows through the Microsoft Symbol Server. WinDbg downloads them as needed. You set the symbol path once to:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Kernel debugging basics. Two PCs (or one PC and a VM) are used:

 ┌──────────────────────┐   cable / network / virtual link   ┌──────────────────────┐
 │  HOST PC             │◄──────────────────────────────────►│  TARGET PC (test)    │
 │  runs WinDbg         │                                    │  runs Windows + the  │
 │  you control it here │                                    │  driver being tested │
 └──────────────────────┘                                    └──────────────────────┘

The target is paused when it hits a breakpoint or crashes, and the host examines it. This is how driver developers work. (On the target the debug setting is turned on with bcdedit /debug on; only do this on a test machine.)

A few of the most-used WinDbg commands:

15.2 Minidump Analysis Basics

What it is: A minidump is the small file Windows writes when it crashes (Section 14.2), found in C:\Windows\Minidump. Opening it in WinDbg is the beginner's path to finding a bad driver.

Step by step:

What !analyze -v shows, simplified, with a made-up example:

BUGCHECK_CODE:  d1
BUGCHECK_STR:   DRIVER_IRQL_NOT_LESS_OR_EQUAL

Arg1: ffffd0010a2b3c40   memory that was referenced
Arg2: 0000000000000002   IRQL at the time of the access
Arg3: 0000000000000000   0 = read, 1 = write
Arg4: fffff80123451234   address of the instruction that did it

MODULE_NAME:  mydriver
IMAGE_NAME:   mydriver.sys
STACK_TEXT:
  nt!KeBugCheckEx
  nt!KiBugCheckDispatch
  nt!KiPageFault
  mydriver!ProcessPacket+0x4a      <-- the failing function
  mydriver!DpcRoutine+0x31
  nt!KiRetireDpcList
  ...

How to read it:

Here, the story is: mydriver.sys, while running a DPC (IRQL 2), touched memory that wasn't available. Boom. That matches Section 14.2.

Be careful with conclusions. !analyze often names the module that was running, but memory damage caused by a different driver may be the real cause (Section 14.1). Signs that it isn't a simple driver bug: many different drivers named across different crashes, or the cause listed as memory_corruption / "pool corruption." That is when you suspect bad RAM or turn on the Verifier on a test PC.

Non-expert shortcuts. Several free third-party tools (for example BlueScreenView or WhoCrashed) read the minidumps for you and show the driver name. They are not part of Windows, so download them only from the maker's official site.

Windows' own clues, without any debugger:

Command-line tools (safe, read-only):

15.3 Driver Verifier Stress Testing

What it is: This ties together Section 14.3 and the debugger. Verifier makes a hidden bug show itself right away and clearly, so the dump points to the real culprit rather than a victim.

The typical workflow of a developer (or advanced tester) on a test machine or VM:

 1. Pick the driver to test           (verifier → Create custom settings →
                                       choose only that driver)
 2. Turn on standard checks            (special pool, IRQL, deadlock, ...)
 3. Restart the test PC
 4. Use the device hard                (copy big files, plug/unplug, sleep/wake,
                                        run the driver's tests)
 5. If a bug exists ──► blue screen with the code DRIVER_VERIFIER_DETECTED_VIOLATION
                         (stop code 0xC4), pointing exactly at the faulty driver
 6. Open the dump in WinDbg ──► !analyze -v ──► fix the bug
 7. Turn Verifier OFF  ( verifier /reset ) and restart

Typical stop codes with Verifier on: DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4), DRIVER_VERIFIER_IOMANAGER_VIOLATION (0xC9), and DRIVER_CORRUPTED_EXPOOL.

Other stress tools Microsoft provides for developers (names only): the Hardware Lab Kit (HLK) tests, Device Fundamentals tests, and Static Driver Verifier (examines the source code without running it).

Reminder (see Section 14.3): Verifier can cause boot loops. Use it only on a test machine or VM. If a PC is stuck, boot to Safe Mode or the recovery command prompt and run verifier /reset.

A beginner's debugging checklist:

1. What was the stop code and the .sys name?
2. What changed recently? (New driver, update, hardware)
3. Check Event Viewer (System log: IDs 41 and 1001; also Service Control Manager errors).
4. Check Device Manager for yellow warning icons and their Code number (Properties → General).
5. Run driverquery /v and pnputil /enum-devices /problem.
6. Update or roll back the suspect driver; re-test.
7. If the evidence is unclear, open the dump in WinDbg with !analyze -v.
8. Still random? Suspect hardware: test RAM (Windows Memory Diagnostic), check temperatures, disks.

Summary