WinDBG

From ReactOS Wiki
Revision as of 12:16, 15 September 2013 by ThFabba (talk | contribs) (Workaround for user-mode breakpoints)
Jump to: navigation, search

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.

See also