# 🚀 New Release: mcp-windbg 1.3.1

> Break-in while a command runs, partial output on timeouts, and a debugger that exits is reported right away. Three of the four fixes came from the community.

- Published: 2026-09-30
- Author: Sven Scharmentke
- Canonical: https://svnscha.de/posts/mcp-windbg-1-3-1-release/
- Tags: ai, debugging, mcp-windbg, crash-analysis, kernel-debugging, community, release

---

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](https://github.com/adity982), [@Oscar-Williams](https://github.com/Oscar-Williams), and [@RamanaIntel](https://github.com/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](https://github.com/svnscha/mcp-windbg/issues/109)).

[@adity982](https://github.com/adity982) moved debugger startup, commands, and shutdown onto worker threads in [#110](https://github.com/svnscha/mcp-windbg/pull/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](https://github.com/svnscha/mcp-windbg/issues/112)).

With [@Oscar-Williams](https://github.com/Oscar-Williams)' fix in [#114](https://github.com/svnscha/mcp-windbg/pull/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](https://github.com/RamanaIntel)'s [#115](https://github.com/svnscha/mcp-windbg/pull/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:

```text
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

```bash
pip install -U mcp-windbg
```

If you use the Claude Code plugin, update it:

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

See the full [v1.3.1 release notes](https://github.com/svnscha/mcp-windbg/releases/tag/v1.3.1) for details. If a debugger session still gets stuck in a way this release doesn't cover, please [open an issue](https://github.com/svnscha/mcp-windbg/issues).