Skip to content

Debug from another machine

mcp-windbg needs Windows and cdb.exe, but you do not have to work on that machine. Run the server on the Windows host that holds the dumps, symbols, and debugger, and connect to it over HTTP from your own laptop, or let a few people share one debugging host.

Start the server on the Windows host

mcp-windbg --transport streamable-http --host 127.0.0.1 --port 8000

It serves MCP at http://127.0.0.1:8000/mcp. Pass the same server options as usual, for example --symbols-path or --filter-script, see Command-line options.

Point your client at it

Use an HTTP MCP server entry instead of a launched command:

{
    "servers": {
        "mcp_windbg_http": {
            "type": "http",
            "url": "http://localhost:8000/mcp"
        }
    }
}

Replace localhost with the host's name or IP when the client is on a different machine. From there you debug exactly as over stdio, the crash dump and remote target workflows are identical.

Paths are on the server

The server opens dumps from its own filesystem, so the paths you mention are the host's paths, not your laptop's:

Analyze the crash dump at C:\dumps\app.dmp

That C:\dumps\app.dmp is read on the Windows host.

Expose it beyond localhost

--host 127.0.0.1 keeps the server local. To accept connections from other machines, bind a reachable address and open the port:

mcp-windbg --transport streamable-http --host 0.0.0.0 --port 8000

The HTTP transport has no authentication

Anyone who can reach the port can drive cdb.exe on the host. Keep the server on 127.0.0.1 or a trusted network. To reach it remotely, prefer an SSH tunnel or an authenticating reverse proxy rather than binding 0.0.0.0 on an untrusted network. Also allow the port through the host firewall.