Driver Debugging

Windows Driver Debugging - Quick Reference

Deep Knowledge: Use mcp__documentation__fetch_docs with technology: driver-debugging. Authoritative source: learn.microsoft.com/en-us/windows-hardware/drivers/debugger/.

Setup checklist (one-time per test machine pair)

1. Two machines: HOST (debugger, WinDbg) + TARGET (the machine running the driver)
2. Same OS bitness, both on the same private network (or USB 3 debug cable, or serial — Ethernet via KDNET is the modern default)
3. On TARGET, enable kernel debugging:

   bcdedit /debug on
   bcdedit /dbgsettings net hostip:<HOST_IP> port:50000 key:1.2.3.4
   bcdedit /set testsigning on        ; if loading test-signed drivers
   

   bcdedit prints the debug key — copy it to HOST.
4. Reboot TARGET — it now waits for HOST early in boot (or run live)
5. On HOST: WinDbg → File → Attach to Kernel → Net → port 50000, paste key
6. Symbols: set _NT_SYMBOL_PATH=srv*c:\symbols*https://msdl.microsoft.com/download/symbols (and add your driver's .pdb path)

Driver Verifier (use this every dev/test session)

Configure on TARGET:

verifier /standard /driver MyDriver.sys
verifier /flags 0x209BB /driver MyDriver.sys     ; common production-like set
verifier /query                                   ; show current state
verifier /reset                                   ; turn off

Standard rules catch: pool corruption, IRQL violations, low resources simulation, leaked references, deadlock detection, DMA verification.

Cost: ~10–20% perf hit, occasional artificial low-memory failures. Worth it — the bugs Verifier finds are bugs that ship.

WinDbg essentials

Bugcheck analysis flow

1. !analyze -v — get the proposed culprit, parameters, faulting stack
2. Cross-check with bugcheck reference (e.g. 0xC4 = Driver Verifier detected violation, 0x9F = power state failure, 0xD1 = DRIVER_IRQL_NOT_LESS_OR_EQUAL)
3. kP for full stack with parameters
4. !irp <faulting irp> if an IRP is involved (very common for 0xD1)
5. Inspect the suspect driver:
   • lm vm MyDriver — module info, build time
   • !for_each_module .if (...) to script
6. Reproduce with Driver Verifier if not already on — it often changes a wild crash into a precise assertion

Common bugchecks tied to driver mistakes

Live remote inspection (no break)

.reload /f                         ; refresh symbols
!process 0 17                       ; very verbose process list
!thread <tid>                       ; current thread
.dump /ma C:\target.dmp              ; full memory dump for offline analysis

Post-mortem (MEMORY.DMP)

Configure TARGET to write a kernel/full dump:

• System Properties → Advanced → Startup and Recovery → Write debugging information → Kernel memory dump (or Complete for big repros)
• After bugcheck, %SystemRoot%\MEMORY.DMP is created — open with WinDbg → Open Crash Dump

Application Verifier (UMDF)

For UMDF drivers (and the user-mode services that talk to them), use appverif.exe:

appverif /verify WUDFHost.exe                  ; full UMDF host coverage
appverif /verify mytestapp.exe /faults          ; with fault injection

Catches handle leaks, heap corruption, double-frees, lock-order issues — the user-mode equivalent of Driver Verifier.

WPP trace decoding

:: Start a session against the driver's WPP GUID
tracelog -start mytrace -guid GuidFile.txt -f trace.etl -flag 0xFFFF -level 5

:: Repro the bug

tracelog -stop mytrace

:: Decode using the .pdb of the driver (TMF embedded)
tracefmt -p C:\symbols\MyDriver.pdb trace.etl -o trace.txt

Or use traceview.exe (legacy GUI) for live decoding.

ETW (modern alternative for UMDF / general)

• Define an ETW provider with <instrumentationManifest> or TraceLoggingProvider.h
• Capture: wpr -start GeneralProfile && repro && wpr -stop trace.etl
• Open in Windows Performance Analyzer (WPA) for graphs, or tracerpt trace.etl -of XML

Anti-Patterns