MF0.6 WinDbg and the Kernel Debugger Perspective

WinDbg is a debugger, not a memory forensics tool. It was designed for live kernel debugging — attaching to a running Windows system over a serial cable, USB, or network, pausing execution, examining state, resuming. Memory forensics practitioners use it in a different mode: post-mortem analysis of a crash dump or memory image, examining the recorded state without any debugged system attached. In this mode, WinDbg is slower, less automated, and less forensically structured than Volatility 3 — which is why it's not the primary memory forensics tool. But it has access to something Volatility 3 doesn't: Microsoft's authoritative kernel structure definitions, loaded symbols from the public symbol server, and the debugger's own structure-dumping commands that work on every Windows version Microsoft has ever shipped.

For most memory forensics questions, that matters less than you'd think. Volatility 3 uses the same Microsoft symbols — when it parses an EPROCESS, it's using the same structure definition WinDbg would show. The difference is that Volatility 3 presents the parsed result as structured plugin output, while WinDbg shows you the raw structure at the debugger level. Most of the time, the Volatility 3 presentation is what you want: it's easier to read, it fits into the documentation workflow, and it covers 80% of investigation questions. WinDbg is for the 20% where you need to look at the structure itself rather than a plugin's view of it.

WinDbg's role — validation, not primary analysis

Three categories of memory forensics question make WinDbg the correct tool. The first is structure validation — the investigator has a Volatility 3 finding that will form a decisive claim in the case report, and wants to confirm the underlying structure by examining it at the debugger level. The use pattern is "I found X with Volatility 3; I validated X with WinDbg; the finding is supported by both methods." Under expert testimony, the ability to say "I did not rely solely on the plugin's interpretation; I examined the EPROCESS structure myself using the Microsoft kernel debugger and confirmed the field values" produces a stronger methodology defence than "I ran the plugin and trusted its output."

The second category is rootkit analysis — specifically, rootkits that manipulate the structures Volatility 3 reads. A rootkit that unlinks its process from the active process list might still be visible in the pool allocator; Volatility 3's windows.psscan catches this class. But a more sophisticated rootkit that also manipulates pool headers, unlinks driver objects, or hooks the kernel callback chains in ways that Volatility 3's plugins don't check may be invisible to plugin-based analysis. At that point, the investigator reaches for WinDbg's structural commands to walk the kernel manually — !poolfind, !process 0 7, !callbacks, u on suspicious function pointers — and finds what the plugin missed. This is covered in depth in MF6 and MF8; for MF0, the key point is that WinDbg is the fallback when a rootkit is suspected.

The third category is structure reverse-engineering — the investigator encounters a memory artefact that doesn't match any known structure, or a novel malware technique that manipulates kernel objects in ways current plugins don't detect. WinDbg's dt command dumps any structure Microsoft has published symbols for, with all fields and types; dt -r recursively dumps nested structures. For a novel technique, the investigator uses dt to understand the structure, confirms their understanding against test cases, and writes the documentation that informs the next Volatility plugin (or their own custom analysis).

Outside these three categories, Volatility 3 is the better tool. If the question is "enumerate the processes," use vol ... windows.pslist. If the question is "extract injected code," use vol ... windows.malfind. If the question is "what's this image's network connections," use vol ... windows.netscan. WinDbg can answer these questions but more slowly and with less structured output. The decision is not "WinDbg or Volatility 3" as if they compete — it's "Volatility 3 for most questions, WinDbg for the three categories above."

Loading a memory image in WinDbg

WinDbg treats a memory image as a crash dump file, even if no crash occurred. The practitioner opens the image via File → Open Crash Dump (or the command-line equivalent windbg -z NE-FIN-014-mem.raw). WinDbg then attempts to identify the OS version and kernel build, and loads symbols from the configured symbol path.

Symbol configuration is a one-time setup. The standard symbol path points to Microsoft's public symbol server with a local cache: SRVC:\Symbolshttps://msdl.microsoft.com/download/symbols. This tells WinDbg to download missing symbols from Microsoft's server and cache them locally. Setting this is File → Symbol File Path in the GUI or .sympath SRVC:\Symbolshttps://msdl.microsoft.com/download/symbols at the command line. After setting it, .reload /f forces symbol resolution for the loaded dump. Without symbols, most WinDbg commands produce unusable output (raw addresses without structure interpretation); with symbols, the commands show field names, function names, and typed values.

Once the image is loaded and symbols resolved, WinDbg presents a command-line interface. Commands fall into three categories: built-in commands (starting with .), meta-commands (starting with !), and expression evaluation. Built-in commands control the debugger itself — .reload, .sympath, .help. Meta-commands run predefined analysis sequences — !process, !pool, !poolfind, !callbacks, !for_each_process. Expression commands evaluate addresses, structures, and memory reads — dt, db, u, ?. For memory forensics, meta-commands and expression commands do most of the work.

The minimum command set

Six commands cover 90% of what memory forensics practitioners need from WinDbg. Each has a dedicated purpose and a standard invocation.

!process 0 0 — lists all processes in the image. The two zeros mean "all processes" and "minimum detail." Roughly equivalent to Volatility 3's windows.pslist. Produces a walkable reference with EPROCESS address, PID, image name, and parent PID.

!process

0: kd> !process 0 0 powershell.exe
PROCESS ffff8e03a7c42080
    SessionId: 1  Cid: 1308    Peb: 7ffda4230000  ParentCid: 107a
    DirBase: 1ad842001  ObjectTable: ffff9a0287e5c5c0  HandleCount: 412.
    Image: powershell.exe

PROCESS ffff8e03b24f3100
    SessionId: 1  Cid: 1308    Peb: 7ffdb0f20000  ParentCid: 1076
    DirBase: 14ae29001  ObjectTable: ffff9a0288a21600  HandleCount: 527.
    Image: powershell.exe

EPROCESS Address    PID (Cid)    Parent PID    Image           Match?
ffff8e03a7c42080    0x1308 4872  0x107a 4218   powershell.exe  Yes — PID 4872, WINWORD parent 4218
ffff8e03b24f3100    0x1308 4872  0x1076 4214   powershell.exe  No  — different parent, likely unrelated

0: kd> dt nt!_EPROCESS ffff8e03a7c42080 UniqueProcessId ImageFileName VadRoot CreateTime
   +0x440 UniqueProcessId  : 0x00000000`00001308 Void
   +0x5a8 ImageFileName    : [15]  "powershell.exe"
   +0x7d8 VadRoot          : _RTL_AVL_TREE
   +0x2d0 CreateTime       : _LARGE_INTEGER 0x01DC4F7E`C3A71B40

Field             Offset    Value                              Volatility 3 agreement?
UniqueProcessId   +0x440    0x1308 (4872)                      Matches plugin output
ImageFileName     +0x5a8    "powershell.exe"                   Matches plugin output
VadRoot           +0x7d8    _RTL_AVL_TREE (AVL tree of VADs)   Root for VAD walk that malfind performed
CreateTime        +0x2d0    2026-03-15 08:42:47 UTC (decoded)  Matches plugin output exactly