WinDBG
The page WinDBG is a short article on something that should have a lot more information written on it.
If you know anything else about it, you are STRONGLY encouraged to add the information in. If you are unsure of proper formatting or style, add it to the talk page or this page itself as you think best and others will help.
Online reference
Useful commands
command | description |
---|---|
kp | generate a backtrace |
ta | trace to address |
x *! | full modules list (atm lm is only showing basic modules) |
!drvobj <driver_object address> 0x7 | dumps driver object details - start/unload + irp handlers |
!gflag +soe | catch all exceptions (first exception handling) apart from STATUS_PORT_DISCONNECTED or if the exception code is not an error code |
!gflag +hpa | enable page heap flag turns on page heap verification, which monitors dynamic heap memory operations |
!process 0 0 | list all process with basic info |
!process <addr> 0x1e | list detailed info of attached process, with its threads |
!process <addr> 0x1f | list stack traces for all the threads in the process |
.process <addr> | attach to the process of a given address |
!thread <addr> | list info about the thread |
.thread <addr> | attach to the thread of a given address and set the default thread context in kernel mode |
.reload /user | reloads user symbols and enables resolving of usermode |
User-mode breakpoints
With WinDbg attached as a kernel debugger, it is not trivial to set breakpoints on user-mode code. Since every process has it's own address space, the debugger does not know which process to set the breakpoint in. The .process
command does not solve this problem sufficiently (.process /i
does, but ReactOS doesn't support that yet).
A workaround is to place a kernel-mode breakpoint (those are always reliable) that is likely to be executed in the context of the right user-mode process.
As an example,
bm win32k!NtUserCreateWindowEx
will break whenever a window is created*. By executing .reload /user
after this breakpoint is hit, you will be able to look at a backtrace (that hopefully includes the right user-mode symbols) and judge whether you are in the right process at the right time. Once that is achieved, you can place user-mode breakpoints in the context of this process for further examination.
* when debugging issues during OS boot, be sure to break late enough so that win32k is loaded, though — e.g. you can be sure of this by breaking right after the display mode change that makes the desktop's background color appear.