PDB Paths and the PE Debug Directory

You might have noticed that WinDBG sometimes “knows” where to find the PDB for your driver even if you have never set your Symbol Search Path to point to your object directory. Spooky, and it certainly begs the question of how WinDBG knows where to look for your PDB.

The answer is in the debug directory of your driver’s PE image. The debug directory can contain, well, debug information, or can point off to a file containing debug information. This is how WinDBG can so easily find your PDB, by default the fully qualified path (FQP) to the PDB is found in the debug directory. If you want to see the path, you can do so with the !dh command, which will parse the PE header of the image and show you the intepreted results. Just execute !dh modulename in the debugger and scroll down to the Debug Directories section:


You can even leverage this to find information about drivers that you don’t own. I just checked the loaded module list on my current machine and had a driver loaded that I didn’t recognize: NETw4x32.sys. Doing a !dh on that module tells me that the FQP is:


So, it’s the free build of an NDIS 5.x miniport driver, which isn’t bad for information gleaned from two seconds of effort.

The problem with those FQPs is that they can contain information that you don’t want to share with the world. Build machine names, developer names, etc. may show up in the path and you might not want people outside your company to have access to that info. Luckily, there is a way to strip the path information out of your image files and that is exactly what Microsoft does with their binaries. For example, take the kernel on my system using the info from !dh nt:


The secret to making this work is the binplace tool, which exists mostly to move binary outputs of the build process to various locations. However, it has the added features of generating public PDB files as well as stripping the path infromation from your released image files.

Getting binplace integrated to your build is another post for another day, but details can be found on MSDN if you’re interested: http://msdn.microsoft.com/en-us/library/ms791453.aspx

Comments are closed.