WinDbg Basics Cheat Sheet

Sidebar

Operating Systems · WinDbg Basics Cheat Sheet

Opening a crash dump in WinDbg, setting symbols, and the handful of commands that answer what crashed?. None of this was run: WinDbg is not installed on the PC this was written on, and its minidumps cannot be read without administrator rights. The commands come from Microsoft Learn's WinDbg documentation (the symbol-path, !analyze and kernel-dump pages) where marked, otherwise from my own knowledge. The newer Store version of WinDbg may label menus differently from the classic one described by Microsoft.

Install and Open

winget install Microsoft.WinDbgPackage id from winget show on this PC (version 1.2610.1001.0, msix, publisher Microsoft); not installed here. Or the Microsoft Store listing

windbg -y <symbols> -z <dump>Start with a symbol path and open a dump (Microsoft)

windbg -i <imagepath>Add the executable image path; kernel and small dumps may need it (Microsoft)

File > Open crash dump (Ctrl+D)Classic UI. Dump files end .dmp or .mdmp

.opendump <file>Open a dump from the command window

Open a copyCopy the dump first (administrator PowerShell); never open or edit the original

Symbols

.symfix C:\SymbolsSet the path to Microsoft's public symbol server, with a local cache (Microsoft)

.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbolsThe explicit form (Microsoft)

.sympathShow the current path

.reload /fReload symbols for every module, forcing it

_NT_SYMBOL_PATHEnvironment variable that sets the path before WinDbg starts (Microsoft)

!sym noisyVerbose symbol loading: turn it on when symbols fail to load (Microsoft)

Third-party driversMicrosoft's server returned HTTP 404 for the Killer and NordVPN drivers on this PC: expect module names and offsets, not function names

First Commands

.bugcheckThe stop code and its four parameters. Check them against event 1001 / event 41: if they differ, wrong dump

!analyze -vMicrosoft: begin with this. Bug check, Probably caused by, failure bucket and stack

!analyze -show 13AThe debugger's own description of a bug check code and its parameters (Microsoft documents -show BugCheckCode)

lmList loaded modules (drivers) with load addresses and symbol state

lmvm <module>Detail of one module: version, company name and timestamp (from knowledge)

k / kvStack of the current thread (kv adds arguments) (from knowledge)

.lasteventWhat the debugger last saw: the exception or bug check (from knowledge)

qQuit

Looking Further (Microsoft Lists These)

!process 0 0List processes

!locksKernel resource locks

!memusagePhysical memory usage

!vmVirtual memory counters

!errlogThe WHEA/system error log in the dump

!verifierDriver Verifier statistics, if it was enabled

!heap / !pool <address>Heap and pool detail: Microsoft names !heap for bug check 0x13A. !pool is from knowledge

Reading !analyze -v

BUGCHECK_CODE / BUGCHECK_P1–P4The code and parameters; decode with Microsoft's page for that code

MODULE_NAME / IMAGE_NAMEThe module the analyzer blames: a suspect, not a verdict

FAILURE_BUCKET_IDA grouping label; useful when searching or reporting

STACK_TEXTThe call stack at the crash; heap corruption is often only noticed here, not caused here

SYMBOL_NAME / FAILURE_ID_HASHMore labels for reports and searches

DEFAULT_BUCKET_IDA coarse category (for example a driver-fault bucket)

Field names are from my knowledge of typical !analyze -v output; I have not seen output for this PC's dumps.

What a Dump Does and Does Not Prove

Stop code and parametersWhat kind of failure was detected, and where. Not whose code did it

Probably caused byA suspect. For heap corruption the code that noticed may not be the code that caused it

Module listWhat was present. Not that any of it was involved

One dumpOne data point. The same module in several dumps is far stronger

Small dumpMicrosoft: errors not directly caused by the running thread may not be discoverable. Consider a larger dump type

Sending dumpsSend the text output first; a dump itself only when asked, and privately: it can contain more than you expect

This PC's Two Bugchecks (For Checking)

101926-16187-01.dmp19 Oct 2026: 0x13A, P1 0x11, P2 0xffff840729100140, P3 0xffff8407770608e0, P4 0

102426-15109-01.dmp24 Oct 2026: 0x13A, P1 0x11, P2 0xffffb00ee3100140, P3 0xffffb00f1e44e350, P4 0

Expect from .bugcheckBugCheck 13A, {11, ffffb00ee3100140, ffffb00f1e44e350, 0} for the second dump (from the event log, not from the dump)

P1 0x11Microsoft: the heap detected invalid internal state; can be a double-free or heap corruption

Not run here

Every command on this sheet is unrun on this PC. Where a line says Microsoft it is from Microsoft Learn's WinDbg pages; otherwise it is from my own knowledge of WinDbg and may differ in the Store version.

Open a copy, keep the original

Dumps are evidence. Copy them first, record their hashes, and open only the copies.