Windbg Mcp
WinDbg/DbgEng over MCP: crash dumps, live user & kernel, driver IOCTLs, and TTD.
- Transport
- Not stated
- Package
- —
- Registry id
- io.github.glslang/windbg-mcp
No install snippet on purpose. A working MCP config is a command, its arguments and an environment block — the last two are where API keys live, so this catalogue never stores them and cannot publish them. Follow the link above for the authors' own instructions.
An MCP server that exposes WinDbg/DbgEng to AI agents
(Claude Code, Claude Desktop, Cursor, …) — over stdio, or over HTTP with --listen, which
serves the same tools to clients that are not on the machine DbgEng runs on. It drives a live
debugger engine for user-mode, kernel-mode, crash-dump, and
Time Travel Debugging (TTD) workflows.
The low-level engine bindings live in dbgscope
(src/dbgeng.rs); this crate adds process-per-session engine supervision and the rmcp tool
surface on top.
Documentation
This file is the map. Each topic is one document, and each document is the whole of that topic.
| Install and engine setup | Requirements, prebuilt binaries, Scoop, and the one-time WinDbg engine copy that TTD replay, !analyze, the driver tools and 32-bit .NET SOS need |
| Use with an MCP client | Client config, running the server on another machine (--listen), the Claude Code plugin, the MCP registry |
| Architecture | Why a supervisor process and one engine worker per session, what each source file owns, and which MCP revisions are served |
| The tool surface | Serving fewer tools with --tools, what a typed operand may contain, and how the control-flow and TTD tools behave |
| Sessions and session handles | session_id routing, the four-session cap, interrupt, progress notifications, and recovering a parked attach |
| Kernel connection profiles | Keeping a KDNET debug key out of tool arguments and out of the client's transcript |
| Structured results | Which tools answer with structuredContent, what each carries, and the error categories a caller can branch on |
| Transactional batches | debug_batch: a mutating sequence whose cleanup runs on every path, including a timeout or a disconnect |
| Walking a structure | walk_memory: lists, arrays and chains where an unreadable node is a row rather than the end of the walk |
| Session transcripts | WINDBG_MCP_TRANSCRIPT: a JSONL record of every call, what is redacted, and rendering one as an asciicast |
| Limitations & notes | The honest edges — TTD is user-mode only, static reachability is best-effort, pool and heap walks need a stopped x64 target |
| Walkthroughs | Worked sessions end to end: crash-dump triage, TTD, a Flare-On solve, driver IOCTL surfaces |
| The local-model eval | A grid of model × tool surface × context window against a verified answer key: what a laptop-sized model can drive, and the two defects it found in this server |
Operator and reference material: remote listener, driving it with ollama, driving it with Apple's on-device model, disassembler coordinates, smoke test, token budget, releasing.
Quick start
Windows x64, with dbgeng.dll from System32 — enough for live user-mode, kernel and crash-dump
work. TTD .run replay, !analyze and the driver tools each need files that engine does not ship;
docs/install.md is the one-time copy.
Download a prebuilt windbg-mcp-vX.Y.Z-windows-x64.zip from a
release, or build it:
cargo build --release
Then point a client at the binary:
// .mcp.json (or claude_desktop_config.json under "mcpServers")
{
"mcpServers": {
"windbg": {
"command": "C:\\workspace\\windbg-mcp\\target\\release\\windbg-mcp.exe"
}
}
}
From the project's README.