svnscha / debug-remote

Debug a live user-mode process

MCP connection

Use the existing mcp-windbg MCP connection, whether it is launched by a plugin,
a native executable, Python, or an HTTP service. Tool names below are base
names; resolve them against the tools exposed by that connection rather than
assuming a plugin-specific prefix. Keep each session on the server that opened
it. If multiple servers match, use the user's selected server or ask which one.
If the required tools are unavailable, report the missing connection or tool
and help check its configuration; do not register a second server.

Attach to an existing WinDbg/CDB debug server with the mcp-windbg tools.
This is user-mode only - for a kernel target use the available kernel-debug skill.

The other end

Someone must already be hosting the target. In WinDbg or CDB on that machine:

.server tcp:port=5005

If they have not, say so rather than guessing a connection string - there is
nothing to attach to yet.

Connecting

open_cdb_remote with the connection string:

• TCP: tcp:Port=5005,Server=hostname
• Named pipe: npipe:Pipe=pipename,Server=hostname

The target is running when you attach, so the session may not be at a prompt.
send_ctrl_break halts it when you need it stopped.

Working the target

run_cdb_command with the session_id:

• ~*k for every thread's stack - the usual first move on a hang
• !locks, !cs -l for lock contention
• lm, !peb for what is loaded and how it started
• bp, g, wait_for_break to catch a code path in the act
• .dump /ma <path> to capture a dump for offline analysis

Letting it run again

Attaching to a live process freezes it while broken in, and a frozen process is
usually worse than an unanalyzed one:

• g resumes and returns immediately; the target produces no output until it
  stops again.

• wait_for_break blocks until it stops on its own.
• Any ordinary command breaks in automatically first.

close_cdb_session when finished. Say plainly whether the target was left
running or halted, so nobody discovers a frozen process an hour later.

Reporting

For a hang, the answer is usually the relationship between threads, not a single
stack: which thread holds what, and which are waiting on it. Say that explicitly
rather than pasting ~*k and leaving the reader to work it out.