svnscha - crash-analysis

🚀 New Release: mcp-windbg 1.3.0

2026-09-10T00:00:00+00:00

Version 1.3.0 of mcp-windbg separates the Claude Code integration into three plugins. If you've already installed mcp-windbg yourself, you can now add the debugging skills and crash-analysis agent to that connection.

Three Separate Plugins

The 1.2.0 release bundled the server, skills, and agent together. I split them so you can choose the parts you need:

Plugin	What it provides
`mcp-windbg-uvx`	The MCP server, launched with uvx, and default symbol settings
`mcp-windbg-skills`	Four debugging skills
`mcp-windbg-agents`	The `crash-analyst` agent

The uvx plugin now ships only the server configuration. Skills and agents are independent: install either, both, or neither.

Skills and Agents for Your Existing Server

If mcp-windbg is already registered in Claude Code, add the marketplace and install the workflows you want:

/plugin marketplace add svnscha/mcp-windbg
/plugin install mcp-windbg-skills@mcp-windbg
/plugin install mcp-windbg-agents@mcp-windbg

The skills cover the same four tasks:

analyze-dump for crash dump analysis.
debug-remote for live user-mode debugging.
kernel-debug for live kernel debugging.
windbg-doctor for checking the debugging setup.

They use your configured MCP connection, whether it runs a native executable, a Python installation, or an HTTP service. Setup diagnosis checks that server's actual launcher and host. It no longer assumes every installation needs uv.

For example:

/mcp-windbg-skills:analyze-dump C:\dumps\app.dmp

The agent is available as mcp-windbg-agents:crash-analyst. It investigates a dump and reports its likely cause, debugger evidence, and next steps. It uses the MCP tools directly and does not need the skills plugin.

If you want the plugin to start the server through uvx, install it as well:

/plugin install mcp-windbg-uvx@mcp-windbg

Windows and CDB/KD are still required on the debugging host. The server's built-in MCP prompts are available independently of these plugins.

Enterprise environments: Managed allowedMcpServers settings can cause Claude Code to silently skip plugin-bundled MCP servers (issue #32882). I recommend manual installation and registration plus the skills plugin, with the agents plugin if needed. The server must still be permitted by your organization's MCP policy.

Upgrading from the Bundled Plugin

Update the marketplace and server plugin:

/plugin marketplace update mcp-windbg
/plugin update mcp-windbg-uvx@mcp-windbg

Then install the skills and agents plugins using the commands above if you want to keep those workflows.

Skill commands now start with /mcp-windbg-skills: instead of /mcp-windbg:. For example, /mcp-windbg:analyze-dump becomes /mcp-windbg-skills:analyze-dump. References to the agent should use mcp-windbg-agents:crash-analyst. Restart Claude Code if the new components do not appear.

See the full v1.3.0 release notes and the plugin guide for installation, switching servers, and updating each plugin.

🚀 New Release: mcp-windbg 1.2.2

2026-09-05T00:00:00+00:00

Version 1.2.2 of mcp-windbg is out. This release fixes missing Unicode output on Windows systems that use a multibyte code page, including Chinese, Japanese, and Korean systems.

The bug was reported by a community member in issue #102. Thanks for taking the time to provide a clear report and help track it down.

The Problem

The du command, which displays a Unicode string, sometimes returned an empty result through mcp-windbg. Running the same command directly in CDB worked as expected. Other commands such as db and dw also worked against the same address.

The important detail was the reporter's Chinese Windows system locale.

What Caused It

mcp-windbg communicates with cdb.exe through a pipe. It sends a command and reads the debugger's response from that pipe.

On multibyte system code pages, such as Chinese 936, Japanese 932, Korean 949, or the "Use Unicode UTF-8" setting, CDB can truncate text while writing it to a pipe. The end of a line may be missing, including the closing quote and newline.

For du, this could remove the entire string. If the output was cut in the middle of a character, later commands could also time out because the session could no longer parse the incomplete output correctly.

This only affects redirected output, which is why the command still looks correct when run in a normal debugger window. There is no CDB option that fixes the pipe output; interactive mode, batch mode, and ANSI log files all show the same problem.

The Fix

CDB can write complete UTF-16 log files using .logopen /u, so mcp-windbg now uses one on affected systems. The pipe is still used to manage command timing, but the command output itself is read from the UTF-16 log.

This is not a special case for du. It also fixes Unicode text in module paths, !analyze output, string dumps, and other debugger commands. Systems with a single-byte code page continue to use the existing pipe-based output.

I tested the fix with real crash dumps, a live kernel target, and remote sessions using the 1252, 936, and 65001 code pages.

Getting Started

Upgrade with:

pip install -U mcp-windbg

If you use the Claude Code plugin, update the plugin to pick up the new version.

The project is available on GitHub. If you notice any other commands behaving differently on a non-English Windows system, please open an issue.

🚀 New Release: mcp-windbg 1.2.0

2026-08-27T00:00:00+00:00

Version 1.2.0 of mcp-windbg adds a Claude Code plugin. It packages the MCP server together with the instructions and workflows needed for common debugging tasks, so Claude Code can install and use it without a separate Python setup or a hand-written MCP configuration.

Installing the Plugin

Add the mcp-windbg marketplace and install the plugin from Claude Code:

/plugin marketplace add svnscha/mcp-windbg
/plugin install mcp-windbg-uvx@mcp-windbg

The plugin starts mcp-windbg with uvx, which downloads the pinned version from PyPI the first time it runs. You still need Windows, CDB, and uv, but you do not need to install the Python package yourself.

The existing pip install mcp-windbg setup remains available for other MCP clients and for anyone who prefers a manual configuration.

Skills for Common Debugging Tasks

The plugin includes four skills:

analyze-dump guides the analysis of a Windows crash dump.
debug-remote works with a live user-mode target through CDB.
kernel-debug handles live kernel debugging with KD.
windbg-doctor checks the local setup when CDB, KD, symbols, or the MCP server are not working as expected.

These skills only load when they are needed, which keeps the plugin's normal context use small. The underlying MCP tools are still available directly when you want to run a specific command or control a session yourself.

The Crash Analyst Agent

The plugin also includes a read-only crash-analyst agent. It can investigate a dump independently and return:

its likely cause
the debugger evidence supporting that conclusion
alternative causes it checked
practical next steps

The agent is kept away from mutating tools. It can inspect a debugging session, but it cannot resume a target or perform another action that would change its state.

Symbols by Default

Readable stack traces depend on symbols, and missing symbol configuration is a common source of poor results. The plugin now provides the Microsoft symbol server as the default value for _NT_SYMBOL_PATH.

If you already have _NT_SYMBOL_PATH configured, the plugin leaves it unchanged. Existing private symbol servers and custom cache paths therefore continue to work.

A Small 1.2.1 Follow-up

Version 1.2.1 followed later the same day. It reorganized the README installation guide by client and fixed a corrupted C:\dumps\app.dmp example that contained a hidden control character. There were no runtime changes, so it does not need a separate post.

Getting Started

Use the two plugin commands above for Claude Code, or upgrade the Python package for another MCP client:

pip install -U mcp-windbg

See the full release notes for v1.2.0 and v1.2.1. The source and plugin marketplace are available in the mcp-windbg repository.

🚀 New Release: mcp-windbg 1.1.0

2026-08-26T00:00:00+00:00

Version 1.1.0 of mcp-windbg is out. It's the first release since 1.0.0, which was broken on fresh installs for some time.

What Happened: 1.0.1

The dependency was mcp>=1.28.1 with no upper bound. When the MCP Python SDK shipped 2.0.0 - renaming McpError to MCPError and dropping the @server.list_tools() decorator - every fresh install broke at import:

ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'

Existing installs worked fine; only new ones broke. That's the worst kind of bug: invisible to anyone who could report it. 1.0.1 capped the requirement at <2.0.0. Thanks to @aphroteus for the fix and @arjunarjun07 for finding the cause.

If you're still on 1.0.0, run pip install --upgrade mcp-windbg. Any pip install "mcp<2" workaround can go.

Support for the 2.x SDK

A cap is a stopgap, not a fix. 1.1.0 runs on mcp>=2.0.0: handlers are passed straight to Server(...) instead of registered via decorators, and they return the SDK's result types (ListToolsResult, CallToolResult).

Nothing changes for clients - same tools, same schemas, stdio and streamable-http both work as before. Python support is unchanged (the 2.x SDK wants 3.10+, like this project already did).

Two changes so the next SDK release is boring instead of another five silent weeks:

All runtime dependencies are capped at the next major version. Without a ceiling, moving to 2.x would have left the same trap for 3.0.0. Since mcp-windbg is an application, not a library, upper bounds can't conflict with anything downstream - a breaking SDK release just becomes a failing CI run.
A weekly canary tests what users actually get. CI installed from uv.lock, so it only tested pinned versions, while real installs resolve whatever the ranges allow. The canary ignores the lock, installs the newest allowed versions, and runs the test suite every Monday. It's scheduled rather than tied to pull requests on purpose: an upstream break should page me, not block someone's unrelated PR.

`wait_for_break`

The one new tool. Resume a target with g, go do something else, then call wait_for_break to block until it stops again - breakpoint, bugcheck, or CTRL+BREAK. It returns everything the debugger printed along the way.

If the wait expires, the target keeps running. Waiting never halts your machine behind your back.

Fixing `g` Freezing the Target

This was bad and hid for a while, so let me be honest about it.

Go-class commands (g, gh, gn, gN, gc, gu) hand control back to the target, after which the debugger stops reading stdin. The server queued an .echo marker behind the g, which never got answered - so the command sat until timeout, and the timeout's CTRL+BREAK halted the target again. Ask the machine to run, get it frozen a minute later. The opposite of what you asked for.

Go-class commands are now sent bare and return immediately. Step commands (p, t, pa, ta, ...) are unaffected.

Fixing that exposed several related problems:

A command right after g breaks in cleanly. No manual send_ctrl_break, and the target's output isn't thrown away.
A break-in sent immediately after g no longer gets lost. Resuming used to return before the debugger read the g, leaving a window where a CTRL+BREAK hit the prompt instead of the target. Against a live KDNET target, a break sent with no gap was lost every single time. The resume is now confirmed consumed before reporting success.
Break-in checks before signaling. A CTRL+BREAK aimed at an already-stopped target would queue and re-halt it later. The session now probes for a prompt first and only signals if there's no answer, making speculative send_ctrl_break calls safe.
bp nt!X; g reports whether the breakpoint was set. A typo'd symbol now shows up as Couldn't resolve error instead of an endless wait.
One operation per session at a time. wait_for_break parks on a worker thread while the server keeps answering other requests; a second call on the same session is refused immediately. Closing a session also ends any wait parked on it.
Kernel sessions over named pipe or serial connect. kd announces those links with a different message than KDNET, and only the latter was matched - so sessions that were actually attached timed out.

Getting Started

Still one line:

pip install mcp-windbg

Release notes: v1.1.0 - Docs: svnscha.github.io/mcp-windbg - Source: github.com/svnscha/mcp-windbg

Summary

No headline features here. Just a dependency cap, a canary, one new tool, and a long list of places where the debugger and the server disagreed about who was talking. That's what a .1 release should be - especially after a 1.0.0 nobody could install.

If mcp-windbg has helped you, I'd love to hear about it. Open an issue, reach out, or star the repository. Thank you.

🚀 New Release: mcp-windbg 1.0.0

2026-07-16T00:00:00+00:00

I've just released version 1.0.0 of mcp-windbg. Yes, one-point-zero. The headline: your AI assistant can now debug the Windows kernel. The fine print: every tool has a new name, so bring your prompts. Both below.

Kernel Debugging

Three new tools, open_kd_session, run_kd_command, and close_kd_session, drive kd.exe against a live kernel target over the connections you would actually use:

KDNET (net:port=...,key=...)
Named pipes (com:pipe,port=\\.\pipe\...) - the classic VM setup
Serial - because sometimes it is 2003 in your lab and that is fine

Point your assistant at a VM, ask what that driver is up to, and let it run !process, !irql, lm, and friends while you have your coffee.

A kernel target is not a dump file: break in at the wrong moment and you have halted an entire machine. The tools are built around that reality:

Sessions arrive already stopped. open_kd_session waits for the connect banner and breaks in for you.
Closing resumes the target. close_kd_session sends g by default; pass resume: false only if you want the machine frozen on purpose.
--kd-path points the server at a specific kd.exe, the counterpart to --cdb-path.

There are also two new guided prompts to go with it: kernel-triage investigates a kernel target (including telling a real bugcheck apart from a plain break-in, and releasing the machine at the end), and remote-triage does the same for a live user-mode process.

Session IDs

The other big change: sessions are now first-class. Every open_* tool returns an opaque session ID (cdb-… or kd-…), and run_*, close_*, and send_ctrl_break address a session by that ID. No more implicit sessions, no more addressing by dump path: open first, then talk. Opening the same dump twice gives you two independent sessions.

The kind is enforced, too: pass a cdb ID to run_kd_command and you get an error naming the right tool. That matters more than it sounds when the caller is a model that occasionally guesses.

The Breaking Changes

The old names conflated the product (WinDbg) with the engines doing the work (cdb.exe for user mode, kd.exe for kernel). That distinction is now load-bearing, so everything got renamed:

0.x	1.0.0
`list_windbg_dumps`	`list_dumps`
`open_windbg_dump`	`open_cdb_dump`
`open_windbg_remote`	`open_cdb_remote`
`run_windbg_cmd`	`run_cdb_command` / `run_kd_command`
`close_windbg_dump`, `close_windbg_remote`	`close_cdb_session`

Also: send_ctrl_break takes a session_id, and the connection_type parameter is gone because the tool name now says which engine you mean. If you have prompts or agent instructions written against the 0.x names, they need updating - that is exactly why this is 1.0.0 and not 0.16.0. The docs are rewritten around the new flow, including a "Debug a kernel target" guide.

Smaller, But You Will Notice

Per-call timeouts: timeout_seconds on any open_* / run_* overrides that tool's default. Useful when that one !analyze -v against a 30 GB dump needs its time.
A slow command no longer wedges the session. On timeout the server breaks in with CTRL+BREAK and resynchronizes, so the session is usable for the next command instead of stranded.
Output goes to the right command. Every command waits on its own unique completion marker, so late output from a slow command can never be mistaken for the next one's result.
No more orphaned debuggers. cdb.exe launched via the Microsoft Store aliases spawns a child that a plain terminate left behind, still holding the target. Shutdown now kills the whole process tree.

Getting Started

Still a one-liner:

pip install mcp-windbg

Full release notes are on the v1.0.0 release page, and the project lives at github.com/svnscha/mcp-windbg. A star is always appreciated.

One-Point-Zero

Fourteen months ago this was a weekend experiment. Today it sits at 1.4k stars and debugs kernels. Calling it 1.0 is a promise more than a milestone: the names are stable now, and breaking changes from here on will be rare and loud.

Here is to stable.

If mcp-windbg has helped you, I would love to hear about it. Reach out, open an issue, or just star the repository. Thank you all.

🚀 New Release: mcp-windbg 0.15.0

2026-06-09T00:00:00+00:00

I've just released version 0.15.0 of mcp-windbg. It has been a while since the 0.12.2 post, and three releases have landed since then. Rather than a single feature, this is a round-up of everything that has shipped: a way to break into a running session, a hook to scrub sensitive data before it ever reaches the model, and a proper documentation site to tie it all together.

What's New

Break into a live session

If you have used a real debugger, you know the moment: the process is spinning, you want to know what it is doing right now, and you reach for CTRL+BREAK. That now works through the MCP interface too.

The new send_ctrl_break tool, contributed by @GeoYS, interrupts an active CDB/WinDbg session, for both dump and remote debugging workflows. So when you are driving a live target and it wanders off into a tight loop or a long wait, the model can break in, inspect the state, and carry on, the same way you would at the keyboard. This closes a real gap: before, a live session that was busy was a session you could only wait on.

Redact sensitive data before it leaves the machine

Crash dumps are full of things you might not want to hand to a model: file paths with usernames, machine names, environment variables, command lines, sometimes worse. The new --filter-script option lets you point the server at a trusted Python helper that can rewrite string-valued tool arguments and tool text output on the way through.

The important part is the boundary. Your script only sees the string values, not the full MCP protocol messages, so you can do focused PII redaction (mask a username, strip a token, normalize a path) without writing a protocol-aware proxy. If you run a centralized analysis service, this is the piece that lets you control what actually crosses the wire.

A real documentation site

The project has outgrown a README and a wiki. There is now a proper documentation site built with MkDocs Material and deployed to GitHub Pages. It covers getting started, the individual use cases, and a reference for the command-line options, the tools, and client configuration.

A few highlights worth calling out:

Use-case guides for the things people kept asking about: running the server over HTTP to debug from another machine, and scrubbing tool output to redact sensitive data.
The built-in dump-triage prompt is now documented, including its dump_path argument, so you can trigger a full structured triage without hand-writing the workflow.
Honest limitations are written down rather than discovered the hard way: the HTTP transport has no authentication, attach-by-PID is not supported, and sessions run concurrently.

Quieter, sturdier foundations

This release also includes several smaller changes that matter in daily use:

The stdio transport no longer crashes on a malformed input line. A single unparseable line used to tear down the whole process; now it is logged and the server keeps running.
The test suite was rebuilt as a declarative end-to-end harness. Every scenario runs against a really-hosted python -m mcp_windbg server driven by a real MCP client, with only the LLM faked. Coverage now sits above 90 percent, measured in the subprocess where tool dispatch actually runs.
Package metadata is complete, so pip show and the PyPI page now carry the author, project URLs, and proper classifiers.
Symbols resolve more often out of the box: the dump's own directory is now auto-included in the symbol search path, so PDBs sitting next to a dump are found without extra configuration.

Community Contributions

This stretch of releases leaned on the community, and two contributions stand out:

@GeoYS added the live break-in feature in #40, which became the send_ctrl_break tool above. It is the headline of the 0.13.0 release.
@SSyl made symbols just work in more cases by auto-including the dump directory in the symbol search path (#41).

This is exactly the kind of contribution that makes a tool better for everyone, not just the person who filed it. Thank you both.

Getting Started

Installation is unchanged and still a one-liner:

pip install mcp-windbg

The project is open source and available on GitHub at https://github.com/svnscha/mcp-windbg. If you find it useful, a star on the repository is always appreciated.

A Year and a Month In

It is hard to believe, but mcp-windbg is now a year and a month old. When I first wrote about it in May 2025, it was a weekend experiment to scratch my own itch: I was tired of typing the same WinDbg commands over and over, and I wanted to see whether a model could drive the debugger for me. I genuinely did not expect it to go anywhere.

It went somewhere. The repository now sits at 1.4k stars, the original article reached tens of thousands of readers in its first days, and the project has shown up in conversations, talks, and threads far beyond anything I planned. People have used it to triage real production crashes, wired it into team workflows, and sent screenshots of it cracking bugs that had been open for weeks. Every one of those still makes my day.

What has meant the most, though, is not the numbers. It is the people. Contributors who saw a gap and just fixed it. Folks who filed thoughtful issues, asked sharp questions, or pushed back when something did not work the way they needed. The many of you who reached out directly, by email, on LinkedIn, in DMs, to say the tool saved you an afternoon, or to suggest where it should go next. A project like this is only as good as the community around it, and this one has been generous well beyond what I could have hoped for.

So this is mostly a thank-you note. Thank you for the stars, the pull requests, the issues, the messages, and for trusting a small open-source tool with your hardest crashes. You are the reason it keeps getting better, and the reason I keep shipping.

Here is to the next year.

If mcp-windbg has helped you, I would love to hear about it. Reach out, open an issue, or just star the repository. Thank you all.

🚀 New Release: mcp-windbg 0.12.2

2025-12-15T00:00:00+00:00

I've just released version 0.12.2 of mcp-windbg, bringing some significant enhancements that expand how and where you can perform crash dump analysis.

What's New

This release introduces two major features that address the flexibility and deployment needs many of you have been asking about.

First up is support for the Prompts API, which fundamentally changes how you can interact with crash dump analysis. Rather than being tied to a local setup, you can now trigger triage analysis from anywhere in your environment. The server can be deployed on any machine in your network, whether that's a dedicated analysis box, a build server, or even directly on a file server hosting your crash dumps. This means you can centralize your debugging infrastructure and access it from wherever you're working.

Second, this release adds streamable-http as an alternative transport backend. This gives you more options for how the server communicates, particularly useful in containerized or networked environments where different transport mechanisms might be preferable.

The combination of these features means you can now set up a centralized crash analysis service that developers across your team can leverage without needing to install WinDbg or configure everything locally. Want to analyze dumps directly on the file server where they're stored? Now you can.

Getting Started

If you want to try out the latest version, installation is straightforward:

pip install mcp-windbg

The project is open source and available on GitHub at https://github.com/svnscha/mcp-windbg. If you find it useful, a star on the repository is always appreciated.

A Real-World Example

No release post would be complete without putting the tool to work on an actual crash dump. Here's an example of the analysis in action:

Even Copilot needs a debugger sometimes.

🚀 New Release: mcp-windbg 0.10.0

2025-10-11T00:00:00+00:00

mcp-windbg 0.10.0: Now Available on PyPI

Five months after the initial release of mcp-windbg, I'm releasing version 0.10.0 with significant improvements and simplified deployment.

mcp-windbg is now officially available on PyPI. Installation no longer requires cloning repositories or setting up development environments:

pip install mcp-windbg

This represents a significant simplification from the original setup process described in my first article.

Additionally, mcp-windbg is now listed on the official Model Context Protocol registry, which should improve discoverability and enable integrations with various MCP-compatible tools.

Release 0.10.0: Key Features and Improvements

Version 0.10.0 incorporates community feedback and focuses on improving usability across different experience levels with debugging tools.

New Features

Live Debugging Sessions

Added open_windbg_remote and close_windbg_remote functions
Support for connecting to live processes beyond crash dump analysis
Real-time debugging through conversational AI interface

Extended Dump File Support

Full compatibility with .mdmp and .hdmp formats
Microsoft Store WinDbg CDB compatibility
Improved automatic discovery of crash dump files

Development Infrastructure

Migrated to uv package manager for improved build performance
Significantly reduced development setup and build times
Streamlined dependency management

Community Contributions

@sooknarine contributed several key improvements that made this release possible:

#6: Find local dumps with other common extensions - Enhanced automatic discovery of crash dump files
#10: Add support for remote debugging - Implemented live debugging session support

These contributions demonstrate the value of community involvement in open source development.

Infrastructure Improvements

Several behind-the-scenes improvements enhance reliability and maintainability:

Continuous Integration: Automated testing across Python versions 3.10 through 3.14
Dependency Management: Automated security updates and dependency maintenance
Release Process: Streamlined deployment for faster delivery of updates

Documentation Updates

The documentation has been restructured for better usability:

AGENTS.md: Comprehensive debugging instructions specifically for AI assistants
Structured Templates: .github/prompts/dump-triage.prompt.md for consistent crash analysis (inspired by my prompt engineering article)
Repository Wiki: All documentation now lives in an easily searchable wiki
Simplified README: Focused on getting you started in minutes, not hours
This Changelog: So you know what's changing and why

Installation: From Tedious to Trivial

Remember the old installation process? Clone, setup virtual environment, install dependencies, configure paths... ugh.

Here's the new process:

# Install mcp-windbg
pip install mcp-windbg

# That's it. Seriously.

Then add this to your .vscode/mcp.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"
			}
		}
	}
}

The installation process is now considerably simplified compared to the previous manual setup requirements.

Next Steps

With 0.10.0 released, these are the next areas I plan to work on:

More AI integrations beyond VS Code
Enhanced live debugging capabilities
Performance optimizations for large dump files
Community-requested features (keep them coming!)

The development roadmap will continue to incorporate community feedback and feature requests.

Getting Started

To begin using mcp-windbg 0.10.0:

Install: pip install mcp-windbg
Configure: Add the MCP server to your VS Code configuration
Use: Load crash dumps and interact through natural language queries
Contribute: Report issues, suggest features, or contribute code improvements

Links:

Community Response and Impact

Since the initial release in May, the project has received significant community engagement. The original article generated over 40,000 page views within the first two days, along with thousands of LinkedIn impressions and direct messages from developers worldwide.

The feedback has been constructive and encouraging. Developers have shared how the tool helped reduce time spent on crash analysis, and several teams have integrated it into their debugging workflows. I've had opportunities to present this work both internally and externally, leading to valuable discussions about AI-assisted development tools.

The open source community response has been particularly gratifying. Contributors like @sooknarine have stepped in to add functionality that benefits all users. The GitHub repository has gained considerable attention, and the project's inclusion in the official MCP registry should further improve its discoverability.

Building something that genuinely helps other developers solve real problems has been rewarding beyond what I expected when I first started working on this as a way to improve my own debugging workflow.

Thanks to everyone who has contributed, shared feedback, or simply tried the tool. The community response has made this project much better than it would have been otherwise.

AI Meets WinDBG: A Different Way to Analyze Crashes

2025-05-04T00:00:00+00:00

Old Meets New: Bringing Crash Analysis into 2025

Let's face it - while the rest of software development has evolved at warp speed, crash dump analysis feels like it's been preserved in digital amber for decades. We've got self-driving cars and pocket-sized supercomputers, yet here we are, still pecking away at command prompts like it's the dawn of the internet. Why is debugging the only area where we cling to tools that look like they belong in a computer history museum?

Picture this: You, a professional software engineer in 2025, hunched over a terminal, manually typing arcane commands like !analyze -v and .ecxr, squinting at hexadecimal memory addresses, and mentally translating stack traces. All while your friends in other industries are delegating their work to AI assistants that can write entire documents, create art, or automate complex workflows.

Something's wrong with this picture, right?

I wanted a simpler workflow: ask questions in plain language and let an AI assistant run the relevant debugger commands. This is more than a new interface for WinDBG; it changes how you interact with the debugger.

When Inspiration Strikes

During a debugging session at work, I had one of those lightning bolt moments. What if - and stick with me here - we could apply the same AI-assisted "vibe coding" approach to crash dump analysis?

Picture this: instead of manually slogging through memory dumps and command outputs, you simply ask, "Hey, why did this application crash?" and get an intelligent, contextual answer that actually helps you solve the problem.

The idea was too compelling not to pursue. So I built it.

See It In Action: AI-Powered Crash Analysis

Before diving into the technical details, let me show you what this looks like in practice. I have prepared a demo application to showcase two different use cases:

Video 1: Crash Analysis and Automated Bugfix

In this video, I show how Copilot can analyze a crash dump, identify the bug and auto-fix the issue.

Your browser does not support the video tag.

As you can see in the video, instead of manually running WinDBG commands and interpreting the cryptic output, I'm having a natural conversation with GitHub Copilot. The AI quickly identifies that the application crashed, explains which specific conditions led to the crash, and suggests a fix.

Video 2: Automated Crash Dump Analysis of multiple crash dump files

This video demonstrates a different capability: analyzing multiple crash dump files at once. It shows how the tool can quickly identify which dumps belong to your application and which don't.

Your browser does not support the video tag.

Worth noting, it takes just a few seconds until you get your first useful answer. I've played around with this for many hours and let me tell you one thing: You can really go deep. If you ask the right questions, the AI runs WinDBG/CDB commands that I haven't seen in all these years of debugging, and that is simply amazing.

How can this help the industry?

I believe this is one of the really good examples of how AI can boost productivity. Analyzing crash dumps is a very tedious task. It begins with quickly checking and identifying whether crashes are the same or different, and often requires very advanced knowledge when a crash is challenging - really challenging.

Copilot can help here tremendously; it knows how to:

Interpret assembly code (without you having to remember what EAX stands for)
Check memory contents (so you don't have to count hex bytes on your fingers)
Traverse structures with symbols (goodbye to manual pointer arithmetic!)
And so much more

This can help engineers, support teams, and QA staff work with crash dumps without memorizing every debugger command.

How did I build this?

If you've ever worked with WinDBG, you know the drill: cryptic commands, obscure syntax, and endless scrolling through memory addresses and stack traces that make your eyes glaze over. It's the kind of specialized knowledge that takes years to master and feels like speaking an alien language even when you do.

The trick here is connecting WinDBG with AI. To do that, you first need to programmatically control a debugging session, right? There are plenty of options on how to do this. I prefer to keep things simple, so I have chosen CDB, which is Microsoft's Console Debugger. It operates on standard input and output, and that's so much more fun to deal with than setting up COM APIs or similar approaches.

The second part is "connecting with AI." That's where Model Context Protocol Servers come into the game.

Understanding Model Context Protocol Servers

MCP is an open standard developed by Anthropic, released in November 2024. This protocol allows AI models to interact with external tools and data sources - think of it as giving AI assistants "hands" to work with other software. It defines a way for AI assistants to discover, access, and use tools through a consistent interface. In essence, it's what allows GitHub Copilot to "talk" to external programs like WinDBG.

An MCP server acts as the intermediary between the AI model and the tool. It:

Registers available tools with the client
Handles requests from AI models to use these tools
Executes the tool operations and returns results
Maintains context across interactions

Any tool can be made available to an AI model through an MCP server. I built one for WinDBG's CDB debugger.

Why MCP Instead of LanguageModelTool API?

The LanguageModelTool API might eventually be a better fit for this specific use-case. Creating a Visual Studio Extension that "just works" out of the box would potentially simplify the integration process significantly.

However, using MCP directly offers several notable advantages. It works with any AI model, not just limiting itself to Copilot. The server can be used outside VS Code, functioning with various other tools. New features can be easily added without necessitating changes to the core integration. Moreover, it remains platform-independent, avoiding lock-in to any single company's implementation.

The MCP-WinDBG Project

I've implemented a Model Context Protocol server that wraps WinDBG/CDB and exposes its capabilities to AI models within VS Code. Better yet, I've made it open source so everyone can experience this new workflow.

The project, mcp-windbg, connects VS Code and GitHub Copilot to WinDBG's analysis commands.

The actual "hard part" was implementing the CDB (Command-Line WinDBG) interaction layer. And by "hard", I mean vibe-coding with two coffees on a Saturday morning, where I spent more time being annoyed by pyTest failures than actual coding difficulties. The core implementation came together surprisingly quickly!

The rest is primarily wrapper code that implements the Model Context Protocol specifications. Now that I've established and defined the core WinDBG interaction logic, I'm considering refactoring the project to TypeScript. This would enable me to create both an MCP Server in TypeScript and a dedicated Visual Studio Extension, with both implementations leveraging the same underlying CDB interaction layer.

What Does This Mean In Practice?

Let me walk you through what this enables:

Natural language crash analysis: "Why is this application crashing with an access violation at this address?" (Instead of: "What the $%#@ is this heap corruption!?")
Contextual debugging: "Show me the stack trace for thread 5 and explain what each function is doing based on the symbols." (Instead of staring at call stacks like they're ancient hieroglyphics)
Root cause identification: "What's causing this null pointer dereference and where should I look in the code to fix it?" (Instead of playing detective with memory addresses)

Instead of typing obscure commands like !analyze -v followed by a series of manual investigations, you simply ask questions in plain language, and the AI interprets the crash data for you. It's like having a WinDBG expert whispering in your ear, except it doesn't get annoyed when you ask the same question five times.

How It Works

The MCP server connects GitHub Copilot to WinDBG:

It provides a set of tools that Copilot can use to interact with crash dumps
It translates natural language questions into appropriate WinDBG commands
It parses and interprets the often cryptic WinDBG output into more useful information
It maintains context throughout a debugging session, enabling follow-up questions to work naturally

The technical implementation uses Python to spawn and communicate with CDB (the command-line version of WinDBG), parses the output, and exposes the functionality through the Model Context Protocol to VS Code.

Getting Started With mcp-windbg

Ready to try it yourself? Here's how to get started:

First, make sure you have the Windows SDK installed with Debugging Tools for Windows
Clone the repository: git clone https://github.com/svnscha/mcp-windbg.git
Set up a Python virtual environment and install the package
Configure VS Code to use the MCP server

For complete details, check out the repository README.

Once configured, create a .vscode/mcp.json file in your project that points to the server:

{
    "servers": {
        "mcp_server_windbg": {
            "type": "stdio",
            "command": "python",
            "args": [
                "-m",
                "mcp_server_windbg"
            ],
            "env": {
                "_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
            }
        },
    }
}

You might need to update the command, depending on where and how you have installed the mcp_server_windbg to.

The Human Touch Still Matters

Just like with code refactoring, the AI assistance isn't perfect. The human element - your experience, intuition, and domain knowledge - remains crucial. Sometimes you'll need to guide the analysis, ask follow-up questions, or provide additional context.

The useful part is the combination: AI can process a large amount of debugger output quickly, while you provide the context needed to judge the result. It still needs supervision and can follow the wrong lead, so treat its findings as a starting point rather than a final answer.

Join The Experience

I'd love for you to try this out, contribute to the project, and share your experiences. If you're interested:

Star the GitHub repository
Try it on your own crash dumps
Report issues, suggest improvements, or contribute code
Share your success stories (or even failures - we learn from those too!)

The Magic Is In The Flow

Just like with my code refactoring experience, the real magic isn't about any single capability - it's about the flow. When debugging stops being a tedious chore and becomes a fluid conversation, something fundamentally changes in how you approach problem-solving.

Gone are the days of dreading crash analysis. Instead, each debugging session becomes an opportunity for collaboration with an AI partner that helps you understand what's happening at a deeper level.

Summary

Crash dump analysis has traditionally been one of the most technically demanding and least enjoyable parts of software development. It's like archaeology with a keyboard - painstakingly excavating through layers of memory and CPU state to unearth what went wrong. With AI assistance through tools like mcp-windbg, it becomes another area where we can experience that perfect "vibe state" of frictionless problem-solving.

If you're still manually typing WinDBG commands and squinting at memory dumps in 2025, you're not just missing out on productivity - you're missing out on a fundamentally more enjoyable way to work.

Try it. Debug it. Vibe it.

svnscha - crash-analysis

🚀 New Release: mcp-windbg 1.3.0

Three Separate Plugins

Skills and Agents for Your Existing Server

Upgrading from the Bundled Plugin

🚀 New Release: mcp-windbg 1.2.2

The Problem

What Caused It

The Fix

Getting Started

🚀 New Release: mcp-windbg 1.2.0

Installing the Plugin

Skills for Common Debugging Tasks

The Crash Analyst Agent

Symbols by Default

A Small 1.2.1 Follow-up

Getting Started

🚀 New Release: mcp-windbg 1.1.0

What Happened: 1.0.1

Support for the 2.x SDK

wait_for_break

Fixing g Freezing the Target

Getting Started

Summary

🚀 New Release: mcp-windbg 1.0.0

Kernel Debugging

Session IDs

The Breaking Changes

Smaller, But You Will Notice

Getting Started

One-Point-Zero

🚀 New Release: mcp-windbg 0.15.0

What's New

Break into a live session

Redact sensitive data before it leaves the machine

A real documentation site

Quieter, sturdier foundations

Community Contributions

Getting Started

A Year and a Month In

🚀 New Release: mcp-windbg 0.12.2

What's New

Getting Started

A Real-World Example

🚀 New Release: mcp-windbg 0.10.0

mcp-windbg 0.10.0: Now Available on PyPI

Release 0.10.0: Key Features and Improvements

New Features

Community Contributions

Infrastructure Improvements

Documentation Updates

Installation: From Tedious to Trivial

Next Steps

Getting Started

Community Response and Impact

AI Meets WinDBG: A Different Way to Analyze Crashes

Old Meets New: Bringing Crash Analysis into 2025

When Inspiration Strikes

See It In Action: AI-Powered Crash Analysis

Video 1: Crash Analysis and Automated Bugfix

Video 2: Automated Crash Dump Analysis of multiple crash dump files

How can this help the industry?

How did I build this?

Understanding Model Context Protocol Servers

Why MCP Instead of LanguageModelTool API?

The MCP-WinDBG Project

What Does This Mean In Practice?

How It Works

Getting Started With mcp-windbg

The Human Touch Still Matters

Join The Experience

The Magic Is In The Flow

Summary

`wait_for_break`

Fixing `g` Freezing the Target