Cheat Sheet.
Windbg command line parameters:
!wow64exts.sw |
switches to 32 bit mode |
!analyze -v !analyze -hang -v |
analyze crash analyze hang |
k |
dump stack |
!gle |
get last error |
!lastevent |
get last exception event |
!ecxr |
display exception content |
.sympath [path] |
get/set symbol path |
.srcpath [path] |
get/set source path |
.reload |
reload all modules |
lm x *! |
list loaded modules |
bl |
list all breakpoints |
bc * |
clear all breakpoints |
bp @@(App!CAppDlg::OnAbout) bp 01533c20 |
set breakpoint
|
x App!*onabout* |
list all symbols by pattern |
g |
go |
p |
step over |
t |
step into |
gu |
step out |
~ |
list thread |
K |
call stack |
~0 k |
call stack for thread 0 |
r |
registers |
dt var_name |
dump variable |
dv |
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) |
!runaway |
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 sxr |
break on first chance exceptions reset all exceptions |
!locks !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 |
heap |
!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:
tcp:server=Server,port=5005
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]
"DumpCount"=dword:00000100
"DumpType"=dword:00000002
"HelpUrl"="http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx"
"DumpFolder"=hex(2):25,00,4c,00,4f,00,43,00,41,00,4c,00,41,00,50,00,50,00,44,\
00,41,00,54,00,41,00,25,00,5c,00,43,00,72,00,61,00,73,00,68,00,44,00,75,00,\
6d,00,70,00,73,00,00,00
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