← Back to directory
M

MCP Server for WinDbg Crash Analysis

Community
Drive WinDbg with natural language for Windows crash dump analysis
GitHub source repository ↗
★ 1.6k Stars Category · Dev Tools Very popular
67FMRS · C

Maintained by an individual developer (repository svnscha/mcp-windbg, MIT license); it is not an official Microsoft or MCP protocol project. It wraps cdb.exe / kd.exe behind ten MCP tools covering dump analysis, user-mode remote debugging, kernel debugging, bulk triage, and output filtering, with stdio and streamable-HTTP transports plus a Claude Code plugin and VS Code client config. It suits Windows developers doing crash and driver triage who already use an MCP client; it is not for non-Windows environments or users expecting automatic fixes. Before use, confirm the debugging tools are installed, understand that live and kernel sessions interrupt targets, and use a filter script to control sensitive data exposure.

Reliability
11/20
Security and permissions
12/20
Maintenance
13/20
Documentation
17/20
Setup experience
14/20
Read the FMRS scoring method →

A Model Context Protocol server that bridges AI models with WinDbg for Windows crash dump analysis, user-mode remote debugging, and kernel debugging. Under the hood it drives the Windows debuggers: CDB for user mode (dumps and -remote) and KD for kernel targets (-k). It is not a magical auto-fix, but a Python wrapper around cdb.exe / kd.exe that lets an LLM run real debugger commands and reason about the output. Every open_* call returns a session_id so several sessions (dumps, remote, kernel) can be open at once and addressed independently; per-call timeouts break into slow live commands with CTRL+BREAK and resynchronize the session. It runs locally over stdio or as a streamable-HTTP service you can drive from another machine, and a --filter-script can redact PII/secrets from tool arguments and output before they leave the machine.

Tools

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

Setup

  1. Prerequisites: Windows with Debugging Tools for Windows or WinDbg from the Microsoft Store, which ship cdb.exe and kd.exe (auto-detected). 2. In Claude Code you can use the plugin: /plugin marketplace add svnscha/mcp-windbg then /plugin install mcp-windbg-uvx@mcp-windbg; this needs uv (winget install astral-sh.uv) which supplies uvx. 3. Or register manually: pip install mcp-windbg (Python 3.10+ required), then run claude mcp add mcp-windbg -s user -e _NT_SYMBOL_PATH="SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols" -- python -m mcp_windbg. 4. Other clients: after installing, point the client at python -m mcp_windbg; in VS Code (GitHub Copilot) press F1 and select MCP: Open User Configuration, then use the servers config shown in the README. 5. Restart your client and ask in natural language, e.g. 'Analyze the crash dump at C:\dumps\app.dmp'. Server options include --cdb-path, --kd-path, --symbols-path, --filter-script, --transport.
claude_desktop_config.json
{
  "servers": {
    "mcp_windbg": {
      "type": "stdio",
      "command": "python",
      "args": ["-m", "mcp_windbg"],
      "env": {
        "_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
      }
    }
  }
}

Fit and risk

Best for

  • Developers and support engineers doing Windows crash dump and driver/kernel triage
  • Users of MCP clients (Claude Code, GitHub Copilot, Claude Desktop, Cursor, Windsurf, Cline) who want natural-language control of WinDbg
  • Teams that need to manage and automate multiple cdb/kd sessions (dumps, remote, kernel) in parallel
  • Environments that must filter sensitive data before debugging output leaves the machine

Not for

  • Non-Windows platforms: dump analysis needs cdb.exe and kernel debugging needs kd.exe
  • Users expecting an automatic fix: it runs real debugger commands and lets the model reason about output
  • Users without organizational permission to use AI tools in a managed enterprise environment
  • Users who have not installed the debugging tools (cdb.exe / kd.exe)

Required permissions

  • Execute local processes on the Windows host (cdb.exe / kd.exe and the Python package)
  • Read local dump files (.dmp/.mdmp/.hdmp) and target directories
  • Open TCP, named-pipe, or COM connections for user-mode remote debugging
  • Open KDNET, named-pipe, or serial connections for kernel debugging (waits for and breaks into the target machine)
  • Optional: filter tool arguments and output via --filter-script; configure a custom CDB_PATH and symbol path via _NT_SYMBOL_PATH

Risks and side effects

  • Closing a kernel session resumes the target machine, which may affect it if it is processing critical state
  • Attaching to live (remote or kernel) sessions interrupts the target and may affect production or shared environments
  • Without --filter-script, sensitive data in dumps may leave the machine as part of tool output
  • Using MCP and AI tools in enterprise environments may be restricted by organizational policy; confirm permissions first
  • The default symbol path uses the Microsoft symbol server, so debugging may access external networks

Troubleshooting

  1. If cdb.exe/kd.exe is not found, confirm the debugging tools are installed or set CDB_PATH, --cdb-path, --kd-path explicitly
  2. If symbols fail to resolve, check _NT_SYMBOL_PATH / --symbols-path (defaults to the Microsoft symbol server)
  3. A slow live command is broken into with CTRL+BREAK and the session resynchronized; if still unresponsive, use send_ctrl_break manually
  4. Kernel sessions require a reachable target over KDNET / named pipe / serial; verify connection parameters and target state
  5. If remote debugging fails to connect, check the TCP, named-pipe, or COM connection string and reachability
  6. If the HTTP transport does not respond, confirm --transport streamable-http and the right --port (default 8000) and call http://localhost:{port}/mcp

Use cases

Analyze a .dmp from a crash and root-cause it: exception, faulting frame, why it happened
Break into a live user-mode process (via cdb -server) and inspect a hang or live state
Debug drivers, bugchecks, and boot-time issues on a KD-enabled machine or VM
Triage a folder full of dumps and find the common signature
Run the server over HTTP on a debugging host and drive it from another machine
Scrub secrets or PII from tool output before it leaves the box

Supported clients

Claude CodeFull support
GitHub Copilot (VS Code)Full support
Claude DesktopFull support
CursorFull support
WindsurfFull support
ClineFull support