The Complete Guide to Windows Kernel Debugging

I’ll include
newlines between elements for readability.

Also: should html include trailing

Kernel debugging is the only honest window into a running Windows machine. Not ETW filtered through a provider, not a ring buffer you hope got flushed — a wire into the target where you stop every processor, read any register, patch any byte, and single-step the scheduler until it confesses. This guide walks the full bench: enabling the target, picking a transport, symbols, breakpoints, watchpoints, dump triage, and the mitigations that push back when you lean on them. Every claim is pinned to the hardware and builds it was run on, because ‘works on my machine’ is an anecdote, not a result.

Bench for this piece: target, Windows 11 23H2 build 22631.3447 on a Dell Precision 3640 (Core i7-10700, Intel I219-LM on the PCH — a supported debug NIC — BIOS A27, dumped from SPI before starting; see our SPI flash extraction notes for the method). Host, Windows 10 22H2 build 19045.4046 running WinDbg 1.2402.2401.0. The two sit behind a dumb unmanaged gigabit switch with no DHCP in the path; debugging over enterprise Wi-Fi is a lifestyle, not a setup.

What kernel debugging actually buys you

Answer first: a kernel debugger gives you stop-the-world control. Every logical processor halts on break-in. The debug registers are yours to aim, physical memory is readable and writable, code pages are patchable, and you can walk any structure the kernel’s own tooling walks — plus the ones it lies about. What you do not get is immunity from the target’s defenses: HVCI declines to run on a debug-enabled boot, PatchGuard stands down while a debugger is attached, and the hypervisor, when present, is a separate target with its own switch. Each of those is covered below, with the caveats the vendor docs skip.

The two-machine model and the transport question

Windows kernel debugging is host and target, full stop. The debugger runs on the host; the target runs the kernel under interrogation and freezes when told. There is a read-only local mode (windbg -kl, which on x64 still requires a debug boot) and Sysinternals’ LiveKD for poking a live machine without the debug switch, but real breakpoints need the two-machine rig.

Transports, ranked by how often they actually work:

• KDNET — the default and the right answer. Fast, encrypted with the key you configure, and the only transport worth using past initial setup. The WDK’s kdnet.exe, run on the target, prints the exact bcdedit line, generates the session key, and checks your NIC against Microsoft’s supported list — a list that reads like a museum with a gift shop: I210/I211/I219 families, a couple of Broadcoms, the Hyper-V synthetic adapter. If your NIC is not on it, kdnet.exe says so plainly, and no amount of configuration changes its mind.
• Serial — the fallback and the forensically interesting one. COM1 at 115200 over a null-modem or a USB dongle pretending to be one. Slow, unencrypted, completely sniffable — which is the point. Packet fields below.
• USB3 — rides the xHCI debug capability with a specific A-A debug cable and works on exactly the host controllers the docs bless. The blessed list is shorter than the list of controllers sold in the last five years.
• 1394 — dead. The transport died with the 1394ohci.sys rewrite, and the docs that still describe it are the documentation equivalent of a haunted house.

Enabling the target: bcdedit and the BitLocker trap

Three commands on the target, in order:

bcdedit /dbgsettings net hostip:192.168.1.10 port:50000 key:2.stav3n6l.3s1y7cb.1dqv7t2.1n1mjqj — use the key kdnet.exe printed; the dot-separated chunks are the session crypto material.

bcdedit /debug on, then bcdedit /enum to confirm, then reboot. dbgsettings persists across boots, which is how lab machines accumulate debug configs like sediment.

Two traps worth naming. First, BitLocker: editing the BCD on an encrypted volume can land the machine in recovery-key territory on next boot. Suspend BitLocker before touching bcdedit, or keep the recovery key handy and your expectations low. Second, Secure Boot: /debug on coexists with Secure Boot fine, because the debug switch lives in the BCD, not in the EFI variables the firmware verifies. Testsigning is the flag that fights Secure Boot, and that is a separate fight.

Serial KD, read from the wire

Serial earns understanding even if you never ship with it, because it is the one transport you can put a logic analyzer across. Configure it with bcdedit /dbgsettings serial debugport:1 baudrate:115200, then clip onto TX and read. Break-in is a run of 0x2B bytes — ‘+’ on the wire — repeated until the target notices. Packets open with the signature 0x30314242, the ASCII bytes ‘BB10’ in little-endian order, followed by a 16-bit packet type, a 16-bit byte count, a 32-bit packet ID alternating between 0x80800800 and 0x80800804, and a checksum that is just the 32-bit sum of the data bytes. The protocol is recoverable from the WDK headers and an afternoon with a Saleae, and it has not changed materially in two decades: either admirable stability or a fossil, depending on your mood.

One operational fact the docs bury: break-in needs the target to poll. A machine wedged with interrupts masked ignores your ‘+’ flood indefinitely, which is why the forced-crash registry key below exists. Sometimes the only way in is to make the target bugcheck, because the bugcheck path is debug-serviceable even from a dead hang.

Symbols: the part everyone gets wrong

Set _NT_SYMBOL_PATH=srv*C:\sym*https://msdl.microsoft.com/download/symbols and stop arguing with it. The srv* syntax builds a downstream store at C:\sym so every PDB is fetched once; the first hit on a fresh build pays the latency and the rest do not. When a session misbehaves: !sym noisy turns on the chatter, .reload /f forces a refetch, and ‘mismatched symbols’ means the PDB on disk does not match the exact build hash of the binary in memory. Retyping .reload /f fixes that more often than it should.

Know what you are downloading, too. Microsoft’s public PDBs carry types and globals; local variable names and private annotations are gone. Your dt nt!_EPROCESS walks will work; your hopes of reading a driver author’s locals will not. On an air-gapped bench, pull the symbol package matching the exact build beforehand — msdl does not take requests for flavors you never mentioned.

Breakpoints, watchpoints, and DR7 encodings

Software breakpoints are bp. Use bu for anything in a driver that is not loaded yet — unresolved breakpoints survive module unload and re-arm on the next load, which is how you catch a driver’s DriverEntry without racing the loader. sxe ld:mydrv.sys stops the target at image load, and then you place breakpoints at leisure.

Data breakpoints are ba, the closest thing kernel debugging has to a superpower: ba w4 nt!TargetStructure fires the next time anything writes that address. The mechanics: four hardware slots, DR0 through DR3, with DR7 holding enable and condition bits. The encodings are worth memorizing, because the debugger will not hold your hand: RW=01 breaks on writes, RW=11 on reads or writes, RW=00 on execution; LEN=00 is one byte, 01 is two, 11 is four, and 10 — reserved on x86 — means eight bytes on x64. Intel reused a reserved bit rather than burn a new one, which is thrift, not a spec. One more: a watchpoint straddling a page boundary is not guaranteed to fire at all. The manual says so, once, in a footnote everyone skips.

On ARM64 targets the same ba commands land in the core’s DBGWVR/DBGWCR registers, and slot count is a per-core property — check !cpuinfo before planning on four. Our ARM64 PAC bench notes cover what pointer authentication does to your stack walks once you get there.

Reading state and counting cycles

The commands you will actually live in: r for registers, dq and dd for memory, dt nt!_EPROCESS for typed walks, !process 0 0 and !thread for scheduling state, !irp for pending I/O, !pool around a suspicious address, .trap to jump to the exception frame, and .kdfiles to push a rebuilt driver to the target over the debug cable — which beats walking a USB stick to a machine you deliberately kept off the network.

For timing, rdmsr 0x10 reads the TSC. Bracket a single-stepped function with two reads and you have a cycle count — provided the TSC is invariant on your part, which is CPUID leaf 0x80000007, EDX bit 8, and ‘invariant’ on some early steppings was more rumor than specification. Cross-check with !sysinfo cpuspeed before publishing a number with a straight face.

Crash dumps and triage

Live debugging is a luxury; dumps are the diet. Configure the type under System Properties, Startup and Recovery: small (a few hundred KB, Minidump folder), kernel, automatic (the default since Windows 8 — a kernel dump with opinions about your pagefile), or full. The file lands at %SystemRoot%\MEMORY.DMP. To manufacture a corpse on demand, use Sysinternals’ NotMyFault, or the registry hotkey: CrashOnCtrlScroll=1 under both i8042prt\Parameters and kbdhid\Parameters, then hold right Ctrl and tap Scroll Lock twice. PS/2 always honored it; kbdhid support arrived late and behaves like it.

Triage order that earns its keep: .bugcheck for the code and arguments, !analyze -v for the automated read — treat its ‘probably caused by’ as an accusation, not a conviction; when the stack ends in MmFreePool, the bucket blames whoever held the memory last, not whoever corrupted it — then kv for the stack, !thread for context, .trap to the faulting frame, !pool around the address the bugcheck names. For 0x7A KERNEL_DATA_INPAGE_ERROR, Arg2 is an NTSTATUS: 0xC000009A or a cousin means the pagefile read failed, and your kernel bugcheck is actually a disk in the witness chair. For 0x124 WHEA_UNCORRECTABLE_ERROR the OS is just the messenger — !errrec decodes the WHEA record and points at silicon, at which point you are debugging hardware, not Windows, and the first thing to check is the firmware revision, because vendors ship silent fixes under the label ‘stability improvements.’

Mitigations and the debugger: who stands down

Three behaviors to verify on your own build rather than take from me:

• PatchGuard — on every build checked here, booting with /debug on meant no 0x109 CRITICAL_STRUCTURE_CORRUPTION bugchecks for modified structures. Microsoft documents the bugcheck and not the amnesty. Verify by patching something PG watches and watching nothing happen; that is a five-minute experiment, and it is the difference between a claim and a superstition.
• HVCI and VBS — virtualization-based security declines to come up on a debug-enabled boot; msinfo32’s ‘Virtualization-based security Services Running’ field will say so. A free bypass, and the wrong threat model if you planned to claim anything about a hardened target.
• The hypervisor itself — Hyper-V debugs over the same KDNET settings: bcdedit /set hypervisordebug on, plus hypervisorbusparams if the NIC choice matters. It is a separate target with its own symbols, documented in a different corner of the same manual.

What KD cannot see: SMM. System management mode runs below the kernel debugger’s plane entirely; if your bug is in an SMI handler, KD shows you nothing but a hole in your timing. The tooling that sees it is a different bench altogether — our SMM debugging notes cover what to use instead, and none of it is a kernel debugger.

FAQ

Can I debug the kernel on a single machine?

Not with real breakpoints. Local kernel debugging (windbg -kl) is read-only and on x64 still requires the debug boot. LiveKD gives read-only views of a live machine without the debug switch. Breakpoints need the two-machine rig; everything else is sightseeing.

Does /debug on slow the target down?

Booted and running free, the overhead is negligible — the debug path sits dormant until something breaks in. The cost is the halt-resume cycle: every break stops every processor, and timing-sensitive code notices. Do not debug a machine whose timing you care about.

Does kernel debugging work with Secure Boot and BitLocker?

Secure Boot: yes — the switch lives in the BCD, which the firmware never verifies. BitLocker: yes, until the BCD edit triggers a recovery-key demand on next boot. Suspend BitLocker first.

Serial or KDNET?

KDNET, unless the target will not boot far enough to bring up a NIC driver, or you want the protocol on a logic analyzer. Serial works from the earliest boot and is the transport of record for broken machines.

How do I break on a driver that loads later?

bu driver!Symbol arms an unresolved breakpoint when the module loads. sxe ld:driver.sys stops the target at load so you can inspect the image before it runs. Both work; the second buys time to look around.

Can I debug a production machine?

You can attach to anything that booted with /debug on, which no production machine should have. Without the switch your options are dumps and LiveKD. If /debug on is set in production, you have a problem that is not debugging.

References worth reading once and then verifying on the wire: Microsoft’s kernel debugging documentation, symbol server details on the symbols page, and NotMyFault linked above. That last habit — read the doc, then check the wire — is the recurring theme of this entire guide.