Analyze -v

One day I wanted to demonstrate the !pte command on a page that had been paged out to a paging file. The platform in question was an XP SP3 dump and I was slightly on the spot, so I had to quickly think of a way to find a page that was actually paged out.

I immediately thought to crawl through the paged pool range in the kernel virtual address space, running !pte on each page. I could do this with something like .for or simply manually walk every 4K until I hit a paged out page.

Because I was feeling lucky (and didn’t want to look up the .for syntax), I decided to try manually walking but quickly found that tedious and I didn’t get the results that I was looking for. Everything I hit was paged in, as indicated by the valid bit being set:

So, I needed something else that might provide a quicker solution. Then I thought about paged code sections in a driver image. By default, all driver code (and data) is non-pageable. However, a driver writer is able to use a pragma directive to put code into the PAGE section of its image.

Code in the PAGE section of a driver is subject to being paged out. In addition, the memory manager pages this code to a paging file instead of retrieving it again from the image file (like in most user mode application scenarios). You can see an example of the pragma usage in the FASTFAT source from the WDK:

Being reminded of this, I decided to grab a Microsoft supplied driver and check for a PAGE section in the PE header, since MS supplied drivers often utilize this to decrease their memory footprint in the system. For no particular reason, I went with fltmgr.sys, which is the binary for Filter Manager. This did indeed reveal a code section named PAGE in the image:

This gave me a new, smaller space to search for a page paged out to a paging file. So, I gave it a shot and lucked out immediately:

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