🚀 New Release: mcp-windbg 1.3.1

Version 1.3.1 of mcp-windbg is out. It's a bug fix release about the moments when the debugger is slow, stuck, or gone, which is exactly when you need it to behave.

Three of the four fixes were contributed by the community. Thanks to @adity982, @Oscar-Williams, and @RamanaIntel for the pull requests, and for the tests that came with them.

Break-In While a Command Is Running

Until now, a tool call that waited on the debugger held up every other tool call. A slow !analyze -v or a wait_for_break on a running kernel target meant that send_ctrl_break, the one tool meant to get you out of that situation, sat in the queue behind it (issue #109).

@adity982 moved debugger startup, commands, and shutdown onto worker threads in #110. send_ctrl_break stays on the request loop, so it gets through even when every worker is busy. Two close calls on the same session also no longer race: the first one closes it, and the second is told the session is gone.

Partial Output When a Command Times Out

SOS !clrstack can get stuck printing the same ComMethodFrame over and over. The server used to wait for the command to finish, hit the timeout, and throw away everything it had read, including the useful frames at the top (issue #112).

With @Oscar-Williams' fix in #114, the timeout error includes the output read so far. It's capped at 2,000 lines and 64 KiB, so a runaway command can't flood the model's context with the same frame a few thousand times.

A Debugger That Exits Is Reported Right Away

When cdb.exe or kd.exe exited, nothing noticed. Typing q, a mistyped -remote server, a bad -k connection string, or the debugger itself crashing all ended the same way: every pending call waited out its full timeout, which is up to five minutes for wait_for_break, and then reported a timeout.

@RamanaIntel's #115 watches for the debugger's output to end. The error now arrives immediately with the exit code and the debugger's last lines, which usually say what went wrong:

Debugger process exited (exit code 0x80070057) before the kernel target connected.
Last debugger output:
...
Kernel debugger failed initialization, Win32 error 0n87
    "The parameter is incorrect."

Commands on a session whose debugger has exited now fail straight away and tell you to open a new session.

No More Stack Traces in Tool Errors

I found this one while testing the release. Every tool error carried a full Python stack trace, and the last line of that trace repeats the error message. With partial output in the message, a single timeout on !process 0 7 came back as 133 KB of text, all of it twice. Debugger errors now return only their message, and that same timeout comes back at 61 KB.

Tested Against a Real Kernel Target

CI has no kernel target, so before releasing I ran the kernel scenarios and a set of end-to-end checks against a Hyper-V VM over KDNET. Through a real MCP client:

• send_ctrl_break answered immediately while !process 0 7 was running and cut a command with a three-minute timeout down to five seconds.
• Other tools answered while wait_for_break was blocking, and a break-in ended the wait.
• A bad -k string failed in 0.2 seconds with kd's own error message instead of a connect timeout.

One thing worth knowing from that testing: running q in a kernel session ends kd.exe, but the target machine stays halted at the break. mcp-windbg now tells you the debugger exited, but to leave the machine running, use close_kd_session instead, which resumes the target by default.

Upgrading

pip install -U mcp-windbg

If you use the Claude Code plugin, update it:

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

See the full v1.3.1 release notes for details. If a debugger session still gets stuck in a way this release doesn't cover, please open an issue.