MCP Server for WinDbg Crash Analysis
Author: svnscha
Description: A Model Context Protocol (MCP) server that bridges AI models with WinDbg/CDB for Windows crash dump analysis and remote/live debugging.
Stars: 1.1k
Forks: 101
License: MIT License
Category: Specialized
Overview
Installation
pip install mcp-windbgmcp-windbg
# or explicitly
mcp-windbg --transport stdiomcp-windbg --transport streamable-http --host 127.0.0.1 --port 8000http://127.0.0.1:8000/mcp{
"servers": {
"mcp_windbg": {
"type": "stdio",
"command": "python",
"args": ["-m", "mcp_windbg"],
"env": {
"_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
}
}
}
}python -m mcp_windbg --transport streamable-http --host 127.0.0.1 --port 8000{
"servers": {
"mcp_windbg_http": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}list_windbg_dumps
List available crash dump files for discovery and batch analysis.
open_windbg_dump
Open and analyze a crash dump file to start an initial dump analysis session.
close_windbg_dump
Close/cleanup an active crash dump analysis session to free resources.
open_windbg_remote
Connect to a remote WinDbg/CDB debugging target for live debugging sessions.
close_windbg_remote
Close/cleanup an active remote debugging session to free resources.
run_windbg_cmd
Execute WinDbg/CDB debugger commands for custom investigation and analysis.
FAQs
How do I configure the _NT_SYMBOL_PATH environment variable correctly for mcp-windbg to resolve Microsoft symbols?
The standard format is `SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols`, where `SRV*` enables symbol server mode, `C:\Symbols` creates a local cache directory to avoid repeated downloads, and the URL points to Microsoft's public symbol server. Ensure your firewall allows HTTPS access to msdl.microsoft.com, and the cache directory has write permissions for CDB to store downloaded PDB files.
Can I use mcp-windbg to analyze kernel-mode crash dumps (.dmp files from BSOD), or is it limited to user-mode minidumps?
Yes, mcp-windbg can analyze kernel-mode crash dumps because it executes arbitrary CDB commands through run_windbg_cmd, and CDB natively supports kernel dump analysis. The server accepts any .mdmp or .hdmp file via open_windbg_dump, then allows kernel-specific commands like !analyze -v, !bugcheck, or lm for driver inspection. Ensure _NT_SYMBOL_PATH includes kernel symbols from Microsoft's symbol server.
What are the advantages of using mcp-windbg's streamable-HTTP transport over stdio, and when should I choose one over the other?
Streamable-HTTP enables remote access and multi-client scenarios, allowing teams to centralize debugging servers accessible over network rather than local process communication. Choose stdio for single-machine, single-client setups with lower latency and simpler configuration. Choose HTTP when debugging resources must be shared across teams, accessed from containerized environments, or when client-server separation improves security or resource management.
How does mcp-windbg handle timeouts when running long-running CDB commands like heap analysis on large crash dumps?
The server applies a default thirty-second timeout configurable via the `--timeout` CLI flag. For large dumps or intensive heap analysis, operators should increase this value before starting the server. The timeout applies globally to all CDB subprocess operations, so plan headroom for your slowest expected command rather than average case scenarios.
Can mcp-windbg batch-analyze multiple crash dumps automatically, or does each dump need to be opened and analyzed individually?
Each dump requires individual open, analyze, and close cycles. The list_windbg_dumps tool discovers multiple dump files, but open_windbg_dump processes one session at a time. You can script batch workflows by chaining tools through an MCP client, but the server itself does not provide native batch automation or parallel session handling.
What security considerations should I be aware of when using mcp-windbg's remote debugging feature with open_windbg_remote over TCP?
Remote debugging over TCP lacks built-in authentication or encryption. Use firewalls to restrict access to trusted IPs, establish VPN tunnels for production, and avoid exposing debugger ports publicly. WinDbg remote protocols transmit memory and code in cleartext, creating data exfiltration risks. Consider SSH tunneling or IPsec for encrypted transport.