From Crash Dump to Fix Plan: How Engineer Mode Works

Drop a crash dump into CrashCatch and within seconds you have a symbolicated stack trace, an exception classification from the Intel Engine, and optionally a plain-English explanation from Explain Mode. That's all useful. But there's a gap between "here's what crashed" and "here's what to do about it." Bridging that gap is what Engineer Mode is for.

Engineer Mode ships in v0.3.0-beta as a dedicated tab (Ctrl+0). It takes the crash data from the open dump and generates a structured debug session plan: competing hypotheses ranked by confidence, exact WinDbg commands with real values from the dump, search patterns for your source code, reproduction conditions, a context-aware fix checklist, and a blast radius assessment. Everything runs offline in a deterministic Rust engine. No API key, no network round trip, instant results.

The gap between knowing and fixing

Most crash analysis tools answer the question "what happened?" They show you the exception code, the faulting frame, the register state, and maybe a classification. That's the starting point for debugging, not the end of it. What a senior engineer does next is:

• Form competing theories about root cause
• Decide which theory is most likely given the evidence in the dump
• Write the WinDbg commands needed to test each theory
• Identify which files and functions in their codebase to search first
• Assess whether the crash is a one-liner fix or a deeper structural problem

Junior engineers either skip these steps and guess, or spend an hour reading WinDbg documentation to figure out which commands to run. Engineer Mode codifies what experienced C++ engineers do instinctively and hands it back as a structured plan specific to the crash in front of you.

What Engineer Mode generates

Hypotheses

For any crash, there are usually several plausible root causes. A 0xC0000005 access violation, for example, could be a null pointer dereference, a use-after-free, or a buffer overflow. Engineer Mode generates all plausible hypotheses for the crash class, ranks each one by confidence (0-100%), and lists the supporting and contradicting evidence for each.

─── HYPOTHESES ───────────────────────────────────────
● [HIGH 91%]  Null Pointer Dereference
  ✓  RAX = 0x0 — null pointer in accumulator register
  ✓  Access violation target address: 0x0
  ✓  Fault in AEnemy::Tick (user module, not system)
  ✗  No deallocation function found in crashing stack
     Confirm: dt AEnemy @rcx

● [LOW 9%]    Use-After-Free
  ✓  Access violation on read operation
  ✗  Target address 0x0 — not a heap-range address
  ✗  No deallocation frame in crashing stack
     Confirm: !heap -p -a @rax

Each hypothesis includes a how to confirm field: the specific WinDbg command or action that would prove or disprove the theory using the data in this dump.

WinDbg plan

Generic WinDbg advice is useless. "Run !analyze -v" is in every crash analysis tutorial and tells you nothing new. Engineer Mode generates a step-by-step WinDbg plan using real values from the dump: the actual thread ID to switch to, the actual register holding the suspect pointer, the actual address to inspect in the heap.

─── WINDBG PLAN ──────────────────────────────────────
1  !analyze -v
   Full automated analysis with verbose output

2  ~~[0x1a4c]s; k
   Switch to crashing thread 0x1a4c, print full stack

3  dt AEnemy @rcx
   Inspect AEnemy object at address in RCX register

4  !heap -p -a 0x0
   Check heap metadata at the faulting address

5  !teb
   Inspect thread environment block for stack limits

The thread ID (0x1a4c) came from the dump. The register name (@rcx) was selected because RCX held a near-null value at the time of the fault and RCX is the first argument register on x64 Windows. The type name (AEnemy) was extracted from the qualified function name AEnemy::Tick in the crashing stack frame.

Source search patterns

After identifying the likely cause, the next step is finding where in your code to look. Engineer Mode generates grep-compatible patterns based on the type names and function names extracted from the crashing stack. System modules (ntdll, kernel32, ucrtbase, and others) are filtered out so the patterns focus on your actual code.

─── SOURCE SEARCH PATTERNS ───────────────────────────
AEnemy
Type extracted from crashing frame AEnemy::Tick

AEnemy\s*\*\s*\w+\s*=
Find AEnemy pointer declarations — check for null guards

IsValid\(.*AEnemy
Find existing IsValid checks on AEnemy (UE pattern)

GetEnemy\|FindEnemy\|SpawnEnemy
Find factory functions that return AEnemy pointers

Reproduction conditions

Not every crash is straightforward to reproduce. Engineer Mode analyses the thread state and crash context to identify whether the crash is likely timing-dependent (multiple threads involved, crash in concurrent code) or memory-pressure-related (high allocation rate, crash in allocator code). It also produces a plain-language conditions list to guide reproduction attempts.

Fix checklist

The fix checklist is context-aware. A null pointer dereference in an Unreal Engine project gets different advice than the same crash class in a plain C++ application. In a UE project, the checklist suggests TWeakObjectPtr and IsValid() checks because those are the correct UE-aware patterns. In a non-UE project, it suggests std::weak_ptr and explicit null guards.

Blast radius

Every crash gets a severity rating (low / medium / high / critical), a scope description, and an impact note. A game thread crash in shipping code is critical. A crash in a background worker during cleanup might be medium. The rating is derived from the thread name, module, exception code, and crash class, not assigned arbitrarily.

─── BLAST RADIUS ─────────────────────────────────────
Severity  CRITICAL
Scope     AEnemy::Tick — game thread crash
Note      Game thread crash terminates the process immediately.
           All users on this build are affected. Ship a fix
           before the next release.

Why it's a Rust engine, not AI

Engineer Mode was prototyped as an AI call. It was rebuilt as a deterministic Rust engine for three reasons.

First, everything it generates can be derived directly from the crash data. The WinDbg commands use real values from the dump. The hypothesis confidence scores are calculated from specific signals: register values, exception codes, stack frame names, thread state. No language model reasoning is needed because there's no ambiguity to reason through, just pattern matching on structured data.

Second, the output needs to be trustworthy at the command level. An AI might generate a plausible-looking WinDbg command with a fabricated address. A Rust engine that reads the actual thread ID from the dump and formats it into the command string will always be correct. When you paste ~~[0x1a4c]s into WinDbg, that thread ID came from the dump, not from inference.

Third, offline and instant matters. Crash debugging is often time-sensitive. Waiting on a network round trip, paying per-use API costs, and requiring an internet connection on air-gapped development machines all add friction. The Rust engine has none of that.

Crash classes covered

Engineer Mode produces tailored output for 10 crash classes:

• Null Pointer Dereference detected via 0xC0000005 with a null target address
• Use-After-Free detected via 0xC0000005 with a deallocation function in the crashing stack
• Heap Corruption detected via 0xC0000374
• Stack Overflow detected via 0xC00000FD plus repeated frame heuristic
• Deadlock detected when all non-crashing threads are in wait functions
• Abort / Assert detected via 0x40000015
• Pure Virtual Call detected via __purecall in the crashing stack
• Security Cookie / Stack Overrun detected via 0xC0000409
• Out of Memory detected via 0xC0000017
• Access Violation (generic) fallback for non-null violations that don't match the above patterns

For Unreal Engine projects, ensure() failures (FDebug::EnsureFailed in stack) and check() failures (FDebug::CheckVerifyFailed in stack) are detected and layered on top of any base crash class, producing UE-specific guidance alongside the standard output.

Using Engineer Mode

Open a crash dump in CrashCatch and press Ctrl+0, or click the Engineer tab in the tab bar. The report generates immediately with no button press required. If you have multiple dumps open, each gets its own independent report.

Engineer Mode output is included in the PDF export: hypotheses as cards, the WinDbg plan as a numbered table, search hints, reproduction conditions, the fix checklist as an ordered list, and the blast radius with a color-coded severity badge. You can attach the full report to a GitHub issue or paste it directly into a Jira ticket using the Copy as Markdown button.

Engineer Mode is available in v0.3.0-beta. The beta is free to download and use through June 1, 2026, no license key required.