Unreal Engine Crash Analysis: What the Crash Folder Actually Contains

A typical Unreal Engine crash on Windows produces a folder that looks something like this:

CrashContext.runtime-xml
UE4Minidump.dmp
MyGame.log
CrashReportClient.ini

Most developers drag the .dmp file into WinDbg and ignore everything else. That's understandable the minidump is the standard crash artifact and it contains the stack trace. But CrashContext.runtime-xml often contains information that the minidump doesn't, and understanding both together gives you a much clearer picture of what happened.

The minidump

UE4Minidump.dmp (or UE5Minidump.dmp) is a standard Windows minidump written by Unreal's crash handler when an unhandled exception occurs. It contains the exception record, all thread stacks, loaded modules, register state, and partial memory. Everything described in a standard minidump analysis applies here.

The complication with UE is the stack size. A typical UE crash stack contains hundreds of frames the engine's own tick loop, the actor tick chain, the animation system, the physics thread dispatcher before you get anywhere near your game code. For example:

00  ntdll!RtlUserThreadStart
01  kernel32!BaseThreadInitThunk
02  UE5Editor!FRunnableThread::Run
03  UE5Editor!FEngineLoop::Tick
04  UE5Editor!UGameEngine::Tick
05  UE5Editor!UWorld::Tick
06  UE5Editor!AActor::TickActor
07  UE5Editor!UActorComponent::TickComponent
...
38  UE5Editor!UActorComponent::TickComponent
39  MyGame!APlayerCharacter::Update      PlayerCharacter.cpp:312
40  MyGame!UWeaponComponent::FireWeapon   WeaponComponent.cpp:88
41  MyGame!AProjectile::Initialize        Projectile.cpp:44

Frames 0–38 are engine infrastructure. The crash is at frame 41, in your code. Without a tool that understands which frames belong to the engine and which belong to your game, finding the relevant frames means manually scrolling through dozens of identical-looking engine entries.

CrashContext.runtime-xml

This file is what makes UE crash analysis different from analyzing a generic C++ crash. Unreal's crash handler captures engine-level context that doesn't exist in the minidump. A typical CrashContext.runtime-xml looks like this:

<RuntimeProperties>
  <GameName>MyGame</GameName>
  <EngineVersion>5.3.2-26560700</EngineVersion>
  <BuildConfiguration>Development</BuildConfiguration>
  <EngineMode>Game</EngineMode>
  <CrashType>Crash</CrashType>
  <IsEnsure>false</IsEnsure>
  <IsAssert>false</IsAssert>
  <CPUBrand>AMD Ryzen 9 7950X</CPUBrand>
  <GPUBrand>NVIDIA GeForce RTX 4090</GPUBrand>
  <TotalPhysicalRAM>34359738368</TotalPhysicalRAM>
  <bIsOOM>false</bIsOOM>
  <CallStack>
    AProjectile::Initialize [Projectile.cpp:44]
    UWeaponComponent::FireWeapon [WeaponComponent.cpp:88]
    ...
  </CallStack>
</RuntimeProperties>

Here's what each field tells you:

• EngineVersion the exact UE build. Critical for checking engine release notes for known crash bugs in that version.
• BuildConfiguration Development, DebugGame, Shipping, etc. This directly affects how useful your stack trace will be (more on this below).
• EngineMode whether it crashed in the Editor, a packaged Game build, a Server, etc.
• CrashType / IsEnsure / IsAssert — distinguishes a hard crash from an ensure() failure or a check() assertion. An ensure is a soft failure that doesn't terminate the process; a check/assert terminates immediately.
• bIsOOM whether an out-of-memory condition was detected before the crash. If true, the stack trace may be misleading OOM in UE often manifests as an access violation in an apparently unrelated location.
• CallStack UE's own call stack string, captured by the engine's crash handler. This is independent of the minidump stack walk and can sometimes provide function names even when symbol resolution fails on the .dmp side.

UE exception codes

Unreal Engine defines its own exception codes for non-crash events that it captures through its crash handler:

• 0xE0000001 — UnrealFatalError — a UE_LOG(Fatal, ...) call or a check() / checkf() assertion failure. The engine calls RaiseException with this code to trigger the crash reporter cleanly.
• 0xE0000002 — UnrealEnsure — an ensure() or ensureMsgf() that evaluated to false. The process continues after an ensure failure, but the crash reporter fires to capture the state.

If you see either of these in the Exception tab, the crash was deliberate the engine detected an error condition and triggered the reporter intentionally. The interesting information is in the log file and the UE call stack, not in the exception address.

Build configuration and stack quality

This is the most practically important thing to know about UE crash analysis. The build configuration you were running when the crash occurred determines how useful your stack trace will be:

• DebugGame full symbols, no inlining, no optimization. Best possible stack trace. Use this when actively debugging a crash on your dev machine.
• Development symbols available, some optimization. Good stack traces, some inlined frames may be missing.
• Shipping symbols stripped from the binary by default. Stack traces contain addresses with no function names unless you separately archive the PDB. Many inlined frames collapse into their callers. The stack may look completely different from what you'd see in Development.

For crashes from player machines running Shipping builds: if you don't have a symbol archive process that stores the PDB alongside each Shipping build you distribute, you will not be able to symbolicate those crashes. Build this into your pipeline before you ship it's much harder to recover PDBs after the fact.

Analyzing UE crash folders in CrashCatch

CrashCatch Analyze has dedicated support for the UE crash folder format via File > Open UE Folder (Ctrl+Shift+O). It locates the .dmp file and CrashContext.runtime-xml automatically, runs the standard minidump analysis, and adds a UE Context tab with all the engine metadata. Engine frames are identified and can be dimmed so your game code stands out. The Intel Engine activates UE-specific heuristics when UE modules are detected garbage collector issues, async loading deadlocks, and Blueprint vs. native frame classification.