Debug a remote target¶
Beyond frozen dumps, you can attach to a live debugging session and inspect it as it
runs. This is for connecting to a debugging server that is already listening, for example a
cdb -server started on the target machine.
Connect¶
Give the model the connection string:
This calls open_windbg_remote. Supported
connection string formats:
| Transport | Example |
|---|---|
| TCP | tcp:Port=5005,Server=192.168.0.100 |
| Named pipe | npipe:Pipe=MyPipe,Server=MyServer |
| COM | com:Port=COM1,Baud=115200 |
Connecting to a debugging server, not attaching directly
open_windbg_remote attaches to an existing debugging server (cdb/WinDbg started with
-server). It does not attach to a running process by PID, and kernel-mode debugging over a
-k cable is a different mode that is not supported. To debug a local process, start a cdb
-server on it first, then connect.
Break in, then inspect¶
If the target is running, pause it before you inspect state. Ask the model to break in,
which calls send_ctrl_break:
Once stopped, investigate the same way you would a dump, through
run_windbg_cmd:
Show the current registers and call stack
List all threads and point out any that look stuck
Check thread CPU time with !runaway
Look for held locks with !locks
A typical hang investigation:
1. Connect to tcp:Port=5005,Server=192.168.0.100
2. Send CTRL+BREAK so we can inspect safely
3. Show current state - registers, stack, threads
4. Run ~*k and identify the thread holding things up
5. Run !locks to check synchronization objects
Close the connection when done¶
This calls close_windbg_remote and releases
the session.
Related¶
- Tools reference -
open_windbg_remote,send_ctrl_break,run_windbg_cmd. - Troubleshooting - connection failures.