Windbgskill

WinDbg HTTP Bridge

Controls WinDbg through windbgskill.dll, exposing a local HTTP server. The user loads the plugin once per session; you communicate via HTTP (curl, curl.exe, Python, or any HTTP client).

All three debug modes share the same plugin interface — the only difference is which WinDbg commands you send.

Quick Start

User loads the plugin in WinDbg once per session:

.load windbgskill.dll

# Default: listen on 127.0.0.1:9090 (local access only)
!windbgskill start

# Specify port only (still binds to 127.0.0.1)
!windbgskill start 9090

# Specify IP and port (use 0.0.0.0 to allow remote machine access)
!windbgskill start 0.0.0.0 9090

User tells you the port (e.g. "windbgskill plugin is on port 9090"):

curl.exe -s http://127.0.0.1:9090/api/status
curl.exe -s -X POST http://127.0.0.1:9090/api/exec -d "!analyze -v"

Always check /api/status first. If state is running, call /api/break before sending any commands.

Debugger States

State transitions: running → POST /api/break → broken → POST /api/go → running

Scenario Detection

If the user doesn't specify which mode, infer from context before asking.

When the scenario is ambiguous and cannot be inferred from context, ask: "Is this dump analysis, live kernel debugging, or user-mode process debugging?"

API Reference

Base URL: http://127.0.0.1:{PORT}

# Self-discovery
curl.exe -s http://127.0.0.1:{PORT}/api/help

# Check state - also shows which command is currently running
# {"state":"broken","port":9090,"exec":{"busy":false}}
# {"state":"broken","port":9090,"exec":{"busy":true,"cmd":"!analyze -v","elapsed_s":47}}
curl.exe -s http://127.0.0.1:{PORT}/api/status

# Execute a command (body = raw WinDbg command, response = raw output)
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "k"
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "!analyze -v"

# Custom timeout via query param (default 60 s)
curl.exe -s -X POST "http://127.0.0.1:{PORT}/api/exec?timeout=180" -d "!analyze -v"

# Interrupt / resume
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/break
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/go

# Stop server remotely
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/shutdown

Common Commands by Scenario

Dump Analysis (process dump or kernel dump)

Symbol issues: if output shows ??? symbols or symbol file could not be found, run .reload <module> or .reload /f. Use !sym noisy before .reload to diagnose why symbols fail to load.

Live Kernel Debugging

~N in kernel context = switch to processor/core N (not thread). Use !process / !thread to navigate threads.

User-mode Process Debugging

~N in user-mode context = switch to thread N (e.g. ~0s, ~1s).

Workflows

Crash dump analysis

# 1. Confirm state (dump loads in broken state)
curl.exe -s http://127.0.0.1:{PORT}/api/status

# 2. Automated analysis (can take 60-120 s if downloading symbols)
curl.exe -s -X POST "http://127.0.0.1:{PORT}/api/exec?timeout=180" -d "!analyze -v"

# 3. Switch to faulting context and inspect stack
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d ".ecxr"
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "k"

Live kernel debugging

# 1. Break in
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/break

# 2. Explore system state
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "!process 0 0"

# 3. Set breakpoint and resume
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "bp nt!NtCreateFile"
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/go

# 4. When breakpoint hits, inspect
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "k"
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "r"

User-mode process debugging

# 1. Break in
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/break

# 2. Overview
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "~*k"
curl.exe -s -X POST "http://127.0.0.1:{PORT}/api/exec?timeout=120" -d "!analyze -v"

# 3. Set breakpoint and resume
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/exec -d "bp MyModule!MyFunction"
curl.exe -s -X POST http://127.0.0.1:{PORT}/api/go

Rules

• Use any available HTTP client (curl, curl.exe, Python requests, etc.).
• /api/exec body is plain text — send the WinDbg command directly, no JSON wrapping.
• Slow commands (!analyze -v, .reload /f, symbol downloads): append ?timeout=180; default is 60 s.
• /api/exec returns HTTP 409 if target is running — call /api/break first.
• /api/exec returns HTTP 503 if the engine is stuck — diagnose and recover:
  1. GET /api/status → exec.busy, exec.cmd, exec.elapsed_s show what is blocking and for how long.
  2. POST /api/break → sends a passive interrupt to unblock the stuck command.
  3. Retry the original command or investigate the cause.
• After resume commands (g, p, t, pt, tt), state becomes running; check /api/status before next command.
• ~N means thread N in user-mode, processor/core N in kernel mode and kernel dumps.
• If the debug scenario is unclear, infer from context first; ask the user only if inference is not possible.