This page has been machine-translated from the original page.
A cheat sheet summarizing the WinDbg commands I often use personally.
I plan to add more content in the future.
Table of Contents
- Frequently Used Links
- Adding and Loading Symbol Settings
- Module Listing, Information Retrieval (lm, x, ln)
- Register Reference and Operation (r)
- Memory Reference and Editing (dc, dps, etc..)
- Searching in Memory (s)
- Saving Memory Data as a File
- Outputting Assembly Code (u, ub, etc…)
-
- !help: Extension Help
- !analyze: Obtaining Information on Exceptions or Bug Checks
- !address: Referencing Information on Memory or Processes
- !handle: Referencing System or Process Handle Information
- Obtaining Thread Environment Block (TEB) Information
- Obtaining Process Environment Block (PEB) Information
- Extracting PE Files Using !dumpext Extension
- Using MEX
- Config Commands
- Other Commands
- JavaScript-based Debugging Scripts
-
- Setting Up Full Memory Dump Acquisition
- Enumerating Kernel Structure Information
- Enumerating Process Information
- Enumerating Thread Information
- Enumerating Process Handle Information
- Outputting Physical and Virtual Memory Information
- Aligning Context in Kernel Memory Dump
- Investigating Session ID and Processes
- Exploring System Registry Information
- Reading CPU Statistics by Referencing KPCR and KPRCB
- Investigating Pool
Preface
The content of this article is created based solely on publicly available information, published books, or results verified in my personal testing environment.
Related articles are here.
- Memo for Reading Windows Process Information with WinDbg
- Knowledge Collection for Setting Global Flags with GFlags for Detailed Debugging
Frequently Used Links
Reference: Debugging Resources - Windows drivers | Microsoft Learn
Reference: Commands - Windows drivers | Microsoft Learn
Reference: Docs Search Link
Reference: WinDBG
Reference: WinDbg Release notes - Windows drivers | Microsoft Learn
Reference: WinDbgAto_Z
Reference: CrashMe Application / Mike Dos Zhang: Search results for WinDbg
Reference: Inside Show | Microsoft Learn
Adding and Loading Symbol Settings
# Set cache and symbol store (replace)
.sympath cache*C:\Users\kash1064\Documents\symbols;srv*C:\Users\kash1064\Documents\symbols*https://msdl.microsoft.com/download/symbols
# Add symbol store setting
.sympath+ C:\Users\kash1064\Downloads
# Confirm current settings
.sympath
# Load symbol files
.reload /f HEVD.sys
.reload /f
# To confirm detailed logs when loading symbols
!sym noisy
.reload /f HEVD.sys
!sym quietReference: Configuring Symbol Paths: Windows Debugger - Windows drivers | Microsoft Learn
Reference: .sympath (Set Symbol Path) - Windows drivers | Microsoft Learn
Reference: .reload (Reload Module) - Windows drivers | Microsoft Learn
Reference: !sym (WinDbg) - Windows drivers | Microsoft Learn
Usually not necessary, but for minidumps, etc., .exepath is required to specify the executable file search path.
Reference: .exepath (Set Executable Path) - Windows drivers | Microsoft Learn
Module Listing, Information Retrieval (lm, x, ln)
# Enumerate modules
lm
# Enumerate modules starting with a
lm m a*
# Display module information, can also display timestamps, etc.
# !lmi can also be used to get detailed module information
lm Dvm <modulename>
# Resolve the address of the main function of the module from symbols
x modulename!*main*
# Enumerate function names starting with a
x /D /f modulename!a*
# Resolve symbol name from address
ln addressReference: lm (List Loaded Modules) - Windows drivers | Microsoft Learn
Reference: x (Examine Symbols) - Windows drivers | Microsoft Learn
Reference: ln (List Nearest Symbols) - Windows drivers | Microsoft Learn
Register Reference and Operation (r)
# Display list of registers
r
# Display specific registers, multiple registers
r eip
r zf
r eax,ebx,ecx,edx,ebp,eip
# Rewrite register values
r eax=00000001
r zf=0
# Display registers assigned to the second thread
# Or switch the current thread with ~1s and then output
~1 r
# Display registers associated with all threads
~* r eax
# Display xmm0 as unsigned 16-byte, xmm1 as double-precision floating-point
r xmm0:16ub, xmm1:d
# Display pseudo registers
r $peb,$teb
# Copy the value of ebx to eax
r eax = @ebxReference: r (Registers) - Windows drivers | Microsoft Learn
Memory Reference and Editing (dc, dps, etc..)
# Output Hex and ASCII in memory range or offset
dc 0x1000 0x1200
# L indicates object count
# dc @addr L1 is 1 DWORD, dq @addr L1 is 1 QWORD
dc @eip L1
dc 0x1000 L20
# Can also reference addresses or registers holding addresses
dc 0x1000
dc eax
# dps, dqs display values in pointer size and symbols if resolvable
dps rsp
dqs rsp
# Display memory in 32bit(ddp), 64bit(dqp)
ddp 0x1000
dqp 0x1000
# Display as ASCII string
da 0x1000
# Display as UNICODE string
du rsp+0x40
# Rewrite byte values
eb 0x1000
# Rewrite ASCII string
ea 0x1000 "change ascii"
# Using pseudo registers, $p holds the result of the most recent d* command
dd r11 L1 ; ? $pReference: d, da, db, dc, dd, dD, df, dp, dq, du, dw (Display Memory) - Windows drivers | Microsoft Learn
Reference: dds, dps, dqs (Display Words and Symbols) - Windows drivers | Microsoft Learn
Reference: e, ea, eb, ed, eD, ef, ep, eq, eu, ew, eza (Enter Values) - Windows drivers | Microsoft Learn
Reference: Pseudo Register Syntax - Windows drivers | Microsoft Learn
Searching in Memory (s)
Basic memory search can be achieved with the following commands.
# Search for DWORD value H in the range from RSP address to 1000000 bytes
s -d @rsp L1000000 'H'
# Search for ASCII string Hello in the range from RSP address to 10000000 bytes
s -a @rsp L10000000 "Hello"
# Search for ASCII string Hello in a wide range from 0 to 0x7fffffff
# L? specification is mandatory when searching ranges larger than 256 MB
s -a 0 L?7fffffff "Hello"
# Unicode strings can also be searched similarly
s -u @rsp L1000000 'Hello'
s -u 0 L?7fffffff "Hello"The following shows the difference between searching for ASCII strings and Unicode strings.
You can also specify specific byte patterns to search for memory information.
# Search for "ASCII strings longer than 4 characters" in the range from RSP address to 400 bytes
s -[l4]sa @rsp L400
# Search for "ASCII strings longer than 4 characters" from "writable addresses" in the range from RSP address to 400 bytes
s -[wl4]sa @rsp L400Reference: s (Search Memory) - Windows drivers | Microsoft Learn
Saving Memory Data as a File
Using the .writemem command, you can save data in a specific address range in memory to a file during debugging.
For example, you can export keys expanded in memory during program execution or decrypted execution code to a file.
# Save 0x100 bytes of memory data from address 0xb3f668 to C:\Temp\output.bin
.writemem C:\Temp\output.bin 0xb3f668 L0x100
# Save 0x1ce00 bytes of memory data from binary offset 3000 to C:\Temp\output.exe
.writemem C:\Temp\output.exe binary+3000 L0x1ce00Reference: .writemem (Write Memory to File) - Windows drivers | Microsoft Learn
Outputting Assembly Code (u, ub, etc…)
You can output the same assembly code as seen in the Disassembly window with the following commands.
# Output assembly code from EIP (ub outputs in reverse direction)
u
ub
# Output 10 lines of assembly code from specified address
u 0x1000 L10
# Can also use registers containing addresses
u eax L10
u eip L20
# Output the entire code of a specific function from function address or symbol name
uf 0x1000
uf module!function
# Extract only call instructions in the target routine
uf /c 0x1000Reference: u, ub, uu (Unassemble) - Windows drivers | Microsoft Learn
Reference: uf (Unassemble Function) - Windows drivers | Microsoft Learn
Outputting Variables and Structures (dv, dt)
Commands to obtain variable or structure information.
Especially, using dt to obtain kernel structure information is very common.
# Output local variables in current scope (/t displays type names)
dv
dv /t
# Variable type names can also be resolved with dt command
dt local_val_name
# Resolve structures from symbol names or addresses
dt MyStruct
# To enumerate substructures recursively, use -r or -b
dt -r MyStruct
# You can specify the hierarchy of structures to display recursively with -r1 -r2, etc.
dt -r2 MyStruct
# Can enumerate type information of kernel structures
dt nt!_*
dt nt!*PEB*
# To get actual values, specify the address of the structure
dt nt!_EPROCESS <EPROCESS address>
# Can extract only specific values by specifying subtype names
dt nt!_EPROCESS ImageFileName <EPROCESS address>
# -l option traverses linked lists to dump structure information
# -y option outputs lines that start with the specified string
# -o option hides offsets
# -i option does not indent subtypes
dt nt!_EPROCESS -l ActiveProcessLinks.Flink -y Ima -yoi Uni <EPROCESS address>
# dt cannot get substructure information, so use -r or -b switch
dt ntdll!_EPROCESS -r <EPROCESS address>
dt ntdll!_EPROCESS -b <EPROCESS address>Reference: dv (Display Local Variables) - Windows drivers | Microsoft Learn
Reference: dt (Display Type) - Windows drivers | Microsoft Learn
Reference: Inside Windows 7th Edition Upper P.44
When the structure to be analyzed contains bidirectional lists, the dt command can recursively obtain information linked in the list. (Enumerating _EPROCESS structures during kernel debugging, etc.)
Also, the dv command does not work effectively in 64-bit calling conventions or Fast calling convention (calling conventions that pass arguments as much as possible via registers).
For example, the __cdecl calling convention commonly used in x86 Windows stably passes all arguments via stack, so local arguments can be referenced stably with dv command.
Reference: 抄訳メモ/Calling Conventions Demystified - Glamenv-Septzen.net
Referencing PE Binary Information
# Reference table information
!dh -f !<module_name>
# Enumerate import table information from identified address and size
dps !<module_name>+<IAT address> !<module_name>+<IAT address>+<IAT size>
# Enumerate DOS header
dt /r _IMAGE_DOS_HEADER @@masm(!<module_name>)
# Enumerate NT header (FileHeader / OptionalHeader)
# e_lfanew is obtained from the PE header pointer at 0x3C of DOS header
dt /r _IMAGE_NT_HEADERS64 @@masm(!<module_name>+<e_lfanew value>)
# Get the first SectionHeader by adding the size of NT header FileHeader to the address where SizeOfOptionalHeader value is added
dt /r _IMAGE_SECTION_HEADER @@masm(!<module_name>+0xF8+0x018+<SizeOfOptionalHeader>)
# By adding the size of _IMAGE_SECTION_HEADER which is 0x28, you can refer to the information of the next section (need to load structure symbols in advance)
dt /r _IMAGE_SECTION_HEADER @@masm(!<module_name>+0xF8+0x018+<<SizeOfOptionalHeader>+0x28>)Setting Breakpoints (bp, bu, bm)
Breakpoints can be set using three commands: bp, bu, bm.
bp is for normal breakpoint setting, setting breakpoints at symbols or addresses specified in the command.
On the other hand, for unresolved addresses or addresses that cannot be resolved with bp, use bu to set breakpoints.
※ Using bu command allows setting breakpoints on system drivers loaded later during kernel debugging, for example.
Furthermore, using bm command allows setting breakpoints on symbols using patterns.
# Set breakpoint at offset
bp module+0x123
bu dllmodule!DLLMain
# Set breakpoints collectively on multiple modules starting with mem
bm myprogram!mem*When setting breakpoints, you can also specify the processing when the breakpoint matches, or the number of times the relevant code is called before stopping execution.
Additionally, you can finely condition the behavior at break time by defining conditional branching such as IF statements.
Operators that can be used in conditional expressions include MASM Numbers and Operators, etc.
Conditional branching is defined with .if or j commands, but this notation is now recommended to use the notation bp /w "(Condition)" Address as per Conditional breakpoints in WinDbg.
# Stop execution on the 7th time the processing set with breakpoint is called
bp MyTest+0xb 7
# After matching the breakpoint, output EAX and variable MyVar, then automatically resume execution
bp ntdll!RtlRaiseException "r eax; dt MyVar; gc"
# Output arbitrary string with echo and continue processing
bp module!myFunction ".echo myFunction executed; gc"
# Basic syntax of IF conditional expression
bp module!myFunction ".if () {} .else {}"
# Dereference var address with poi, compare with decimal 10
# If matches, do nothing and break; if not, continue processing
bp module!myFunction ".if ( poi(var) == 0n10 ) {} .else { gc }"
# The following achieves the same result
bp module!myFunction "j ( poi(var) == 0n10 ) ''; 'gc'"
# Clear all breakpoints
bc *
# Set one-shot breakpoint with /1 (breaks only once)
bp /1 nt!IoCreateDeviceIncidentally, the gc command instructs to move from conditional breakpoints, and when included in the command at break time, it specifies to proceed with the same method as the execution command (g or F10, etc.) when reaching this breakpoint.
Reference: bp, bu, bm (Set Breakpoint) - Windows drivers | Microsoft Learn
Reference: gc (Go from Conditional Breakpoint) - Windows drivers | Microsoft Learn
Reference: j (Execute If - Else) - Windows drivers | Microsoft Learn
Reference: Conditional breakpoints in WinDbg and other Windows debuggers - Windows drivers | Microsoft Learn
Conditional breakpoints can also be controlled using script files.
See Using Script Files for details.
Monitoring Read and Write Access (ba)
Using the ba command, you can set breakpoints when access occurs to specific memory areas, not just execution code.
The specifiable values are mainly “execute (e)”, “read/write (r)”, “write (w)“.
Additionally, limited to kernel debugging, you can configure breakpoints when I/O occurs on specific I/O ports with the “I/O (i)” option.
# Break when read access occurs on 4-byte area from variable name or variable address
ba r4 myVar
ba r4 0x1000
# Break when write access occurs on target
ba w4 0x1000
# Break when I/O occurs on ports from 3f8 to 3f8+4 (kernel debugging only)
ba i4 3f8Reference: ba (Break on Access) - Windows drivers | Microsoft Learn
Managing Breakpoint Settings (bl, bd, etc…)
You can confirm, enable/disable current breakpoint settings with the following commands.
# Enumerate currently set breakpoints
# The breakpoint ID displayed here can be used to specify targets in other management commands
bl
# Disable all breakpoints
bd *
# Disable only breakpoint with ID 1
bd 1
# Enable all breakpoints
be *
# Enable only breakpoint with ID 1
be 1
# List the commands used for current breakpoint settings in order from top
.bpcmdsReference: bl (Breakpoint List) - Windows drivers | Microsoft Learn
Reference: be (Breakpoint Enable) - Windows drivers | Microsoft Learn
Reference: bd (Breakpoint Disable) - Windows drivers | Microsoft Learn
You can also update current breakpoint settings or conditions with the following commands.
# Change breakpoint ID
# Can also batch change multiple IDs
br OldID NewID
br OldID NewID OldID2 NewID2 OldID3 NewID3
# Can modify the command part of the breakpoint
bs ID ["CommandString"]
# Can change breakpoint condition statements
bsc ID Condition ["CommandString"] Reference: br (Breakpoint Renumber) - Windows drivers | Microsoft Learn
Reference: bs (Update Breakpoint Command) - Windows drivers | Microsoft Learn
Reference: bsc (Update Conditional Breakpoint) - Windows drivers | Microsoft Learn
Breaking When Loading DLLs or Kernel Drivers
# Break when loading HEVD.sys driver
sxe ld HEVD.sys
# Set one-shot breakpoint on nt!IoCreateDevice after load break
bp /1 nt!IoCreateDeviceReference: sx, sxd, sxe, sxi, sxn, sxr, sx- (Set Exceptions) - Windows drivers | Microsoft Learn
Code Execution Commands
In WinDbg, code execution can be performed in three main operations.
- Step: Execute a single instruction or code (Step Over)
- Trace: Execute a single instruction or source line (Step Into)
- Go: Resume execution of process or thread
Step Over (p)
Execute a single instruction or code with p command or F10 key.
In WinDbg, the operation executed with p command or F10 key corresponds to Step Over, and in call instructions, it does not move to the called function, but proceeds to the next line of the call instruction.
By default, registers and flags are output when Step Over, but you can disable the output of registers and flags by adding r like pr, or by executing .prompt_allow -reg command. (Execute .prompt_allow +reg to restore)
# Perform step over operation
p (or F10)
# Execute 5 lines of step over
p 5
# Execute WinDbg command after step over
p "k;r eax"
# Repeat Step Over until reaching specified address
pa StopAddress
# Step Over until next call instruction line
pc
# pc can also execute count
pc 3
# Step Over until next ret instruction line
pt
# Step Over until next call or ret instruction line
pct
# Step Over until next branching instruction
phReference: p (Step) - Windows drivers | Microsoft Learn
Reference: pa (Step to Address) - Windows drivers | Microsoft Learn
Reference: pc (Step to Next Call) - Windows drivers | Microsoft Learn
Reference: pt (Step to Next Return) - Windows drivers | Microsoft Learn
Reference: pct (Step to Next Call or Return) - Windows drivers | Microsoft Learn
Reference: ph (Step to Next Branching Instruction) - Windows drivers | Microsoft Learn
Step Into (t)
TODO: To be added
Reference: t (Trace) - Windows drivers | Microsoft Learn
go (g)
TODO: To be added
Reference: g (Go) - Windows drivers | Microsoft Learn
Saving Command Output to a File
Using the .logopen command, you can save WinDbg command executions and their output results to an arbitrary file.
By default, the output text is ASCII strings, but you can specify Unicode strings with the /u option.
Especially useful when outputting a large amount of information like the process command at once.
# Record command output in arbitrary log file (ASCII text)
.logopen C:\Users\Public\windbg.log
# Record in arbitrary log file with process ID and current date/time (/t)
.logopen /t C:\Users\Public\windbg.log
# Automatically determine file name from process or file information and save
.logopen /d
# Append to existing log file
.logappend C:\Users\Public\windbg.log
# Close and end recording
.logcloseReference: Keeping a Log File in WinDbg - Windows drivers | Microsoft Learn
Reference: .logopen (Open Log File) - Windows drivers | Microsoft Learn
Reference: .logappend (Append Log File) - Windows drivers | Microsoft Learn
Reference: .logclose (Close Log File) - Windows drivers | Microsoft Learn
Saving Output to a File Using Command Line Options
Using the -logo FilePath option to launch WinDbg saves all command window outputs to the specified file.
This can also be used when specifying the Debugger flag of the application to the WinDbg path.
Also, you can specify the -logo option when launching WinDbg by editing the shortcut.
For example, setting the following command line in the shortcut will always save output results to C:\Users\Public\debug.log.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe -logo C:\Users\Public\debug.logNote that when using the -logo option as in the example above, the file is overwritten each time WinDbg is launched.
Extensions
Loaded extensions can be confirmed with .chain.
Default extensions are of the following types, each loaded as DLL.
- ext
- wow64exts
- dbghelp
- exts
- uext
- ntsdexts
!help: Extension Help
The !help extension outputs the command list of ext extension by default.
However, the help extension exists in several other extensions as well, and you can access the command lists of each extension with notations like !ext.help or !wow64exts.help.
# Output ext extension help
!ext.help
analyze [-v][level] - Analyzes current exception or bugcheck (levels are 0..9)
owner [symbol!module] - Displays the Owner for current exception or bugcheck
comment - Displays the Dump's Comment(s)
error [errorcode] - Displays Win32 or NTSTATUS error string
gle [-all] - Displays the Last Error & Last Status of the current thread
address [address] - Displays the address space layout
[-UsageType] - Displays the address space regions of the given type
cpuid [processor] - Displays the CPU information for a specific or all CPUs
exchain - Displays exception chain for the current thread
for_each_process <cmd> - Executes command for each process
for_each_thread <cmd> - Executes command for each thread
for_each_frame <cmd> - Executes command for each frame in the current thread
for_each_local <cmd> $$<n> - Executes command for each local variable in the current frame,
substituting the fixed-name alias $u<n> for each occurrence of $$<n>
imggp <imagebase> - Displays GP directory entry for 64-bit image
imgreloc <imagebase> - Relocates modules for an image
str <address> - Displays ANSI_STRING or OEM_STRING
ustr <address> - Displays UNICODE_STRING
list [-? | parameters] - Displays lists
cppexr <exraddress> - Displays a C++ EXCEPTION_RECORD
obja <address> - Displays OBJECT_ATTRIBUTES[32|64]
rtlavl <address> - Displays RTL_AVL_TABLE
std_map <address> - Displays a std::map<>!analyze: Obtaining Information on Exceptions or Bug Checks
!analyze is a command in ext extension, very useful for crash dump analysis, etc.
It includes the output results of the .ecxr command that displays the Register Context linked to the occurred exception. (.exr -1 displays information on the latest exception that occurred in the system.)
For system dumps, you can also refer to information on the cause of system crash with the .bugcheck command.
# Perform main analysis
!analyze -v
# Global flags
NTGLOBALFLAG
# Information recorded for processes or applications
PROCESS_BAM_CURRENT_THROTTLED
PROCESS_BAM_PREVIOUS_THROTTLED
APPLICATION_VERIFIER_FLAGS
# EXCEPTION_RECORD records information on the process that caused the exception and crash
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ffce5c60910 (ntdll!LdrpDoDebuggerBreak+0x0000000000000030)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
# Stack callback at exception occurrence is recorded
# ~0s ; .cxr ; kb can output the same content
STACK_TEXT
# Display failure category
FAILURE_BUCKET_IDReference: WinDBG !analyze extension command
Reference: analyze (WinDbg) - Windows drivers | Microsoft Learn
Reference: Magical WinDbg VOL.1【4章 アプリケーションのクラッシュダンプを解析する】 - !analyze 拡張機能でクラッシュダンプを分析する
Reference: Magical WinDbg VOL.1【5章 システムクラッシュ時のフルメモリダンプを解析する】 - !analyze 拡張機能でクラッシュダンプを分析する
!address: Referencing Information on Memory or Processes
!address is also a command in ext extension, to display information on the memory area or process of the specified address.
For example, issuing the !address command on the return value address of the malloc function, etc., allows obtaining information on the target memory area.
# Output information on each memory block
!address
# Output information on specified address
!address <Address>
# Output statistical information on memory in user mode debugging
!address -summary As per the parameter table in the following Docs, you can obtain various information such as the usage, status, and protection status of the target memory area.
Reference: address (WinDbg) - Windows drivers | Microsoft Learn
!handle: Referencing System or Process Handle Information
!handle is also a command in ext extension, to obtain information on system or process handles.
When used in user mode debugging, you can obtain a list of handle information of that process or statistical information.
The information obtainable with the !handle command without options is very similar to the handle view in Process Explorer.
# Obtain handle information
!handle
# Dump detailed information on all handles
!handle 0 0xf
# Obtain detailed information on handle with handle ID 430
!handle 430 0xfReference: handle (WinDbg) - Windows drivers | Microsoft Learn
Obtaining Thread Environment Block (TEB) Information
# Dump TEB information
!tebReference: teb (WinDbg) - Windows drivers | Microsoft Learn
Obtaining Process Environment Block (PEB) Information
# Dump PEB information
!pebExtracting PE Files Using !dumpext Extension
Using the open-source !dumpext extension, you can easily dump PE header information or extract PE binaries from dump files.
Build the extension in advance following the steps in the following Github repository.
Then, you can export PE binaries from dump files as follows.
# Download pre-built binary from https://kashiwaba-yuki.com/file/dumpext.dll.
.load C:\Users\User\Downloads\dumpext.dll
# Export PE binary from process dump to "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64" as dump.out
!dumpext.dump_pe !<module_name>Reference: peb (WinDbg) - Windows drivers | Microsoft Learn
Using MEX
Reference: Magical WinDbg VOL.1【付録 A WinDbg の Tips】
Config Commands
# Confirm symbol settings
.sympath
# Set symbol cache and source
.sympath cache*C:\symbols;srv*https://msdl.microsoft.com/download/symbols
.reload
# Output/suppress details when loading symbols
!sym noisy
!sym quiet
# Force loading of mismatched symbols (not recommended)
.reload /f /i <modulename>
# Output list of loaded extensions
.chain
# Load additional extensions
.load <Extension DLL path>
# Display extension details
.extmatch /D /e <Module> *
# Launch help window
.hh
# Save as dump file
# https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/-dump--create-dump-file-
.dump [options] FileNameOther Commands
# ?<Hex> allows decimal conversion
?ff
> Evaluate expression: 255 = 000000ff
# Display status of current process in user mode debugging
|
# Display debugging system
||Reference: Commands - Windows drivers | Microsoft Learn
Using Script Files
By using text files containing WinDbg commands, you can automate WinDbg command execution to some extent.
# Execute script defined in file
$<C:\windbgcmd.txt
# Execute as single command block (better for using breakpoints)
$><C:\windbgcmd.txt
# Set command arguments (not standard input)
# Can be used when using commands like .echo argument is ${$arg1}
$$>a<C:\windbgcmd.txt test_text
# Recursively call the script eaxstep that continues execution until 1234 is contained in eax register
# .if (@eax == 1234) { .echo 1234 } .else { t "$<eaxstep" }
t "$<C:\\eaxstep"Reference: , , $$ a (Run Script File) - Windows drivers | Microsoft Learn
Reference: Executing Until a Specified State is Reached - Windows drivers | Microsoft Learn
Conditional Branching
WinDbg commands or script internals can handle conditional expressions like the following.
# Using IF token
.if (Condition) { Commands }
.if (Condition) { Commands } .else { Commands }
.if (Condition) { Commands } .elsif (Condition) { Commands }
.if (Condition) { Commands } .elsif (Condition) { Commands } .else { Commands }Reference: .if (WinDbg) - Windows drivers | Microsoft Learn
Reference: Control Flow Tokens - Windows drivers | Microsoft Learn
In this case, various limits can be included in Condition.
In WinDbg, MASM operators and C++ operators are supported.
Especially, address resolution with poi of MASM operators and non-numeric operators like $scmp("String1", "String2") for string comparison are frequently used.
# $scmp performs evaluation equivalent to C++ strcmp, returns 0 when strings match
.if ($scmp("${$ImageName}","notepad.exe")) { } .else { .echo match }Loop Commands
TODO: To be added
Creating Blocks
TODO: To be added
Creating and Deleting Aliases
TODO: To be added
Using Pseudo Registers
TODO: To be added
Sample: Enumerating Processes and Obtaining File Names
TODO: To be added
Sample: One-liner to Rewrite ZF While Continuing Loop Processing
TODO: To be added
JavaScript-based Debugging Scripts
TODO: To be added
User Mode Process Analysis
User Mode Threads
TODO: To be added
User Mode Processes
TODO: To be added
Displaying Stack Backtrace and Frames
TODO: To be added
Investigating User Mode Heaps
TODO: To be added
Kernel Mode Dump Analysis
Setting Up Full Memory Dump Acquisition
TODO: To be added
Enumerating Kernel Structure Information
TODO: To be added
Enumerating Process Information
TODO: To be added
Enumerating Thread Information
TODO: To be added
Enumerating Process Handle Information
TODO: To be added
Outputting Physical and Virtual Memory Information
TODO: To be added
Aligning Context in Kernel Memory Dump
TODO: To be added
Investigating Session ID and Processes
TODO: To be added
Exploring System Registry Information
TODO: To be added
Reading CPU Statistics by Referencing KPCR and KPRCB
TODO: To be added
Investigating Pool
TODO: To be added
Remote Debugging
Debugging a Process in a Virtual Machine from the Client-side WinDbg
TODO: To be added
Live Debugging
Connecting Kernel Debugger (Hyper-V, VirtualBox)
TODO: To be added
Setting Debugger Operations for Exceptions or Specific Events
TODO: To be added
Filter Driver Investigation
Commands of fltkd Extension
TODO: To be added
Knowledge Required for Analysis
Understanding 32-bit and 64-bit Calling Conventions
TODO: To be added
NTGLOBALFLAG
TODO: To be added
EXCEPTION_RECORD
TODO: To be added
EPROCESS, ETHREAD
TODO: To be added
Guard page
TODO: To be added
sysenter instruction
TODO: To be added
Common Exceptions
Access Violation Exception
TODO: To be added
Environment Settings
Changing Visual Studio Linker Settings
TODO: To be added
Disabling Optimization in Release Builds
TODO: To be added
WinDbg Troubleshooting
When “NT symbols are incorrect, please fix symbols” Error is Output
TODO: To be added
Other Tips
Which WinDbg(X86) and WinDbg(X64) Should Be Used?
TODO: To be added
Using Dark Theme in WinDbg(Classic)
TODO: To be added