Sven Scharmentke
cd15a7842a
Two changes. ## README: one heading per audience The install section interleaved three routes - a plugin block, a `pip install` block for "any other client", then a **Configure your client** step that circled back to Claude Code. A reader had to work out which lines applied to them. Now: ``` ## Quick start tip + prerequisites ## Install in Claude Code ### The plugin ### Registering the server yourself ## Install in another client ## Start debugging ``` Each path reads top to bottom without branching. **Python leaves the prerequisites list.** It is not one: the plugin fetches the server through `uvx`, and the native build will not need it either. Each route states its own requirement next to the command it applies to - "Needs uv" for the plugin, "Needs Python 3.10 or higher" for the two pip routes. **The enterprise policy tip moves to the top of Quick start.** It can change whether someone proceeds at all, so it belongs before the prerequisites rather than buried between install steps. I left the `Python 3.10+` badge in place - it is accurate metadata for the PyPI package, and removing it would lose real information for the pip routes. Say the word if you would rather it went too. ## ci.yml: push trigger drops main and master ```yaml branches: [ develop ] ``` - `master` does not exist (`git ls-remote --heads origin master` is empty). - `main` is moved solely by `fast-forward-main`, a `GITHUB_TOKEN` push, which by design starts no workflow. The run history confirms it: **zero** `push main` runs since the migration. Listing it implied a gate that cannot fire. `develop` stays, for two reasons that are easy to miss: 1. **The CI badge reads it** (`?branch=develop`). Remove the trigger and the badge falls back to whatever ran most recently anywhere - which is how it previously ended up showing "failing" off a blocked release-PR run. 2. **Merge skew.** PRs are squash-merged with no up-to-date-branch requirement, so a PR merged while behind `develop` produces a tree nobody tested. The push run is the only thing that exercises the merged result. ## Verified The VS Code JSON snippet parses (it briefly did not - a single-backslash `C:\Symbols` slipped in, the same defect this repo already shipped once in the plugin docs), the shell command keeps its single backslash, `ci.yml` parses with `push branches: [develop]`, and the docs formatter is clean.
MCP Server for WinDbg Crash Analysis
A Model Context Protocol server that bridges AI models with WinDbg for crash dump analysis, user-mode remote debugging, and kernel debugging.
Overview
This server drives the Windows debuggers - CDB for user mode (dumps and -remote) and KD for kernel targets (-k) - so you can debug in natural language: "Show me the call stack and explain this access violation" or "Open a kernel session and tell me which driver bugchecked."
It is not a magical auto-fix. It is a Python wrapper around cdb.exe / kd.exe that lets an LLM run real debugger commands and reason about the output.
Features
- Crash dump analysis - open a
.dmp/.mdmp/.hdmpand get automated triage (!analyze -v, stacks, modules, threads) in a single call. - User-mode remote debugging - attach to a live
cdb/WinDbg debug server (-remote) over TCP, a named pipe, or COM, and break in on demand. - Kernel debugging - attach to a kernel target (
-k, driven bykd.exe) over KDNET, a named pipe, or serial; the server waits for the target and breaks in for you. - Run any WinDbg/KD command - drive an open session with arbitrary commands (
kb,!process 0 0,!heap,lm, ...) described in natural language. - Session ids - every open returns a session id; several sessions (dumps, remote, kernel) can be open at once and are addressed independently.
- Resilient live sessions - per-call timeouts, and a slow live command that outruns its timeout is broken into with CTRL+BREAK and the session resynchronized instead of wedging.
- Multi-dump triage - discover and compare many dumps across a directory.
- Text filter hooks - a
--filter-scriptcan redact PII/secrets from tool arguments and output before they leave the machine. - stdio or HTTP - run locally over stdio, or as a streamable-HTTP service you drive from another machine.
Use cases
| You have | You want to | Guide |
|---|---|---|
A .dmp from a crash |
Root-cause it: exception, faulting frame, why it happened | Analyze a crash dump |
A live user-mode process (via cdb -server) |
Break in and inspect a hang or live state | Debug a remote target |
| A KD-enabled machine or VM | Debug drivers, bugchecks, and boot-time issues | Debug a kernel target |
| A folder full of dumps | Triage the batch and find the common signature | Triage multiple dumps |
| A debugging host, but you work elsewhere | Drive it over HTTP from another machine | Debug from another machine |
| Dumps with secrets or PII | Scrub tool output before it leaves the box | Redact sensitive data |
Tools
Every open_* tool returns an opaque session_id (e.g. cdb-1a2b3c4d); pass it to the matching run_*, close_*, send_ctrl_break, and wait_for_break calls. User-mode targets (dumps and -remote) run under cdb.exe; kernel targets run under kd.exe.
| Tool | Purpose |
|---|---|
list_dumps |
List crash dump files in a directory |
open_cdb_dump |
Open and triage a crash dump |
open_cdb_remote |
Attach to a user-mode remote debug server (-remote) |
open_kd_session |
Attach to a kernel target (-k, KDNET / named pipe / serial) |
run_cdb_command |
Run a command on a user-mode session |
run_kd_command |
Run a command on a kernel session |
close_cdb_session |
Close a user-mode session |
close_kd_session |
Close a kernel session (resumes the target machine) |
send_ctrl_break |
Break into a running live session |
wait_for_break |
Wait for a target you resumed with g to stop again |
Parameters, timeouts, and the built-in triage prompts are in the tools reference.
Quick start
Tip
In enterprise environments, MCP server usage might be restricted by organizational policies. Check with your IT team about AI tool usage and ensure you have the necessary permissions before proceeding.
Prerequisites
- Windows with Debugging Tools for Windows or WinDbg from the Microsoft Store, which ship
cdb.exeandkd.exe(auto-detected). - Any MCP-compatible client (Claude Code, GitHub Copilot, Claude Desktop, Cursor, Windsurf, Cline, ...).
Python is not a prerequisite in itself. Each route below states what it needs.
Install in Claude Code
The plugin
The shortest path: two lines, no pip install, no MCP configuration to edit. Adds four
skills and a crash-analyst agent on top of the ten tools, with symbols preconfigured.
/plugin marketplace add svnscha/mcp-windbg
/plugin install mcp-windbg-uvx@mcp-windbg
Needs uv, which supplies uvx: winget install astral-sh.uv. The
plugin uses it to fetch the pinned server from PyPI on first use, so there is nothing else to
install. See the plugin README for symbols and options.
Registering the server yourself
If you would rather not use the plugin, or you already run the package:
pip install mcp-windbg
claude mcp add mcp-windbg -s user -e _NT_SYMBOL_PATH="SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols" -- python -m mcp_windbg
Needs Python 3.10 or higher. The tools are identical; the skills and the agent are not included.
Install in another client
pip install mcp-windbg
Needs Python 3.10 or higher. Then point the client at python -m mcp_windbg. For VS Code
(GitHub Copilot), press F1 and select MCP: Open User Configuration to enable it in every
workspace:
{
"servers": {
"mcp_windbg": {
"type": "stdio",
"command": "python",
"args": ["-m", "mcp_windbg"],
"env": {
"_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
}
}
}
}
See the client configuration guide for Claude Desktop, Copilot CLI, Autohand Code, HTTP, and from-source setups.
Start debugging
Restart your client, then ask for what you want:
Analyze the crash dump at C:\dumps\app.dmp
Connect to tcp:Port=5005,Server=192.168.0.100 and show me the current thread state
Open a kernel session on net:port=50000,key=1.2.3.4, run !analyze -v, and tell me which driver bugchecked
Server options (--cdb-path, --kd-path, --symbols-path, --filter-script, --transport, ...) are documented in the command-line reference.
Documentation
| Topic | Description |
|---|---|
| Getting started | Setup and your first crash dump analysis |
| Analyze a crash dump | Root-cause an exception: faulting frame, why it happened |
| Debug a remote target | Break into a live user-mode process and inspect a hang |
| Debug a kernel target | Drivers, bugchecks, and boot-time issues over KDNET or a pipe |
| Triage multiple dumps | Scan a folder and find the common signature |
| Debug from another machine | Run the server over HTTP and drive it remotely |
| Redact sensitive data | Scrub secrets from tool output before it leaves the box |
| Reference | Tools, prompts, CLI options, and client configuration |
| Troubleshooting | Common issues and solutions |
| Development | Run from a local checkout and point a client at the dev build |
Blog
Read about the development journey: The Future of Crash Analysis: AI Meets WinDbg
License
MIT