Not all Blue Screens of Death are easy to debug! Sometimes, you need to enable extra checking to help catch a buggy device driver. In this episode of Defrag Tools, Chad Beeder and Larry Larsen discuss using Driver Verifier in conjunction with WinDbg to track down a driver which is corrupting kernel mode pool memory.
Debugger commands used:
- !analyze -v
Make sure you watch Defrag Tools Episode #1 for instructions on how to get the Debugging Tools for Windows and how to set the required environment variables for symbols and source code resolution.
Windows Internals book tools (including NotMyFault)
Forcing a System Crash from the Keyboard
How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system
Driver Verifier Options
[00:09] - What is Driver Verifier?
[01:54] - Using NotMyFault to cause a buffer overflow
[06:04] - Looking at a buffer overflow dump in WinDbg
[08:10] - What is the .trap command? (see: x64 Register Usage)
[12:45] - First dump was inconclusive. Looking at a second buffer overflow dump.
[15:47] - Memory is corrupted, but how to find out who is corrupting it? Driver Verifier!
[16:55] - Launching and configuring Driver Verifier
[20:20] - Verifier enabled, let's crash the system!
[21:25] - What is special pool?
[22:27] - Looking at the memory dump (captured with Verifier enabled)
[25:13] - Forcing a memory dump of a hung system via keyboard
[28:00] - Forcing a memory dump of a hung system via NMI switch
[31:52] - Advanced/custom Driver Verifier settings