More Driver Debugging

Attaching WinDbg to a VM to be able to get debugging output and create breakpoints is good, but if you don’t know how to use it, then its not terribly useful. However, in the cases we are working with (where we are developing and testing the code), we would have a lot more insight into what the driver is doing if we were able to follow it through the source code. And fortunately, we are able to do just that.

This is a continuation of our setup from last time when we setup our development environment. We ended with adding a breakpoint in our driverentry function, which allowed us to debug a complete system. This is important because we are basically able to single step through Windows kernel space (drivers run in kernel space). Now, lets add the ability to step through source code in our debugging process.

The compilation process is actually a process of preprocessing the C files, compiling that to assembly, assembling the files, and finally linking compiled files (to allow for importing functionality from other libraries, or separately compiled files). In that process, there is no mapping between a line of assembly and a line of C code. Depending on the level of optimization during compilation, and how efficient the C code is, there might be significant differences. However, the compiler can generate a symbol file that basically maps assembly with variable/function names. So instead of getting:

mov eax, 0x7cffffff

You might get

mov eax, systemfunction

That is only useful for a human to debug their code. Fortunately, the driver build process gives us the same thing. In the same folder where the driver file is (the .sys file), there is a symbol file (.pdb). In Windbg, File->Symbol file path points the debugger to the folder with the symbol file. To do the same with the source code, do File-> Source file path and point to the source code folder.