How do I install the Analyze Dump skill?

Run npx skillmds@latest add svnscha/analyze-dump in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Analyze Dump safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Analyze Dump?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Analyze Dump free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Analyze Dump?

svnscha (@svnscha) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Analyze Dump by svnscha — Agent Skill

Name: Analyze Dump
Rating: 4.2 (5 reviews)
Author: svnscha

File contents

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.

Triage

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.
run_cdb_command with !analyze -v. This is the single most informative command and belongs in every triage.
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
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.

---name: analyze-dumpdescription: 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 or asks why a Windows process crashed.---# Analyze a Windows crash dump## MCP connectionUse 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 basenames; resolve them against the tools exposed by that connection rather thanassuming a plugin-specific prefix. Keep each session on the server that openedit. 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 tooland help check its configuration; do not register a second server.Work through a `.dmp` file with the `mcp-windbg` tools and report what actuallycrashed, not just what the debugger printed.## Getting a dump pathIf the user gave a path, use it. If not, call `list_dumps` to show what is inthe local crash dump directory and ask which one. Do not guess.## Triage1. `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 implicates4. `close_cdb_session` when you are done.## ReportingLead 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 thespecific 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 onlyshows the crash point, not the cause, and here is what would" is more usefulthan a confident guess.

Frequently asked questions

Analyze Dump