Reading width
Wide uses the full column for everything — text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
WinDbg for Memory Forensics: Validation and Kernel Analysis
The tool for when the first three are not enough
WinDbg is Microsoft's kernel debugger. It is not a memory forensics tool, and most of the time you will not need it. It is the tool you reach for when Volatility 3 and MemProcFS cannot fully answer the question: when a kernel structure has to be examined at the debugger level, when a rootkit is manipulating the very structures Volatility reads, when a novel technique needs reverse-engineering, or when testimony requires showing the raw kernel object rather than a plugin's interpretation of it.
Most practitioners never learn WinDbg for forensics, because institutional training files it under "kernel development", something driver authors use, not something a DFIR analyst needs. That leaves a gap: the analyst who hits a case Volatility cannot fully explain has no fallback and either hands it off or proceeds without the evidence WinDbg would have surfaced. This course refuses that gap. The position it takes is that a memory forensics practitioner should be able to drop to the debugger when the case demands it, not because every case does, but because the cases that do are precisely the high-stakes ones, the sophisticated intrusion, the contested finding, the rootkit, where handing the case off or proceeding without the evidence is the worst available outcome. This sub closes the gap at the right level. Not the kernel developer's WinDbg and not the exploit developer's, just the narrow, task-specific command set for validating findings, reading kernel structures directly, and doing the structural analysis a rootkit defeats at the plugin layer but not at the debugger. It is your fourth tool, after Volatility, MemProcFS, and your own eyes on hex.
WinDbg validates; it does not replace
The mental model to hold is that WinDbg has a different job from Volatility, not a competing one. Volatility is built for forensics: it reconstructs structures across a whole image, reconciles discovery methods, and scales to scanning every process. WinDbg is built for debugging: it gives you a precise, authoritative view of a single structure at a single address, using Microsoft's own symbols and the same structure definitions the kernel itself was compiled against. That makes it the natural validation instrument. When a finding is decisive and will be challenged, you confirm Volatility's parse by displaying the same structure in WinDbg and checking that the two agree field for field. The reason this carries weight is that WinDbg uses Microsoft's own symbols, the same structure definitions the kernel was compiled against, downloaded from Microsoft's public symbol server. When Volatility and WinDbg, two independently built tools relying on independently sourced structure definitions, report the same field at the same offset with the same value, an opposing expert has very little room to argue the finding is a tool artifact. That is the specific evidentiary value WinDbg adds: not a second opinion from a similar tool, but corroboration from the vendor's own debugger against the vendor's own symbols.
Volatility produces the finding at scale; WinDbg confirms the decisive ones against Microsoft's own structure definitions. The phrase "I verified the finding in WinDbg against the kernel's own symbols" is what turns a plugin result into testimony.
Loading an image and the minimum command set
WinDbg opens a memory image as a crash dump. In modern WinDbg you open the .raw/.dmp as a dump file, point the symbol path at Microsoft's public symbol server so the kernel's structure definitions resolve, and reload symbols. From there a forensics practitioner needs only a handful of commands, not the hundreds a kernel developer uses. Getting symbols right is the step that most often trips people, and it is worth understanding rather than copying. WinDbg resolves structure layouts from Microsoft's symbol server, and until symbols load, dt nt!_EPROCESS cannot name a single field because the debugger does not yet know the structure's shape; the .reload after setting the symbol path is what fetches and applies them. On an air-gapped analysis machine, the same staging discipline as Volatility applies: cache the symbol packages in advance, because the debugger is no more able to invent a structure layout offline than a forensics tool is. When symbols are loaded correctly, every subsequent command speaks in named fields and resolved function names; when they are not, you get raw hex and unresolved addresses, which is the visible sign to stop and fix symbols before going further.
The command set worth knowing is small and purposeful. !process 0 0 lists processes by walking the EPROCESS chain, the debugger's equivalent of pslist. dt nt!_EPROCESS displays a structure with every field named and typed from Microsoft's symbols, which is the command that validates what a plugin parsed. db, dd, and dq dump raw bytes, dwords, and qwords at an address, your hex view inside the debugger. dps dumps a region as a list of pointers with the symbol each resolves to, which is how you inspect a function-pointer table for hooks.
lm lists loaded modules. It is the orienting command you run early, because the module list grounds everything else: a function pointer that should resolve into one of these modules and instead points elsewhere is the signature dps later makes visible. That set, plus the address translation from MF0.4, covers the forensic uses; everything else is depth you add only when a specific case demands it.
It is worth understanding why each of those earns its place. dt nt!_EPROCESS is the workhorse: it takes a raw address and overlays Microsoft's structure definition on it, turning an anonymous block of bytes into named, typed fields, which is exactly what you need to confirm that what Volatility called an EPROCESS really has the fields of one at the offsets it should. dps matters for rootkit work because a hooked function-pointer table looks normal as raw bytes but obvious as pointers-with-symbols: a legitimate entry resolves to a named kernel function, while a hooked entry resolves to an address inside an unexpected module or to no symbol at all, and dps makes that contrast visible at a glance. db, dd, and dq are your hex view when you want to see the bytes a structure field actually contains rather than the debugger's interpretation, the same raw-first instinct MF0.3 built, now available inside the debugger. The smallness of the set is the point: you are not learning WinDbg the way a driver developer does, you are learning the half-dozen commands that answer forensic questions.
Worked example: validating a finding against the raw object
The canonical use is confirming a decisive Volatility finding. Suppose windows.psscan surfaced a process that windows.pslist missed, the DKOM-hidden candidate from MF0.3. Before that goes in the report as "DKOM-hidden process," you validate it at the debugger level: display the EPROCESS structure directly and inspect the list pointers the attacker manipulated.
The debugger shows the structure is real, named, and present in memory, yet its ActiveProcessLinks no longer connect it to the active process chain. That is the structural signature of Direct Kernel Object Manipulation, and now you can write the finding with debugger-level support: not "a plugin reported a hidden process," but "the EPROCESS at this address exists with intact contents while its list links have been severed from the active chain, examined directly in WinDbg against Microsoft symbols." MF6 develops this into full kernel-rootkit analysis; here the point is that the capability exists and what it adds.
Notice what the debugger gave you that a plugin alone could not. Volatility's psscan told you a process existed that pslist missed, which is a strong lead but, stated plainly, is "two plugins disagreed." WinDbg let you read the actual mechanism of the disagreement: the structure is intact, its name is real, and its ActiveProcessLinks have been severed, which is not an inference about why the plugins differed but a direct observation of the manipulation that caused it. In a report, the difference between "a scan found a process the active list did not" and "I examined the EPROCESS directly and observed its list links unlinked from the active chain, consistent with deliberate DKOM concealment" is the difference between a finding that invites the question "could the scan be wrong?" and one that has already answered it. That is the whole reason the fourth tool is worth the effort: it converts a multi-plugin discrepancy into an observed, explainable mechanism.
The same approach generalizes beyond DKOM. A suspected SSDT hook becomes a dps of the service table showing one entry resolving outside the kernel's expected range; a questioned driver becomes a structure you read field by field rather than trust a plugin to summarize; a novel technique with no plugin at all becomes something you can still examine, because the debugger reads raw kernel objects whether or not a forensics tool has caught up to the technique that produced them.
Where this fits
WinDbg rounds out the toolkit this module assembles. You have Volatility 3 for primary structural analysis, MemProcFS for triage and interactive exploration, your own reading of raw hex for ground truth, and now WinDbg for authoritative validation and the rootkit cases that defeat the others. Most investigations use the first two heavily and the last sparingly, and that is the correct balance: the debugger is the instrument you are glad to have on the one case in twenty that needs it, and lost without. The cases that need it are not rare in a career, even if they are rare in any given week: the rootkit that feeds your forensics tool false output, the credential-theft variant whose structures a plugin parses wrongly, the testimony where opposing counsel demands to see the raw object rather than your tool's summary of it. None of these can be handled by an analyst who has never opened a memory image in WinDbg, and all of them can be handled adequately with the small command set above. The asymmetry is what justifies the learning curve: a modest, bounded skill that is decisive exactly when the stakes are highest.
You will install WinDbg in the lab build, and the rootkit modules later in the course return to it for real structural analysis. With the toolkit complete, the remaining foundations are about judgment rather than tools: how to assign confidence to a finding, and how to keep an investigation defensible when it reaches legal review. The next sub takes the first of those, the confidence hierarchy that every finding in your report should carry.