Share via

Loading your driver in user mode

  • Article

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
toaster!GsDriverEntry:
0001911e 8bff mov edi,edi
0:000>

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

  • Anonymous
    March 10, 2006
    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.
  • Anonymous
    March 13, 2006
    The comment has been removed
  • Anonymous
    March 15, 2006
    The comment has been removed
  • Anonymous
    March 16, 2006
    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?
  • Anonymous
    March 20, 2007
    The comment has been removed
  • Anonymous
    April 25, 2007
    PingBack from http://www.deez.info/sengelha/blog/2007/04/25/understanding-the-windows-crash-dialog-part-1-the-null-pointer-dereference/