/analyze-dump

name: analyze-dump
description: Triage a Windows crash dump - identify the exception, the faulting frame, and what to look at next. Use when the user points at a .dmp file, asks why a Windows process crashed, or asks why a machine blue-screened.

Analyze a Windows crash dump

MCP connection

Use the existing mcp-windbg MCP connection, whether it is launched by a plugin, a native executable, Python, or an HTTP service. Tool names below are base names; resolve them against the tools exposed by that connection rather than assuming a plugin-specific prefix. Keep each session on the server that opened it. If multiple servers match, use the user's selected server or ask which one. If the required tools are unavailable, report the missing connection or tool and help check its configuration; do not register a second server.

Work through a `.dmp` file with the `mcp-windbg` tools and report what actually crashed, not just what the debugger printed.

Getting a dump path

If the user gave a path, use it. If not, call `list_dumps` to show what is in the local crash dump directory and ask which one. Do not guess.

Kernel dumps

A blue screen leaves a kernel dump: `MEMORY.DMP`, or a file under `C:\Windows\Minidump`. Open it with `open_kd_dump` instead of `open_cdb_dump`, and use `run_kd_command` and `close_kd_session` in place of the cdb tools below. The triage is the same, led by `!analyze -v` and the bugcheck code; kernel follow-ups include `!thread`, `!process 0 0`, `lmvm <driver>`, and `!irql`.

Triage

1. `open_cdb_dump` with the path. Pass `include_stack_trace: true`; add `include_modules` or `include_threads` only if the question calls for them. Keep the returned `session_id` for every follow-up call. 2. `run_cdb_command` with `!analyze -v`. This is the single most informative command and belongs in every triage. 3. Follow the evidence with further `run_cdb_command` calls. Useful next steps:

• `k` / `kb` for the call stack with arguments
• `lm` to see whether the faulting module has symbols
• `.exr -1`, `.ecxr` for the exception record and context
• `dt`, `dx`, `db`/`dd` to inspect the data the crash implicates

4. `close_cdb_session` when you are done.

Reporting

Lead with the answer: what failed, where, and why, in the first two sentences. Then support it - exception code and its meaning, the faulting frame, and the specific evidence that points there.

Two things worth being explicit about:

• **Say when symbols are missing.** A stack full of `module+0x1234` is a

symbol problem, not an analysis result. Say so rather than reading meaning into offsets, and mention `_NT_SYMBOL_PATH`.

• **Separate fact from inference.** "The access violation is at a null `this`

pointer" is a fact from the register state. "This is probably a use-after-free" is a hypothesis - label it as one and say what would confirm it.

If the dump does not support a conclusion, say that. An honest "this dump only shows the crash point, not the cause, and here is what would" is more useful than a confident guess.