UE Live Debugging

Rider MCP debugging workflow: find the suspect symbol, trace who calls it, see what the IDE already knows is wrong.

GATE — mandatory checks before any debugging work

1. UE Project Check

Verify the current working directory contains a .uproject file:

find . -maxdepth 1 -name "*.uproject" | head -1

If no .uproject found → STOP.

"This skill requires an Unreal Engine project (a .uproject file must be in the working directory). The current directory does not appear to be a UE project. Navigate to the project root and retry."

2. Task Is Debugging-Related Check

The task must involve debugging or investigating a runtime or compile-time issue in C++ or Blueprint code. If there is no debugging component → STOP and inform the user this skill only handles debugging.

3. Build Configuration Check — Required Before Setting C++ Breakpoints

Before placing any breakpoints in game module C++ code, verify the binary was compiled in DebugGame Editor (or Debug Editor). In Development Editor the compiler inlines and optimises away most function entry points — breakpoints silently fail with:

"The breakpoint will not currently be hit. No executable code is associated with this line."

How to check: After xdebugsetbreakpoint, inspect the response for breakpointErrorsTail entries containing that message. If present → STOP. Instruct the user to switch Rider's build configuration to DebugGame Editor and rebuild before continuing. Do not attempt to fire the repro until the breakpoint is confirmed bound.

Engine-only breakpoints (RiderLink, UE core) are unaffected — this check applies only to the project's own game modules.

4. Rider MCP Availability Check

Check the <system-reminder> deferred-tool list for Rider MCP tools. Load live schemas with ToolSearch before calling any tool. Schemas are authoritative for parameter names — never guess. If executetool is the only tool returned, use CLI mode (see reference/rider-mcp-tools.md — executetool mode).

If no Rider MCP tools appear in the deferred list:

"Rider MCP tools are unavailable. Open Rider with this project loaded and the MCP server enabled, then retry. Falling back to Bash/Grep — call hierarchy and IDE diagnostics will not run."

Proceed with Bash/Grep/Read only, skipping all mcp<prefix>* steps. Document that Rider intelligence steps were skipped.

Path Selection

Fast path for targeted fixes — known function, single file, clear root cause:

1. Verify .uproject (Gate 1)
2. Locate the function with search_symbol or rg
3. Read the file using the standard Read tool; confirm the bug
4. Apply fix with the standard Edit tool
5. Run getfileproblems if Rider MCP is available
6. Build and verify

Full workflow for crash investigation, unknown root cause, GC/threading bugs, or multi-file changes → continue to Checklist below.

Checklist

Use the agent's native planning/todo mechanism when available. For simple one-file tasks, keep the plan implicit and proceed directly. For complex investigations, track:

1. GATE — UE project check + task check + Rider prefix resolution
2. Triage — classify the entry point: crash dump, log error, or live repro
3. Locate — find the suspect symbol; read its definition and call hierarchy
4. Analyze — trace callers/callees; find IDE-detected problems on suspect files
5. Instrument — identify breakpoint locations; add targeted logging if needed
6. Reproduce — confirm the issue triggers at the identified location
7. Fix — apply the minimal correct fix using the standard Edit tool
8. Verify — build and confirm the issue no longer reproduces

Workflow

Search routing: use rg/Grep for portable text discovery; use Rider searchtext/searchfile when IDE index, generated/reflected UE code, or unsaved editor state helps. Use Rider semantic tools (searchsymbol, analyzecalls, getsymbolinfo, getfileproblems, build) for code intelligence. analyze_calls supports C++ (ReSharper backend) — if it returns "No call hierarchy provider found", fall back to Grep.

Step 0 — Triage: Classify the Entry Point

Crash Dump Analysis

Find crash artifacts in Saved/Crashes/ (editor) or the platform crash folder — see reference/crash-patterns.md for locations and minidump instructions.

Read the crash log first:

find Saved/Crashes -name "*.log" | sort -r | head -1 | xargs tail -100

Look for Fatal error, Assertion failed, Unhandled Exception, or call stack near the end.

Identify the crash signature from the callstack address pattern — see reference/crash-patterns.md — Quick Diagnosis Table.

Map the callstack to source: take the topmost non-engine frame and find it with search_symbol.

Continue from Step 1 using that symbol.

Live PIE Inspection

When PIE is running, use ueexecutepython to query live game state before reading source files — often resolves the question in one call.

Script must be a single line — no \n, no indented blocks. Use ; and comprehensions. See reference/ue-python-inspection.md for ready-to-use query patterns and API pitfalls.

Typical first queries (adapt to project-specific classes):

• World + player valid: import unreal; w=unreal.geteditorsubsystem(unreal.UnrealEditorSubsystem).getgameworld(); pc=unreal.GameplayStatics.getplayercontroller(w,0); print(w,pc)
• Pawn class: ...; p=pc.getcontrolledpawn(); print(p.getclass().getname() if p else None)
• ASC on PlayerState: ...; asc=pc.playerstate.getcomponentbyclass(unreal.AbilitySystemComponent); print(asc.get_name() if asc else None)
• Active gameplay tags: ...; print(list(asc.getownedgameplay_tags()))

After confirming runtime state, continue from Step 1 to locate the responsible source code.

Log Analysis

find Saved/Logs -name "*.log" | sort -r | head -1
grep -n "Fatal\|Error\|Assertion failed\|ensure(" Saved/Logs/<Project>.log | tail -50
grep -n "Warning" Saved/Logs/<Project>.log | grep -v "LogTemp\|LogSlate" | tail -30

See reference/crash-patterns.md — Log Patterns for common entries and root causes. Continue from Step 1.

Step 1 — Locate the Suspect Code

Use search_symbol to find the suspect class or function. Read the source files using the standard Read tool.

If starting from a crash address or log string rather than a known symbol, use search_text restricted to *.cpp.

Step 2 — Trace the Call Hierarchy

Use analyze_calls — it supports C++ via the ReSharper C++ backend.

If the tool returns "No call hierarchy provider found" (symbol not indexed), fall back to Grep to find callers. Read the function body directly to find callees.

See reference/ue-debug-patterns.md — Call Hierarchy Analysis for what to look for in results.

Step 3 — Get Symbol Info for Context

getsymbolinfo is position-based — use the standard Read tool first to find the symbol's exact line and column.

Use to confirm API contracts — whether a function is editor-only, can return nullptr, or has threading guarantees. Do not rely on training-data assumptions for version-specific UE APIs.

Step 4 — Run IDE Diagnostics on Suspect Files

Run getfileproblems on all suspect files (.h and .cpp). For multiple files, use lint_files.

• Error — likely directly related to the bug; address first
• Warning — check if it matches the crash symptom
• Hint / Info — note for context; not blockers

Step 5 — Set Breakpoints and Launch the Debugger

Do not just tell the user where to set breakpoints — set them via MCP. Pick the last point of known-good state, not the crash site.

Load the required tools first (if not already loaded):

ToolSearch(query: "select:mcp__<prefix>__xdebug_set_breakpoint,mcp__<prefix>__xdebug_get_debugger_status,mcp__<prefix>__xdebug_get_frame_values,mcp__<prefix>__xdebug_get_stack,mcp__<prefix>__ue_play,mcp__<prefix>__ue_status,mcp__<prefix>__execute_run_configuration,mcp__<prefix>__get_run_configurations")

5a — Check editor and PIE state using ue_status.

• If not connected → launch the editor using getrunconfigurations then executerunconfiguration.
• If connected and PIE idle → proceed to 5b.
• If PIE already running → proceed to 5b directly.

5b — Set breakpoints using xdebugsetbreakpoint. Set standard, conditional, or logpoint breakpoints as appropriate. See reference/ue-debug-patterns.md — Breakpoint Placement Strategies for placement rules.

5c — Start PIE using ue_play if not already running.

5d — Wait for breakpoint hit, then inspect using xdebuggetdebuggerstatus, xdebuggetstack, xdebuggetframevalues.

Step 6 — Add Targeted Instrumentation (if needed)

If a live debugger session is not feasible, add UE_LOG statements using the standard Edit tool.

See reference/ue-debug-patterns.md — Instrumentation Rules. After editing, run getfileproblems to confirm no new errors.

Step 7 — Fix

Apply the fix using the standard Edit tool.

After editing: run getfileproblems on the changed file (and .h if touched). Fix the root cause, not the symptom — see reference/ue-debug-patterns.md — Fix: Root Cause vs Symptom.

Step 8 — Build and Verify

Run buildsolutionstart and poll buildsolutionstate until complete.

After a successful build:

1. Reproduce the original issue — confirm it no longer occurs
2. Run getprojectproblems on the changed module; address new warnings on your files
3. Remove any instrumentation logging added in Step 6
4. Use reformat_file on changed files

see: reference/rider-mcp-tools.md — ALL Rider MCP tools: complete parameter reference, execute_tool mode table, UE editor/asset/debugger tools see: reference/rider-debug-tools.md — Debugging workflow patterns: crash callstack, intermittent bugs, packaged build crashes, live PIE inspection, breakpoint sequences see: reference/ue-debug-patterns.md — UE debugging patterns: call hierarchy analysis, instrumentation rules, fix guidance, breakpoint placement, GC/threading patterns see: reference/crash-patterns.md — Crash patterns: address signatures, GC crashes, assertion failures, async loading, Slate null widgets, log patterns see: reference/ue-python-inspection.md — UE Python runtime inspection: single-line scripting rules, world/player/component access, GAS/stat-tag queries, GameplayTag API pitfalls, common errors