Installing becomes: ``` /plugin marketplace add svnscha/mcp-windbg /plugin install mcp-windbg-uvx@mcp-windbg ``` This frees the plain `mcp-windbg` name for a self-contained build and makes room for `mcp-windbg-pipx` beside it. Doing it **before** 1.2.0 rather than after means there is no rename migration to run: the old name was never published. ## The syntax is plugin@marketplace, not the reverse Worth stating since it drove the shape here. `claude plugin install --help`: > use plugin@marketplace for specific marketplace So `mcp-windbg@uvx` would mean "plugin `mcp-windbg` from a marketplace called `uvx`" and would need three separate marketplaces. The variant has to live in the plugin name, which is what this does. ## The two names do different jobs `plugin.json`s `name` deliberately stays `mcp-windbg`. I verified the split by installing a plugin whose two names differed on purpose: | Name | Governs | Observed | | :--- | :------ | :------- | | marketplace entry | install identity, plugin cache directory | `cache/probe-mp/mcp-windbg-uvx/` | | `plugin.json` `name` | skill and MCP tool scoping | `plugin:mcp-windbg:mcp-windbg` | and a headless session confirmed the skills: ``` /mcp-windbg:analyze-dump /mcp-windbg:debug-remote /mcp-windbg:kernel-debug /mcp-windbg:windbg-doctor ``` That is the good outcome. Every future variant keeps **identical skill names, identical tool names and one set of documentation** - only the install command differs. Renaming `plugin.json` instead would have renamed every skill and every tool with it, and split the docs three ways. The distinction is recorded in CLAUDE.md, because nothing about the two fields makes it obvious. ## Also verified Installed from the real marketplace under the new name: ``` Source: mcp-windbg-uvx@mcp-windbg Skills (4) analyze-dump, debug-remote, kernel-debug, windbg-doctor Agents (1) crash-analyst MCP servers (1) mcp-windbg ``` `claude plugin validate` passes, docs typography clean, and every occurrence of the old install command across the README, plugin README, getting-started, clients, plugin reference and CHANGELOG is updated. Test state removed afterwards. ## Note on sequencing The open release PR (#91) predates this, so its 1.2.0 CHANGELOG entry still shows the old command. Once this merges I will delete the release branch and let release-please rebuild it, which is the documented way to refresh a release PR - `sync-lockfile` now re-does the lockfile commit on its own.
4.2 KiB
Getting started
This page takes you from nothing to your first crash dump analysis. It uses VS Code with GitHub Copilot. Other clients work the same way once the server is configured, see Client configuration.
!!! tip "Using Claude Code?"
Skip the VS Code steps and install the plugin instead. There is no
pip install and nothing to configure - symbols included:
```
/plugin marketplace add svnscha/mcp-windbg
/plugin install mcp-windbg-uvx@mcp-windbg
```
Then jump to [Analyze your first dump](#4-analyze-your-first-dump), or just run
`/mcp-windbg:analyze-dump`. You still need the prerequisites in step 1, plus
[uv](https://docs.astral.sh/uv/).
1. Check the prerequisites
You need a 64-bit Windows machine with:
-
Debugging Tools for Windows, which ships
cdb.exe. The simplest install is WinDbg from the Microsoft Store:winget install 9PGJGD53TN86 --accept-source-agreements --accept-package-agreementsAlternatively install the Windows SDK or WDK and tick Debugging Tools for Windows. The server auto-detects
cdb.exein the usual locations; if yours is elsewhere, you will pass--cdb-pathlater. -
Python 3.10+, then install the server:
pip install mcp-windbg -
VS Code with the GitHub Copilot extension, and MCP enabled (step 3).
!!! tip "Quick sanity check"
Confirm cdb.exe is reachable before you start:
```powershell
cdb.exe -version
```
If that fails, note the full path to `cdb.exe` and pass it with `--cdb-path`.
2. Configure the server in VS Code
Create .vscode/mcp.json in your workspace:
{
"servers": {
"mcp_windbg": {
"type": "stdio",
"command": "python",
"args": ["-m", "mcp_windbg"],
"env": {
"_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
}
}
}
}
The _NT_SYMBOL_PATH line points the debugger at the Microsoft symbol server (cached under
C:\Symbols), which is what makes stack traces readable. Adjust as needed, see
Command-line options for symbol and CDB path handling.
!!! tip "Escape backslashes in JSON"
JSON treats \ as an escape character. Write Windows paths with doubled backslashes
(C:\\Symbols) or forward slashes.
3. Enable MCP in Copilot
- Open VS Code settings (++ctrl+comma++).
- Search for MCP.
- Enable Model Context Protocol in Copilot Chat.
- Restart VS Code so it picks up
.vscode/mcp.json.
4. Analyze your first dump
Open Copilot Chat (agent mode) and ask, in plain language:
Analyze the crash dump at C:\dumps\app.dmp
Copilot calls the open_cdb_dump tool, which runs the common triage commands and returns
the crash information, the !analyze -v result, the stack trace, modules, and threads. From
there you keep asking:
Show the call stack with kb and explain the access violation
Run .ecxr then u to disassemble around the fault
Check the heap around 0x1f2a0040 with !heap -p -a 0x1f2a0040
Each request becomes a run_cdb_command call against the same open session. When you are
done, ask it to close the session to free the cdb.exe process:
Close the crash dump session for C:\dumps\app.dmp
Where to go next
- Analyze a crash dump - the dump workflow in depth.
- Debug a remote target - connect to a live session and break in.
- Triage multiple dumps - scan a folder and compare.
- Debug from another machine - run the server over HTTP and connect remotely.
- Redact sensitive data - filter secrets out of tool output.
- Command-line options - every CLI flag and transport.
- Tools - the MCP tools and their parameters.
- Client configuration - Claude Desktop, Copilot CLI, pip, and source installs.
- Troubleshooting - when something does not work.