Cheat Sheet.

Windbg command line parameters:


switches to 32 bit mode

!analyze -v

!analyze -hang -v

analyze crash

analyze hang


dump stack


get last error


get last exception event


display exception content

.sympath [path]

get/set symbol path

.srcpath [path]

get/set source path


reload all modules


x *!

list loaded modules


list all breakpoints

bc *

clear all breakpoints

bp @@(App!CAppDlg::OnAbout)

bp 01533c20

set breakpoint


x App!*onabout*

list all symbols by pattern




step over


step into


step out


list thread


call stack

~0 k

call stack for thread 0



dt var_name

dump variable


local variables

db address

dd address

display memory at location (byte+ascii)

dword (4b)

eb address new_value

ed address new_value

edit memory (byte)

dword (4b)


display information about time consumed by each thread

.server tcp:port=4015


start server for remote debugging

on remote computer choose Connect To Remote Session and use tcp:Port=4015,Server=YourHost

dbgsrv -t tcp:port=4015

start server debugger on host machine

on remote computer choose Connect To Remote Stub and use tcp:Port=4015,Server=YourHost

sxe eh


break on first chance exceptions

reset all exceptions


!locks -v

display dead locks

display all critical sections

!cs address (!critsec address)

display critical section

!cs address (!critsec address)

display critical section

!heap -s

!heap -p


!htrace -enable

!htrace -snapshot

!htrace -diff

handle leaks

Using the Command Line

As an alternative to the procedure given in the preceding section, you can set up a remote debugging session at the command line. Suppose you are set up to establish a kernel-mode debugging session, between a host computer and a target computer, over a 1394 cable on channel 32. You can use the following procedure to establish a remote debugging session:

On the host computer, enter the following command in a Command Prompt window.
windbg -server tcp:port=5005 -k 1394:channel=32

On the remote computer, enter the following command in a Command Prompt window.
windbg -remote tcp:Port=5005,Server=YourHost
where YourHostComputer is the name of your host computer, which is running the debugging server.

On the host computer:
Dbgsrv -t tcp:port=5005

On the remote computer:
Windbg -> File -> Connect to Remote Stub Server:

Create a dump file – manually

procdump.exe -ma -n 3 -s 10 notepad.exe c:\procdump\notepad.dmp

Create a dump file – automatically

Windows XP:
drwtsn32 –i
Files would be in C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson

Windows 7/8:
Files would be in C:\Users\<user name>\AppData\Local\CrashDumps

Those are the registry keys in question that “WinDbg –I” changes:

  • \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
  • \\HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]

Remote control of processes

tasklist.exe /s someComputer /u domain\administrator /p pass…
taskkill.exe /pid 1234 /s someComputer /u domain\administrator /p pass…

How to analyze high CPU usage:

1. Using Task Manager dump process in question
2. Open dump file in WinDBG
3. [Use !wow64exts.sw to switch to 32 bit mode because Task Manager makes 64 bit dumps]
4. Use !runaway to get a list of threads ordered by processor time:
0:055:x86> !runaway
User Mode Time
Thread Time
29:4b4 0 days 3:43:34.869
3:62c 0 days 0:00:00.078
12:770 0 days 0:00:00.046
5. Use k to get thread’s call stack: ~29 k

Heap corruption

heap corruption: page heap (light & full) – in Application Verifier

resource leaks:
in debugger: !htrace (enable, diff)

memory tracking: umdh, DebugDiag
in debugger: !heap

use umdh:
1. run gflags.exe
2. set symbols: _NT_SYMBOL_PATH
3. run app
4. run umdh
5. run umdh
6. run umdh for diff