WinDbg Reference
Free reference guide: WinDbg Reference
About WinDbg Reference
The WinDbg Command Reference is a searchable quick-reference covering the essential commands used in Microsoft WinDbg, the primary debugger for Windows kernel-mode and user-mode debugging. The reference is organized into six categories: Basic Commands (g, p, t, r, u, lm, x), Memory (db/dw/dd/dq display, da/du string display, eb/ed editing, memory search with s, and !address region info), Breakpoints (software bp, deferred bu, hardware ba, management bl/bc/bd/be, one-shot bp /1), Stack (call stack k variants, .frame switching, dv local variables, !analyze -v crash analysis), Kernel (!process, !thread, !irql, !pte), and Extensions (.load, !heap, !handle). Each entry includes the command syntax, a concise description, and practical examples showing real usage patterns.
WinDbg is indispensable for Windows driver development, crash dump analysis, and low-level security research. When a blue screen (BSOD) occurs, the !analyze -v command automatically identifies the faulting module, exception code, and call stack. Reverse engineers use the disassembly (u/uf), memory display (db/dd), and breakpoint commands to trace execution flow through user-mode applications and kernel drivers. The hardware breakpoint command (ba) enables watching specific memory addresses for read, write, or execute access without modifying code, which is critical for analyzing packed or self-modifying malware.
This reference covers both user-mode and kernel-mode debugging scenarios. The kernel section includes commands for enumerating processes (!process 0 0), inspecting thread state (!thread), checking the current IRQL (!irql), and examining page table entries (!pte). Extension commands like !heap provide heap allocation analysis for detecting memory leaks and corruption, while !handle enumerates system handles for resource leak investigation. All content is browsable in your browser with instant search filtering, dark mode support, and no server processing.
Key Features
- Complete coverage of WinDbg basic commands: g (go), p/t (step), r (registers), u (disassemble), lm (modules), x (symbol search)
- Memory commands for byte/word/dword/qword display (db/dw/dd/dq), string display (da/du), editing (eb/ed), and pattern searching (s)
- Full breakpoint reference: software (bp), deferred (bu), hardware watchpoints (ba r/w/e), management (bl/bc/bd/be), and one-shot (bp /1)
- Stack analysis commands: call stack variants (k/kn/kv/kb), frame switching (.frame), local variables (dv), and crash analysis (!analyze -v)
- Kernel debugging commands: process listing (!process), thread info (!thread), IRQL check (!irql), page table entries (!pte)
- Extension commands for heap analysis (!heap -s/-stat/-flt), handle enumeration (!handle), and module loading (.load sos/mex)
- Practical examples for each command showing real-world debugging patterns and common flag combinations
- Category-based filtering and instant search across all WinDbg commands with no server round-trips
Frequently Asked Questions
What WinDbg commands does this reference cover?
The reference covers six categories: Basic Commands (g, p, t, r, u, lm, x for execution control, registers, disassembly, modules, and symbol search), Memory (db/dw/dd/dq display, da/du strings, eb/ed editing, s searching, !address info), Breakpoints (bp software, bu deferred, ba hardware, bl/bc/bd/be management, bp /1 one-shot), Stack (k call stack, .frame, dv locals, !analyze -v), Kernel (!process, !thread, !irql, !pte), and Extensions (.load, !heap, !handle).
How do I set a hardware breakpoint in WinDbg?
Use the ba (break on access) command with the access type, size, and address. For example: ba r4 0x00403000 watches 4 bytes at that address for read access, ba w4 0x00403000 watches for write access, and ba e1 0x00401000 watches for execution. Hardware breakpoints use CPU debug registers and do not modify code memory, making them essential for debugging read-only memory or detecting self-modifying code.
What is the difference between bp and bu in WinDbg?
bp sets an immediate software breakpoint that must resolve to a valid address now. bu sets a deferred (unresolved) breakpoint that will activate when the specified module loads. Use bu when the target DLL or driver is not yet loaded — for example, bu mymodule!MyFunction will automatically set the breakpoint when mymodule.dll loads into the process. This is essential for debugging DLL initialization and driver load routines.
How do I analyze a crash dump with WinDbg?
Open the dump file (.dmp) in WinDbg and run !analyze -v. This command automatically identifies the exception code, faulting instruction, faulting module, and provides a reconstructed call stack. It also shows the bugcheck code for kernel-mode crashes (BSODs) and suggests the likely root cause. After the initial analysis, use k to examine the call stack, r to check register values, and db/dd to inspect memory around the fault address.
How do I search for a string in process memory?
Use the s (search) command with -a for ASCII or -u for Unicode: s -a 0 L?80000000 "password" searches the entire 2GB user-mode address space for the ASCII string "password". For byte patterns, use s -b: s -b 0 L?80000000 4d 5a searches for the MZ header signature. The L? prefix uses the address as a length limit rather than an end address.
What do the different k variants show in WinDbg?
The basic k command shows the call stack with return addresses and function names. kn adds frame numbers for use with .frame N. kv includes the first three function parameters and frame pointer omission (FPO) data. kb shows the first three stack parameters in hex. kP shows full parameter types and values when symbols are available. Use kn to identify a frame number, then .frame N to switch context and dv to view that frame's local variables.
Can I use this reference for kernel-mode debugging?
Yes. The Kernel category covers key kernel debugging commands: !process 0 0 lists all processes (with flags 0-7 for detail levels), !thread shows thread information including ETHREAD addresses, !irql displays the current Interrupt Request Level, and !pte examines page table entries for virtual-to-physical address translation. These commands require a kernel debugging session connected to a target machine or VM via serial, USB, or network.
Is any data sent to a server when I use this reference?
No. The entire reference dataset is embedded in the page and rendered client-side. Searching, filtering, and browsing all happen within your browser using JavaScript. No WinDbg commands, notes, or search queries are transmitted to any server.