mcp-windbg: an MCP server that drives CDB and KD for crash dump triage
Model Context Protocol for WinDbg.
At a glance
- What is it?
- mcp-windbg wraps cdb.exe and kd.exe behind ten MCP tools so an LLM can open a dump, run real debugger commands and reason about the output. It is Windows-only, and it is a wrapper, not an auto-fix.
- Who is it for?
- Adopt mcp-windbg if you already keep Windows crash dumps and want an MCP client to run !analyze -v, stacks and module lists without you retyping commands; the ten-tool split between open_*, run_* and close_* is the part that makes multi-session work bearable. Do not adopt it if your debugging happens on Linux, if you expect the model to find the bug without a debugger command behind it, or if you cannot install Debugging Tools for Windows on the host.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap mcp-windbg fills between a .dmp file and an answer
Crash triage on Windows is a command-line ritual. You open a dump in cdb, type !analyze -v, read the faulting frame, run kb to see the stack, lm to see the module list, and repeat until the picture holds. The tooling is good; the friction is that every step is a command you have to remember and a wall of text you have to read. mcp-windbg puts a Model Context Protocol server in front of that loop so an MCP client can issue the commands and reason about the output.
The README is careful about scope: 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." That sentence is the whole product. The audience is Windows developers and support engineers who already own the dumps and the debugger, and who want the reading done faster, not replaced. If you have never used WinDbg, this server will not teach you what a stack frame is.
How the server drives cdb.exe and kd.exe
The architecture is a process wrapper with a session table. User-mode targets, meaning crash dumps and live -remote debug servers, run under cdb.exe. Kernel targets, opened with -k, run under kd.exe. Every open_* tool returns an opaque session id such as cdb-1a2b3c4d, and that id is what you pass to the matching run_*, close_*, send_ctrl_break and wait_for_break calls. Several sessions can be open at once and are addressed independently, so a dump triage and a live kernel attach do not collide.
The tool surface is deliberately small: list_dumps, open_cdb_dump, open_cdb_remote, open_kd_session, run_cdb_command, run_kd_command, close_cdb_session, close_kd_session, send_ctrl_break and wait_for_break. The split between open and run is what lets the client treat a debugger session as state rather than a one-shot shell call.
Live sessions get the most engineering attention. The README describes per-call timeouts, and says a slow live command that outruns its timeout is broken into with CTRL+BREAK and the session resynchronized instead of wedging. That is the failure mode anyone who has scripted a debugger will recognise: a command that never returns, and a wrapper that hangs with it. wait_for_break exists for the other half of the problem, waiting for a target you resumed with g to stop again. close_kd_session is documented as resuming the target machine, which is the detail that matters if you attached to hardware you still need.
Installing mcp-windbg in Claude Code with uvx
The prerequisites are a Windows machine with Debugging Tools for Windows or WinDbg from the Microsoft Store, which ship cdb.exe and kd.exe and are auto-detected, plus any MCP-compatible client. Python is not a prerequisite in itself; each install route states what it needs.
The shortest route is the plugin, which uses uvx to fetch the pinned server from PyPI on first use. It needs uv, which supplies uvx:
winget install astral-sh.uvThen add the marketplace and install the server plugin. The README calls this "two lines, no pip install, no MCP configuration to edit", and notes that symbols are preconfigured:
/plugin marketplace add svnscha/mcp-windbg
/plugin install mcp-windbg-uvx@mcp-windbgSkills and agents are separate plugins. mcp-windbg-skills adds four optional skills and mcp-windbg-agents adds a crash-analyst agent; both use the uvx plugin or your own MCP connection. The README also carries a warning for managed environments: when managed settings define allowedMcpServers, plugin-bundled MCP servers may be silently skipped (Claude Code issue #32882), and the maintainer recommends installing and registering the server manually, then optionally adding the skills or agents plugin. A first real use is a dump: point the client at a .dmp, let it call open_cdb_dump, and expect the triage output from !analyze -v plus stacks, modules and threads in a single call. The examples directory ships small C++ programs such as divide-by-zero.cpp and invalid-free.cpp that you can compile with examples/build.ps1 to produce dumps to practise on.
Where mcp-windbg stops being the right tool
The Windows dependency is absolute. The package classifiers list Operating System :: Microsoft :: Windows, and the whole mechanism is cdb.exe and kd.exe. On Linux or macOS there is nothing for the server to drive, and no amount of MCP configuration changes that.
The second limit is the model. The README is explicit that the LLM runs commands and reasons about output; it does not synthesise a root cause from a dump on its own. If the triage prompt asks the wrong question, or the symbols do not resolve, you get a confident paragraph about the wrong frame. Symbol configuration is mentioned as preconfigured in the plugin and documented in the plugin README, but a dump analysed without the right symbols is still a dump analysed wrong.
Third, kernel sessions touch real machines. close_kd_session resumes the target, and the server waits for the target and breaks in for you. Attaching to a production machine over KDNET is a decision the wrapper does not make safer. Fourth, the redaction hook is opt-in. The README lists --filter-script as a way to redact PII or secrets from tool arguments and output before they leave the machine, which implies that without it, tool arguments and output go wherever your MCP client sends them.
mcp-windbg against GDB MCP servers and WinDbg extensions
The nearest alternatives fall into two groups. GDB MCP servers take the same idea to the GNU debugger, and the difference is not cosmetic: the command language, the dump format and the symbol story are all different, so a GDB-based server cannot open a Windows .dmp and a WinDbg-based server cannot drive a Linux core file. If your crashes are on Windows, the GDB route is not a substitute.
The second group is WinDbg extensions and the built-in AI features that ship with WinDbg itself. Those run inside the debugger window and are tied to that interactive session. mcp-windbg runs outside it, as a stdio or streamable-HTTP service, which is what makes the HTTP scenario possible: you keep the debugging host with cdb.exe and kd.exe installed, and drive it from another machine. That is a different deployment shape, not a better one. A WinDbg extension is the right answer when a human is sitting in front of the debugger; an MCP server is the right answer when the client is an agent that needs to open several sessions and keep them straight.
Maintenance, releases and what the MIT licence means for you
The repository is not archived, and the last push was on 2026-09-09, the same day v1.3.0 was released. The two releases before it, v1.2.2 and v1.2.1, landed on 2026-09-05 and 2026-08-27, so the project is moving in small, frequent steps rather than one large drop. The default branch is develop, and the CHANGELOG.md and release-please configuration in the repository root suggest releases are generated from commit history.
The dependency policy is worth reading before you pin anything. pyproject.toml caps every runtime dependency at the next major, and the comment explains why: mcp 2.0.0 resolved into an unbounded mcp>=1.28.1 and died at import before the server started (issue #76). The cap turns that class of breakage into a Dependabot PR that fails CI instead of a broken install. For a tool you run rather than import, that is the right trade: you get the fix on your schedule, and you give up automatic major upgrades. The current floor is mcp>=2.1.1,<3.0.0, with pydantic, starlette and uvicorn capped the same way, and requires-python is >=3.10.
The licence is MIT, which permits commercial use and modification, and the repository ships a LICENSE file. That is a statement about the licence text, not advice about your situation; if you redistribute the server inside a product, read the file yourself.
Editorial conclusion
Adopt mcp-windbg if you already keep Windows crash dumps and want an MCP client to run !analyze -v, stacks and module lists without you retyping commands; the ten-tool split between open_*, run_* and close_* is the part that makes multi-session work bearable. Do not adopt it if your debugging happens on Linux, if you expect the model to find the bug without a debugger command behind it, or if you cannot install Debugging Tools for Windows on the host. Before wiring it into a workflow, verify that cdb.exe and kd.exe are auto-detected on your machine, read the tools reference for the per-call timeouts, and decide whether the --filter-script redaction hook is needed for the dumps you handle.
Frequently asked questions
What is mcp-windbg used for?
It is a Model Context Protocol server that bridges AI models with WinDbg for crash dump analysis, user-mode remote debugging and kernel debugging. It lets an MCP client run real debugger commands such as !analyze -v, kb and lm on a session and reason about the output.
How do I read a dmp file with mcp-windbg?
The open_cdb_dump tool opens a .dmp, .mdmp or .hdmp and returns a session id, and the README says it gives automated triage with !analyze -v, stacks, modules and threads in a single call. You then pass that session id to run_cdb_command for further commands and to close_cdb_session when you are done.
How do I interpret WinDbg output through mcp-windbg?
The server does not parse the output for you; the README describes it as a wrapper that lets an LLM run real debugger commands and reason about the output. Interpretation happens in the MCP client, which is why symbol configuration matters for the quality of the answer.
Is mcp-windbg made by Microsoft?
No. It is published by svnscha, the author named in pyproject.toml and the maintainer of the GitHub repository. It drives Microsoft's cdb.exe and kd.exe, which come from Debugging Tools for Windows or WinDbg from the Microsoft Store.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/svnscha-mcp-windbg)