# Tracealyzer

> Trace execution (into or over calls) for N steps or until a condition, then analyze the recorded instruction log

- Skill: `netvar1337/tracealyzer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add netvar1337/tracealyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/netvar1337/tracealyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: netvar1337 (https://skillmd.com/u/netvar1337)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/netvar1337/tracealyzer

---


# tracealyzer

Trace debuggee execution — stepping into or over calls — for a specified number of instructions or until a condition is met. The full instruction log is captured to a file and then analyzed.

## Instructions

Follow these steps exactly:

### 1. Verify debugger connection

Call `mcp__x64dbg__get_debugger_status` to confirm the debugger is connected and a debuggee is loaded and **paused**. If it is running, call `mcp__x64dbg__pause`. If no debuggee is loaded, tell the user and stop.

### 2. Gather trace parameters

Ask the user for the following if not already provided:

- **Trace mode**: trace *into* calls or trace *over* calls (default: over)
- **Stop condition** — one of:
  - A maximum number of instructions (e.g. `1000`)
  - An x64dbg expression that stops when true (e.g. `cip == 0x7FF6A0001000`, `rax != 0`)
  - Both (whichever triggers first)

If the user provides a symbol or address for the stop condition, resolve it with `mcp__x64dbg__eval_expression` and build the `break_condition` expression (e.g. `cip == <resolved_addr>`).

When the user only specifies a step count N and no explicit break condition, use break_condition `0` (never true — the trace runs until max_steps is hit).

### 3. Capture starting context

Call `mcp__x64dbg__get_all_registers` and `mcp__x64dbg__disassemble` at the current instruction pointer to record the starting state. Note the starting address.

### 4. Run the trace

Prepare the output log path: `./traces/trace_<timestamp>.log` (create the `traces` directory if it doesn't exist via `Bash`).

Call the appropriate trace tool (`mcp__x64dbg__trace_into` or `mcp__x64dbg__trace_over`) with:

| Parameter | Value |
|-----------|-------|
| `break_condition` | The user's condition, or `0` if only a step count was given |
| `max_steps` | The user's step count, or `50000` if only a condition was given |
| `log_text` | `{p:cip} {i:cip} | Label={label@cip} Comment={comment@cip}` |
| `log_file` | The output log path from above |
| `wait_timeout` | Scale with max_steps — use `max(60, max_steps // 500)` seconds |

### 5. Read and analyze the trace log

Read the trace log file. The log contains one line per executed instruction in the format:

```
<address> <disassembly> | Label=<label> Comment=<comment>
```

*Ignore when Labels or Comments say `[Formatting Error]`, it just means there is no label or comment at that instruction.*

Analyze the trace and present a summary to the user:

- **Trace overview**: total instructions executed, start address → end address, trace mode used
- **Execution flow**: describe the high-level behavior — what the code did, which functions were called, loops observed, and notable control-flow patterns
- **Hot spots**: addresses or regions that appear most frequently (loops, repeated calls)
- **Key observations**: interesting register manipulations, memory accesses, syscalls, API calls, string operations, or anything else that stands out

Use `mcp__x64dbg__get_symbol` to resolve notable addresses to symbol names where possible.

If the trace log is very large (>2000 lines), read it in chunks and summarize progressively.

### 6. Follow-up actions

After presenting the summary, ask the user if they would like any follow-up actions such as:

- **Annotate**: add comments/labels in x64dbg at key addresses using `mcp__x64dbg__set_comment` / `mcp__x64dbg__set_label`
- **Deeper analysis**: re-trace a specific sub-region, or focus on a particular function
- **Deobfuscation**: identify and explain obfuscated patterns found in the trace
- **Export**: the trace log is already saved to disk at the path from step 4