Crash dumps

Analyse a Windows kernel crash dump (.dmp) offline, without a running VM:

ntoseye --dump /path/to/MEMORY.DMP

Full and kernel dumps, plus kernel triage (small/minidump) dumps, are supported. BSOD dumps give you the crash registers, stack trace, and bugcheck analysis automatically; live system dumps (bugcheck 0x161) have memory but no exception context.

Available commands include ps, lm, dt, dq/db/dd, dqs, da/du, analyze, trap, x, ev, drivers, and s. Execution control, breakpoints, and register/memory writes are not available (the dump is read-only).

The Python SDK supports dump analysis as well:

import ntoseye
dbg = ntoseye.attach("dmp", connect="/path/to/MEMORY.DMP")

So does the MCP server: pass --dump at startup (ntoseye mcp --dump /path/to/MEMORY.DMP), or start it with ntoseye mcp (no flags) and let the client load a dump later via the open tool with backend: dump and the dump path as connect.

Writing a dump from a live target

From a live halted target, use the WinDbg-compatible command:

.dump [/f] [/ma] <file>

This streams a PAGEDU64 full kernel dump page by page. It requires a live halted target with memory introspection; a static crash-dump session cannot write another dump. AMD64 and ARM64 targets are both supported: the header’s MachineImageType and the embedded CONTEXT record follow the target’s architecture. /f and /ma are accepted as full-dump switches. The resulting file can be reopened with ntoseye --dump <file>.

The writer streams into a temporary file beside the destination (mode 0600) and renames it over the destination only after the write completes, so the resulting dump is owner-readable regardless of umask. Ctrl+C or a write failure leaves an existing dump unchanged and removes the temporary file. Replacing a dump therefore requires space for the new file alongside the old one. Unreadable guest pages are zero-filled and counted in the command output. Targets with more than 42 physical-memory runs are rejected rather than producing an incomplete full dump.

Generating dumps

From the host, without crashing the guest (produces a live system dump, bugcheck 0x161):

virsh dump <domain> /tmp/win.dmp --memory-only --format=win-dmp

This needs the domain’s vmcoreinfo feature (ntoseye configure can enable it for libvirt guests) and the virtio-win fwcfg driver installed in the guest.

From a real BSOD, Windows writes C:\Windows\MEMORY.DMP on the boot after the crash (System Properties > Startup and Recovery > “Kernel memory dump”). The dump is staged through the page file, so pick one:

  • keep a page file on C: at least as large as the dump (in the Virtual Memory dialog, click Set before OK, or it silently discards the change), or

  • keep paging disabled (see Recommended guest tweaks) and configure a dedicated dump file instead, under HKLM\SYSTEM\CurrentControlSet\Control\CrashControl: DedicatedDumpFile (REG_SZ, e.g. C:\dedicated.sys) and DumpFileSize (DWORD, MB).

Force the crash with Sysinternals NotMyFault or the CrashOnCtrlScroll registry switch. If the guest is booted in debug mode with a debugger attached, continue past the bugcheck (g), otherwise Windows waits in the debugger instead of writing the dump.

Copy the dump out to the host with guestfs-tools while the guest is shut off:

virt-copy-out -d <domain> /Windows/MEMORY.DMP /tmp/

(or use any guest-to-host channel: an SMB/virtiofs share, scp, etc.)