Search code examples
windowsdebuggingdevice-driverkernel

DbgPrint in Memory Dump?

I have a driver that directly avoids the BSoD and turns the screen of Windows Vista into black with few colourful dots and stripes. I am finding a memory dump on the system afterwards and DbgView is wonderfully showing me a stack trace (stating that this might be a garbled stack and some parts might be incorrect). Pity is, the commands found in the stack are nowhere to be seen in the part of the code that is obviously breaking down the whole thing. (I can leave our the whole routine, but not parts of it.)

Does someone know a way to get debug messages either into the memory dump or out of the serial port to read them in an external debugger? (My testsystem stall if the debugger is connected, but this might be me not knowing enough on the how and why of remotely connected kernel debugging.)

I would like to get to know the point where my code fails, because browsing through code seems fine to me is getting a little futile and I could need a hint.

Solution

  • Description from MSDN on how to setup your debugging session.

    The setup procedure is :

    1. Setup 2 PCs, the first with your develop environment and the second which is the debug target. (Vista+Vista64 worked best for me)
    2. Setup a debugger connection by either using a Firewire cable or a Null-Modem cable. (Null-Modem works almost always, but Firewire is better from a performance standpoint. USB is expensive and didn't work out of the box for me ...)
    3. Setup the target computer to boot in 'debug' mode MSDN
    4. Having WinDbg running and waiting for a kernel connection, boot the target computer in debug mode.
    5. While boot up, WinDbg should print messages about the target system. Here you will see DbgPrint messages etc. (All DbgPrint is disabled per default in Vista (not in XP), and you must enable it link)
    6. You can set breakpoints in modules in WinDbg by defining breakpoints.

    PS: bcdedit sometimes fails to setup the debug mode. I have no clue why. But there seems a certain order in which you must tell it the debug parameters. Trying different combination's does work wonders ... .

    You can use commands in WinDbg when you break into the process. A couple of interesting ones :

    • lm displays all modules currently loaded
    • lm m pattern displays all modules satisfying the search condition (e.g. "lm m kernel32*"
    • x module_name!function_name_pattern lists the symbols in the module (e.g. "kernel32!Create*")
    • bl lists all currently set breakpoints
    • bp module_name!function_name sets a breakpoint at the start of the function specified.
    • bc * deletes all breakpoints
    • .hh bp displays the help for "bp"
    • .reload /u x.sys reloads the x.sys module debug settings. (this is helpful when you want to rebuild your project, and get a 'could not create x.pdb ...' message).

    Enable all DbgPrint output under Vista :

    enable_dbg_print_vista.reg

    Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter]
"DEFAULT"=dword:0000000f