Loading your driver in user mode

One of the very cool features of windbg/kd is that you can load any PE file as a dump file.  That means that you can load an exe, dll, or sys file as a dump file in the debugger.  Your driver won't run ;), but you can look at alot of things in it.  All you have to do is use the -z cmd line flag and specify the binary.  For instance,

c:\Debuggers\windbg.exe -z d:\winddk\3790.1830\src\general\toaster\func\featured1\objchk\i386\toaster.sys

will start windbg and bring up the entry point for the file.

Executable search path is:
ModLoad: 00010000 0001c000   d:\winddk\3790.1830\src\general\toaster\func\featured1\objchk\i386\toaster.sys
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=0001911e esp=00000000 ebp=00000000 iopl=0         nv up di pl nz na pe nc
cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000
0001911e 8bff             mov     edi,edi

So, great.  What can you do with a driver loaded in the debugger?  While no code executes, you can enumerate symbols, dump type information, and unassemble functions.  You can do a number of useful things with this information. 

One of things I did for KMDF v1.0 was to remove as much compiler added structure padding as possible by rearranging structure fields.  Instead of making a change and then going through the process of copying the binary over to my test machine, unloading my test driver, reloading it, and then breaking into the live kernel session to dump the type, all I had to do was load the image locally in the debugger and inspect the type.

Another useful thing you can do is unassemble a function and see what the compiler generated without generating a cod file.  This is a powerful option because if you forget to generate the cod file or lost the original compiler settings, generating this information after the fact can be a pain.  Another use of the assembly as it exists in the file is to compare it against the loaded assembly that is running on your debug target.  By comparing the 2, you can sometimes detect memory corruption and other issues that are hard to debug.  (You can also use the !chkimg command to validate a driver loaded on a running OS with the original image.)

Comments (6)

  1. strik says:

    You can use this feature to disassemble a driver for a machine you do not currently have, too. For example, you can unassemble an AMD64 or iA64 driver on a i386 machine.

  2. Alex Ionescu says:

    Another perhaps not-well known feature is that you can also load PDBs directly by using:

    .reload c:foobar.pdb=0xYYYYYYYY

    where YYYYYYYYY is some valid memory address where to load the PDB. Then you can dump the information from it.

    (This is useful in the case where you have a PDB but not the actual PE file to load with -Z)

    Best regards,

    Alex Ionescu

  3. Alex, that is a bit sneaky.  Didn’t know about that.  Internally we have tool which can dump a PDB on the cmd line, so I have always used that.

  4. Alex Ionescu says:

    Doron, is that like dia2dump (an MS tool in the DIA symbol source code which is a PDB dumpber) or does it actually dump symbol data as C code?

  5. Jabeen says:

    Hi Doron,

    Through your kind guidence

    I have installed WinXP SP2 as VM ware and configured the serial port as


    now when i run the command

    windbg -k com:port=\.pipeCOM1,pipe

    WinDBG opens the COM1 port but next to it, it says Waiting to reconnect

    how can i debug the sys file?

    Can you kindly guide me through steps

    I will be really really thankful to you.



Skip to main content