Reported issues for windbg-mcp

Pod holds 19 of 39 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to windbg-mcp.

Most discussed

Install with scoop

I'm already enjoying using this mcp server, thanks! 🎉

The installer is a little bit messy, and I want to be able to easily check for and install updates, so I created a scoop bucket for my "miscellaneous tools" and added windbg-mcp to it first (which takes care of all the post install steps). 😉

Note: anybody can install it using scoop as it's also [visible](https://scoop.s

Read the thread · 2026-08-12 · closed · external user · 3 comments

Support loading SOS for 32-bit .NET Framework dumps (x86 engine worker or guidance)

Problem

When a 32-bit .NET Framework process dump is opened in windbg-mcp, SOS cannot be loaded. The engine worker is x64, and the two available SOS DLLs both fail:

• 64-bit SOS (Framework64\v4.0.30319\sos.dll) loads into the x64 worker process but refuses to analyze the x86 target: SOS does not support the current target architecture (14c)
• 32-bit SOS (Framework\v4.0.30319\sos.dll) can't load at all: Win32 error 0n193 "%1 is not a valid Win32 application"

.effmach x86 i

Read the thread · 2026-08-26 · closed · external user · 2 comments

Single-tenancy and the lease are keyed on Mcp-Session-Id, which 2026-07-28 removed

What happens

Against --listen, at protocol revision 2026-07-28 — the newest this server advertises, and the one Claude Code negotiates — two clients are both served, and neither ever holds a lease.

Two independent clients at 2026-07-28 (sessions removed from the spec):
  client A tools/call -> HTTP 200  No debug session is open. Start one with open_dump / ...
  client B tools/call -> HTTP 200  No debug session is open. Start one with open_dump / ...

(a 409 for B is what the

[Read the thread](https://github.com/glslang/windbg-mcp/issues/162) · 2026-08-18 · closed · 2 comments

### An ARM64 engine cannot read virtual memory from an x64 kernel dump

Adding an ARM64 entry to the debugger tier (#141) turned up a real limitation on the first run. **41 passed, 4 failed**, and the four share one cause.

The dump opens and triages correctly. Bug check code, name and all four parameters are right, and the stack is attributed to `nt` with RVAs:

```json
"bug_check":{"code":"0x13a","name":"KERNEL_MODE_HEAP_CORRUPTION","parameters":["0x8","0xffff998228000140","0xffff99823034eb10","0x0"]},
"frames":[{"address":"0xfffff805cb8f93c0","index":0,"module":"

[Read the thread](https://github.com/glslang/windbg-mcp/issues/142) · 2026-08-16 · closed · 2 comments

### No CI coverage on ARM64, where the debugger tier would earn it

The repository now documents ARM64 hosts — `setup.md` has an ARM64 section, and the engine-bundling instructions carry an architecture warning — but nothing in CI runs on one. Both jobs that touch a debugger are `runs-on: windows-latest`, which is x64.

That gap matters most for the **debugger tier**, because that job's whole argument is that it is the only automated check of properties the architecture exists for, against a real `dbgeng.dll` and a checked-in dump. On ARM64 the engine is a diffe

[Read the thread](https://github.com/glslang/windbg-mcp/issues/134) · 2026-08-16 · closed · 2 comments

### A target exiting during the resume pump leaves the session half-dead and can take the worker down

## Summary

On launch/attach_process sessions, when the target process exits while the engine is running or being pumped to a stop after a resume, the session enters a broken state:

- the command whose release raced the exit returns only a silent echo; the pump's captured output (breakpoint banner, embedded script output) is discarded,
- thread-dependent commands (`k`, `registers`) then fail with a bare `E_UNEXPECTED` (0x80040205) while `.echo` and `.lastevent` still answer, which is indistingu

[Read the thread](https://github.com/glslang/windbg-mcp/issues/242) · 2026-08-26 · closed · external user · 1 comment

### Hosting the x86 engine in cdb -server keeps generating the same class of finding

Not a regression, and not something #239 introduced — the design it raises was chosen deliberately in #234, with the trade recorded at the time. What is new is evidence about that trade, and it accumulated fast enough to be worth writing down before the next change lands on the same seam.

## The observation

#239 puts the engine for a 32-bit dump in a `cdb.exe -server` child and drives it over DbgEng's remote transport. Across three review rounds, **seven distinct findings all landed on that on

[Read the thread](https://github.com/glslang/windbg-mcp/issues/240) · 2026-08-26 · closed · 1 comment

### execute silently swallows execution-control commands (g/p/t) — a plain Execute sets run state without pumping, and every later control call fails with 0x80040205

## Summary

The `execute` tool routes through `EngineOp::BoundedCommand` → `raw_command` → a plain `IDebugControl::Execute`. This repo's own docs say what that means (docs/tool-surface.md, "Control flow and the TTD wrappers"):

> a plain `Execute` only sets the run state — it doesn't move the target

Yet `execute` performs **no content check whatsoever**: it happily accepts `g`, `p`, `t`, compound commands like `bp X; g`, and breakpoints with embedded command strings. When any of these is issued

[Read the thread](https://github.com/glslang/windbg-mcp/issues/226) · 2026-08-25 · closed · external user · 1 comment

## Most recent

### record_trace reports a successful recording as a startup failure when the target outruns the 2.5s watch

## Summary

`record_trace` watches the recorder for 2.5s and treats **any** exit inside that window as a startup
failure. A target that runs to completion faster than that exits inside the window, so a perfectly
good recording is reported as an error:

record_trace { "target": "hostname.exe", "out_dir": "...\ttd2" } → TTD recording failed to start (exit code: 0): Launching 'hostname.exe'. Full log: ...\ttd2\ttd_record.log

The recording had in fact succeeded completely. From the same 

[Read the thread](https://github.com/glslang/windbg-mcp/issues/233) · 2026-08-25 · closed · 0 comments

### record_trace cannot pass arguments to the target, though its schema says it can - the whole command line goes as one argv entry

## Summary

`record_trace`'s `target` is documented as *"Program (with optional arguments) to launch and
record."* (`src/server.rs`, `RecordArgs`), but arguments do not work: the whole string is handed to
`TTD.exe` as a **single** argv entry, so TTD treats it as one filename and the recording never
starts.

record_trace { "target": "cmd.exe /c dir C:\Windows\System32\ntdll.dll", "out_dir": "..." } → TTD recording failed to start (exit code: 0x80004005): Launching '"cmd.exe /c dir C:\Win

Read the thread · 2026-08-25 · closed · 0 comments

ttd_calls and ttd_memory render every result as a blank row - dx without -r2 drops the fields their descriptions promise

Summary

ttd_calls and ttd_memory run dx without a recursion depth, so the data model renders each result as an index and nothing else. Every row comes back empty:

dx @$cursession.TTD.Calls("kernelbase!CreateFileW")
@$cursession.TTD.Calls("kernelbase!CreateFileW")
    [0x0]
    [0x1]
    [0x2]

The count is right and the payload is absent. Both tools' own descriptions promise the fields that are missing — ttd_calls says *"Each result carries the time, thread, parameters,

Read the thread · 2026-08-25 · closed · 0 comments

Both eval drivers handshake outside their cleanup, so a failure between initialize and initialized leaks an MCP session

Summary

handshake() is two requests — initialize, which mints the Mcp-Session-Id the server then records, and the notifications/initialized that follows it:

def handshake():
    out = mcp("initialize", {...})
    mcp("notifications/initialized", notify=True)
    return out["result"]["protocolVersion"]

Both drivers call it before the try whose finally deletes that session:

• tools/local_model_drive.py:695 — handshake; the try/finally that calls `close_

Read the thread · 2026-08-25 · closed · 0 comments

The eval matrix's row label drops the backend, so two backends sharing a model name render identically

Summary

matrix() keys a cell by backend — cell_id = (backend, model, num_ctx, surface.client) (tools/local_model_eval.py:717) — and print_matrix then throws that half away when it renders the row:

for cell, marks in sorted(rows.items(), key=lambda kv: (kv[0][0], kv[0][1],
                                                        -(kv[0][2] or 0), kv[0][3] or "")):
    backend, model, ctx, surface = cell
    label = f"{model[:24]} {str(ctx or 'dflt'):>6} {surface}"

`

Read the thread · 2026-08-25 · closed · 0 comments

outputSchema has no root type: "object" — strict TS-SDK 1.x clients reject the whole tools/list and drop every tool

Summary

Every typed tool declares its outputSchema through constraints_of (src/schema.rs), which wraps rmcp::handler::server::tool::schema_for_output and strips descriptions — but never adds a root type. Since the structured result types are serde-internally-tagged enums (Outcome<T> on "status", src/structured.rs), schemars renders each schema as { $schema, oneOf, $defs } with no root-level type.

Clients built on the official TypeScript SDK 1.x (every released version

Read the thread · 2026-08-25 · closed · external user · 1 comment

A client's identity is its name, so a re-added name is indistinguishable from its predecessor

Split out of #189, which produced five consecutive rounds of review findings on one mechanism. Each was locally real and each was fixed, but they were all the same root cause seen from a different consumer, and the last of them can only be closed here.

The property that is missing

crate::client::Client is a name — Arc<str>, compared and hashed as a string. Everything keyed on identity keys on that name:

• session ownership (`Session::ow

Read the thread · 2026-08-22 · closed · 1 comment

The listener answers a 2026-07-28 handshake and then 400s the next request

--listen negotiates 2026-07-28 and then does not serve it.

What was measured

A listener started from target\debug on the ARM64 bench, driven with a hand-written HTTP client (Invoke-WebRequest, so nothing normalises a status for us):

Read the thread · 2026-08-19 · closed · 0 comments

Flaky: the rollback's final progress notification races the end_session response

What fails

ending_a_session_stops_a_running_batch_and_rolls_it_back, intermittently, in the debugger tier:

thread 'ending_a_session_stops_a_running_batch_and_rolls_it_back' panicked at tests/mcp_smoke.rs:4955:
the rollback finished and the client was never told: ["a transaction is in flight; rolling it back (up to 2m03s)"]

The client sees the promise milestone and never the retraction. Seen four times across a working session; three consecutive full-tier runs in between were

Read the thread · 2026-08-18 · closed · 1 comment

Capture an ARM64 driver crash, so frame attribution is asserted on an ARM64 stack

#143 gave the debugger tier an ARM64 target and closed three of the four assertions that read one. The fourth — a_driver_crash_names_the_driver_frame_that_analyze_cannot — still runs against the x64 MessageManager dump on every architecture. That works (an engine with symbols reads it either way round, see #142), but it means frame attribution to a third-party driver has never been exercised on an ARM64 stack: the arithmetic that turns a captured frame into module+RVA off the load base

Read the thread · 2026-08-18 · closed · 1 comment

The result budget measures one channel, so a typed tool's text half can grow unwatched

Raised by Codex on #149, and it holds. Filing rather than fixing there: the honest fix touches what the harness claims about clients, and testing against more than one client is out of scope for now.

The gap

tool_results_stay_within_their_budget (tests/mcp_smoke.rs) reduces each result to a single number before asserting:

let model = structured.unwrap_or(text);
…
assert!(model <= *ceiling, …);

That is right for the client it was measured against — Claude Code forwards `s

Read the thread · 2026-08-17 · closed · 1 comment

The remaining reports are on the project's issue tracker.