svnscha - community

🚀 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 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.