All Articles

Cheat Sheet for Dump Analysis and Live Debugging with WinDbg

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

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.

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 quiet

Reference: 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 address

Reference: 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 = @ebx

Reference: 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 ; ? $p

Reference: d, da, db, dc, dd, dD, df, dp, dq, du, dw (Display Memory) - Windows drivers | Microsoft Learn

Reference: dda, ddp, ddu, dpa, dpp, dpu, dqa, dqp, dqu (Display Referenced 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.

image-20230401234723850

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 L400

Reference: 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 L0x1ce00

Reference: .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 0x1000

Reference: 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!IoCreateDevice

Incidentally, 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 3f8

Reference: 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
.bpcmds

Reference: 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!IoCreateDevice

Reference: 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
ph

Reference: 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
.logclose

Reference: 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.log

Note 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_ID

Reference: 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 0xf

Reference: handle (WinDbg) - Windows drivers | Microsoft Learn

Obtaining Thread Environment Block (TEB) Information

# Dump TEB information
!teb

Reference: teb (WinDbg) - Windows drivers | Microsoft Learn

Obtaining Process Environment Block (PEB) Information

# Dump PEB information
!peb

Extracting 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.

Reference: pstolarz/dumpext: WinDbg debugger extension library providing various tools to analyse, dump and fix (restore) Microsoft Portable Executable files for both 32 (PE) and 64-bit (PE+) platforms.

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] FileName

Other 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"

image-20230407210644712

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