DbgPrint output in Vista

I’ve been tasked with updating our kernel mode driver to build off the Server 2008 WDM and run in Vista.  Updating to the 2008 WDM was relatively painless.  There were a couple of new deprecated functions but the adjustments weren’t hard to make.  So, I set up a Vista virtual machine for debugging, attached WinDbg to it, and fired up our service.  To my dismay, none of the DbgPrint() statements that the driver outputs were being shown in WinDbg!  Without debugging output it is almost impossible to debug a device driver.  A little bit of digging online lead me to a great device driver blog: A Hole In My Head

It turns out Vista maps every call to DbgPrint() to the newer DbgPrintEx() function. 

ULONG DbgPrint( IN PCHAR Format,. . . .  [arguments]);

ULONG DbgPrintEx(
                           IN ULONG ComponentId,
                           IN ULONG Level,
                           IN PCHAR Format,
                           . . . .  [arguments]
                          );

DbgPrint is supposed to work just like the printf function except it writes to output to any debugger that is attached.  You would pass in a format string followed by a valist of arguments and it would write it out a debugger.  DbgPrintEx works to same way, but added two new arguments with the intention of filtering the system output.  The ComponentID specifies the type of driver that is writing the output.  The possible values are:

DPFLTR_IHVVIDEO_ID

DPFLTR_IHVAUDIO_ID

DPFLTR_IHVNETWORK_ID

DPFLTR_IHVSTREAMING_ID

DPFLTR_IHVBUS_ID

DPFLTR_IHVDRIVER_ID

 

The Level argument rates the messages severity on a scale of 0-31.  This way the host operating system, and ultimately the person debugging, can decide which messages it wants to see. 

Now, when Vista encounters a call to DbgPrint() it maps it to DbgPrintEx() with the DEFAULT ComponentID.  The set behavior for DEFAULT DbgPrint messages is to hide them.  There are three ways to change this.  One way is to go through your source code an change all the DbgPrints to DbgPrintExs with the ComponentID that most closely matches the device.  Unfortunately this function is only supported in XP or later, so this may not be possible for all drivers.  The other two solutions involve changing the output settings in Vista.

Attach a debugger (KD or WinDbg) and break the machine right after boot.  Enter the  command ‘ed nt!Kd_DEFAULT_MASK 0×0F’ into the debugger.  This will allow all types of DbgPrint output to be shown.  This is not a persistent solution so you will have do it every time you run the VM.

On the Vista virtual machine, open the registry and add the value “DEFAULT” : REG_DWORD : 0xFFFFFFFF to the key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter”  The next time you reboot the system it will output all of the DbgPrint output.

So that mystery is solved.  Now I just need to use my debugging output to figure out why my driver throws a kernel exception and blue screens my VM…

Updated Kernel Debugging

In my last post I explained how to set up kernel debugging with WinDbg and a Virtual PC running Windows XP.  I understand that this is a little outdated now, and there are some people that may be wondering how this can be done if the Virtual PC is running Vista.  The process is nearly identical to the one I outlined in my previous post, with the exception of step two.  In Vista, Microsoft changed the way boot options are defined and replaced the manual editing of a boot.ini file with an application called BCDEdit.exe.  This program can be invoked from the command prompt and you must use it configure your Vista boot for debugging.  Windows Hardware Developer Central has a step-by-step explanation that I am not going to try to reproduce here.  If you are interested, follow this link.

Kernel Debugging: WinDbg and Virtual PC

My new job has me doing a lot of device driver development, which naturally leads to quite a bit kernel debugging and system crashes.  Thankfully, with WinDbg and Virtual PC it is simple to set up kernel debugging for a virtual machine.  Since I am developing for a Windows environment, I am using Virtual PC 2007 and WinDbg.  This process will also work for Virtual PC 2004.  This is all probably possible with VMWare, Virtual Box, or any other virtual machine program out there, I am just not sure of the steps.  The following steps are all you need to get debugging, assuming that you have a Windows virtual machine already set up:

Step 1:  Edit the settings of you virtual machine to use a named pipe for a COM port  

Edit
Settings
COM1 
Named pipe:
Add: \\.\pipe\vpcdebug

Step 2:  Edit boot.ini file on the virtual machine.

Right-click on My Computer
Properties
Settings
Edit start-up file manually:

Add: /DEBUG /DEBUGPORT = COM1 /BAUDRATE=115200
I like to add a second line here instead. Copy the last line, and append it with the above line:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
/DEBUG /DEBUGPORT=COM1 /BAUDRATE=115200

This will give you two different boot options, one for debugging and the other for normal use.

Step 3: Set up WinDbg for remote debugging over COM1.
This can be done through the File -> Kernel Debug menu, but I prefer to make a shortcut so I can have multiple different types of debugging environments.

Create a shortcut that points to WinDbg.exe and add the the necessary command-line arguments. Your shortcut target should look something like this:
"C:\Program Files\Debugging Tools for Windows\windbg.exe" -k com:pipe,port=\\.\pipe\vpcdebug,resets=10

 This is all you need to do to set up kernel debugging.  Be sure to start the VM before WinDbg so that it has a chance to create the named pipe.  Also, make sure you download the correct symbols for your environment.  For example:

SRV*c:\websymbols* http://msdl.microsoft.com/download/symbols

Debugging Tools for Windows
Virtual PC 2007