# 🚀 New Release: mcp-windbg 1.4.0

> A quick follow-up to 1.3.1: open kernel crash dumps with open_kd_dump, and load your debugger extensions automatically with init commands.

- Published: 2026-10-01
- Author: Sven Scharmentke
- Canonical: https://svnscha.de/posts/mcp-windbg-1-4-0-release/
- Tags: ai, debugging, mcp-windbg, crash-analysis, kernel-debugging, community, release

---

Only two days after [1.3.1](/posts/mcp-windbg-1-3-1-release/), here's **mcp-windbg** 1.4.0 with two new features: you can now open kernel crash dumps, and you can have your favorite debugger extensions loaded automatically in every session.

Both ideas came from the community. Thanks to [@robster7674](https://github.com/robster7674) for suggesting kernel dump support, and to [@RamanaIntel](https://github.com/RamanaIntel) for the init commands and for giving the kernel dump tool a good workout before release.

## Open Kernel Crash Dumps

When Windows shows a blue screen, it writes a dump to `C:\Windows\MEMORY.DMP` and a small one to `C:\Windows\Minidump`. You can now hand those straight to mcp-windbg:

```text
Analyze the kernel dump at C:\dumps\MEMORY.DMP and tell me which driver bugchecked
```

The new `open_kd_dump` tool opens the dump with `kd.exe`, runs `vertarget` and `!analyze -v`, and keeps the session open for follow-up questions like `!process 0 0` or `!thread`. It works with complete, kernel, and bitmap memory dumps as well as minidumps ([#111](https://github.com/svnscha/mcp-windbg/issues/111)).

If you've used mcp-windbg for a while, this may feel familiar. Before 1.0, `open_windbg_dump` took any crash dump, kernel ones included. When 1.0 split the tools into user mode (`cdb.exe`) and kernel (`kd.exe`), the dump tool became `open_cdb_dump` and was described as user mode only. Kernel dumps still opened with it, but nothing told you so. With `open_kd_dump`, kernel dumps are officially back, with their own tool, the kernel commands, and a longer default timeout for them.

I tried it on real blue screens from a test VM, and CI now checks it against a real kernel minidump. A fresh Claude session also picked the new tool all by itself when I gave it a minidump without mentioning the word "kernel". [@RamanaIntel](https://github.com/RamanaIntel) went a step further and tested it on a 66 GB memory dump, which opened in 12 seconds. On dumps that big, some commands can take a minute or two, so pass `timeout_seconds` or raise `--timeout` if you need more time.

## Load Your Extensions Automatically

If you use your own debugger extensions, maybe an in-house `.dll` or `.loadby sos clr` for .NET, you no longer have to load them in every session. [@RamanaIntel](https://github.com/RamanaIntel)'s [#121](https://github.com/svnscha/mcp-windbg/pull/121) adds `--init-command`:

```json
"args": [
  "--init-command", ".load C:\\Extensions\\myext.dll"
]
```

The commands run as soon as a session opens, before the first analysis, so `!analyze -v` can already use your extension. You can also set them with `MCP_WINDBG_INIT_COMMANDS`, one command per line. Commands that only make sense on a kernel go into `--kernel-init-command` or `MCP_WINDBG_KERNEL_INIT_COMMANDS`, and they run only on kernel sessions and kernel dumps.

## Upgrading

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

If you use the Claude Code plugin:

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

The [MCP registry](https://registry.modelcontextprotocol.io/) now gets every new release automatically too.

The full details are in the [v1.4.0 release notes](https://github.com/svnscha/mcp-windbg/releases/tag/v1.4.0) and the [kernel dump guide](https://svnscha.github.io/mcp-windbg/scenarios/crash-dump/#kernel-dumps). Have fun with it, and if something doesn't work the way you'd expect, [open an issue](https://github.com/svnscha/mcp-windbg/issues).