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


x *!

list loaded modules

bc *

clear all breakpoints

bp @@(ISXAgent!CSSOAgentDlg::OnAbout)

bp 01533c20

set breakpoint

x ISXAgent!*onabout*

list all symbols by pattern




list thread

~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

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 ssomanhost.exe c:\procdump\ssomanhost.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 gyuewin8test /u teak\administrator /p io…
taskkill.exe /pid 1234 /s gyuewin8test /u teak\administrator /p io…

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

some useful tips (mostly for myself)