windbg-mcp: Skill for Claude Code

Running the test tiers

The pass count does not say which tiers ran. Each gate is inside its test, so the mcp_smoke harness reports the same 99 passed with the debugger tier off as with it on — that harness's own result line, since a plain cargo test runs the crate's several hundred unit tests beside it and prints a result line per binary. What differs between the two runs is the runtime (measured on the ARM64 bench 2026-08-23: 1.6s against 61s for cargo test --test mcp_smoke) and the SKIPPED lines, which only --nocapture prints. Read one of those two before believing a run covered a debugger claim. The count moves whenever a test is added — it was 69 until #195 and #196, 75 until item 37, 79 until the TTD tier, 84 until item 50's version-resource test, 85 until item 48's two endings, 87 until item 49's live 32-bit target, 88 until item 51's attach teardown, 89 until the 32-bit worker's version resource, 90 until #66's symbol-path default, 91 until #83's two asynchronous-execution tests, 93 until #85's module-inventory refresh, 94 until the session fuzz, 95 until item 55's retired-handle teardown, 96 until item 14's watchdog-cost guard and 98 until #273's worker-console assertion — and it said 83 while it was 84, 90 while it was 91, 93 while it was 94, and 97 while it was 98, which is the usual state of it, so re-derive it rather than trusting this sentence.

And a gate can be a directory beside the exe, which prints no SKIPPED line at all. The debugger tier's !analyze assertions are inside if analysis["ran"] == true, and ran is false without winext\ext.dll — which ci.yml does not copy (it takes dbghelp.dll and symsrv.dll and no extension directory), so every !analyze claim in that tier is vacuous on both CI runners and a green matrix says nothing about any of them. Restoring the extensions on this bench on 2026-08-30 immediately failed a fixture that had been passing for want of ever running. Its premise was wrong in the instructive direction: the two driver crashes were described as disagreeing about !analyze's attribution because MessageManager has no PDB and HEVD ships one. Measured on one engine against both dumps, they do not disagree — what decides it is triage\triage.ini (present: each names its driver; absent: both Unknown_Module; no winext\: ran: false), and the missing PDB costs the function, which is not what the test read. So analyze_can_attribute_a_module() asks the host and both branches assert, and docs/smoke-test.md carries the table. Two rules fall out. A fixture whose expected value differs per fixture is worth a second look when the thing being measured is the engine — one fixture would have been enough to notice. And bundling the engine changes what the tier covers, so re-run it after a setup.md copy rather than assuming a green run transfers.

The dev exe can be locked too, and the failure is quiet. A worker left running — a driver script that died mid-session, a debugger tier killed partway — holds target\debug\windbg-mcp.exe, and cargo build then fails at the final replace step with Access is denied (os error 5) while everything before it succeeded. If you are driving the binary by hand rather than through cargo test, the next run silently executes the old code, which reads as the change not working. Kill it by path, not by name: the registered release server is the same image, and taking it down with /IM drops every session it holds — which for a live kernel leaves the guest frozen (see the KDNET notes in .claude/skills/live-kernel/SKILL.md). Only the processes under target\debug:

Get-Process windbg-mcp -ErrorAction SilentlyContinue |
  Where-Object { $_.Path -like '*\target\debug\*' } | Stop-Process -Force

Then re-read the build output before believing a behavioural result. Note cargo clippy and cargo test --bins do not refresh that exe: clippy only checks, and the test harness is a separate binary.