How do I read a multi-threaded crash dump from a game?

In a multi-threaded crash dump, each thread has its own stack trace. Start with the crashing thread, which is usually marked by the debugger. Then examine other threads for context: the main thread shows what the game loop was doing, render threads show GPU command state, and audio threads show sound processing. Deadlocks require examining multiple threads to find the circular lock dependency.

Why do coroutine stack traces look incomplete in Unity?

Unity coroutines are implemented as state machines using IEnumerator. When a coroutine yields, its stack is not preserved in the traditional sense. The stack trace at the point of an error only shows the current execution frame and the coroutine scheduler, not the original call chain that started the coroutine. Use descriptive coroutine names and logging to track the full execution context.

What patterns indicate a stack overflow crash in a game?

A stack overflow crash shows the same sequence of function frames repeated many times in the stack trace. The trace is often truncated because the stack depth exceeded the recording limit. Common causes in games include recursive AI decision trees, infinite event chains where event A triggers event B which triggers event A, and recursive scene graph traversals on cyclic node references.

Stack Trace Analysis for Game Developers: Patterns and Techniques

Quick answer: In a multi-threaded crash dump, each thread has its own stack trace. Start with the crashing thread, which is usually marked by the debugger.

This guide covers stack trace analysis for game developers in detail. Reading a single stack trace is straightforward. Recognizing patterns across hundreds of them is what separates effective debugging from guesswork. This guide covers the analysis techniques that experienced game developers use to extract maximum information from stack traces, including multi-threaded dumps, async and coroutine stacks, and common crash signatures.

The Three Questions Every Stack Trace Answers

Before diving into patterns, establish the habit of asking three questions for every crash: What happened (the exception type or signal), where it happened (the topmost frame from your code), and why the code reached that state (the call chain leading to it). The exception type tells you the category. The location narrows it to a function. The call chain reveals the game state that triggered the bug.

Thread Dumps in Game Crashes

Games are heavily multi-threaded. A crash dump captures the stack trace of every thread, not just the one that crashed. Learning to read the non-crashing threads provides crucial context.

# Thread 0 (Main/Game Thread) - CRASHED
CombatSystem::ApplyDamage()        combat.cpp:247
CombatSystem::ProcessHitQueue()    combat.cpp:189
GameWorld::Tick()                  world.cpp:412

# Thread 1 (Render Thread)
RenderQueue::SubmitDrawCalls()     render.cpp:891
RenderThread::Run()                render.cpp:34

# Thread 2 (Asset Loading)
AssetManager::LoadTexture()        assets.cpp:156
AssetThread::ProcessQueue()        assets.cpp:42

In this example, the main thread crashed in the combat system during the game tick. The render thread was submitting draw calls, and the asset loader was loading a texture. If the crash were a data race, the other threads' positions would be critical evidence. A texture being loaded while the render thread submits draw calls using that texture suggests a synchronization issue.

Deadlock Detection

Deadlock crashes show a distinctive pattern: multiple threads are all waiting to acquire locks, and the lock each thread holds is the one another thread is waiting for. In a crash dump, deadlocked threads appear stuck in synchronization functions:

# Thread 0 - waiting for AudioMutex
WaitForSingleObject()
AudioSystem::PlaySound()    # holds RenderMutex

# Thread 1 - waiting for RenderMutex
WaitForSingleObject()
RenderSystem::UpdateUI()    # holds AudioMutex

Thread 0 holds the render mutex and wants the audio mutex. Thread 1 holds the audio mutex and wants the render mutex. Neither can proceed. The fix is to establish a consistent lock ordering across all threads.

Async and Coroutine Stack Traces

Async programming patterns in game engines create stack traces that can be misleading. When a coroutine yields in Unity or a task awaits in C#, the original call stack is lost. The stack trace at the point of failure shows only the coroutine scheduler and the current execution frame:

NullReferenceException: Object reference not set
  at WaveSpawner+<SpawnWave>d__12.MoveNext() [0x00042]
  at UnityEngine.SetupCoroutine.InvokeMoveNext()

The <SpawnWave>d__12 is a compiler-generated state machine for the SpawnWave coroutine. The MoveNext method is how the coroutine scheduler advances execution. You can see which coroutine failed, but not the original StartCoroutine call that launched it.

To work around this limitation, log the coroutine launch point with a unique identifier, or use a wrapper that tracks the caller:

public Coroutine StartTrackedCoroutine(IEnumerator routine,
    [CallerMemberName] string caller = "") {
    Debug.Log($"Coroutine {routine} started by {caller}");
    return StartCoroutine(routine);
}

Stack Overflow Patterns

Stack overflows are easy to identify in a crash dump: the same sequence of frames repeats until the trace is truncated. In games, the common causes are recursive AI behavior trees, event systems that create circular triggers, and recursive scene graph traversals.

# Stack overflow pattern - repeating frames
AIDecisionTree::Evaluate()  ai.cpp:89
AINode::Process()           ai.cpp:145
AIDecisionTree::Evaluate()  ai.cpp:89
AINode::Process()           ai.cpp:145
# ... repeats hundreds of times

The fix depends on the cause. For recursive algorithms, add depth limits. For event chains, add cycle detection that tracks which events are currently being processed. For scene graph traversals, use visited-node sets to break cycles.

Use-After-Free Patterns

Use-after-free crashes are among the hardest to diagnose because the stack trace shows where the freed memory was accessed, not where it was freed. The crash typically manifests as an access violation at an unexpected location, often deep inside a container operation or a virtual method call:

# Use-after-free crash - accessing a vtable on freed memory
ACCESS_VIOLATION reading address 0xDEADBEEF
  Entity::GetHealth()              entity.cpp:34
  CombatSystem::DamageAllInArea()  combat.cpp:112
  Explosion::OnTick()              explosion.cpp:67

The telltale sign is an access violation on a suspicious address pattern. Many debug allocators fill freed memory with sentinel values like 0xDEADBEEF or 0xFEEEFEEE. If you see these in the faulting address, you have a use-after-free. Use tools like AddressSanitizer (ASan) in development builds to catch these at the point of the invalid access.

Analyzing Patterns Across Multiple Reports

A single crash report can be misleading. The real power of stack trace analysis comes from examining patterns across many reports. Group crashes by their top three to five frames and count occurrences. The crash that appears 500 times with the same signature is more important than five unique crashes that each appeared once.

Bugnet automates this grouping. When crash reports arrive from player devices, Bugnet normalizes the stack frames, computes a fingerprint from the significant frames, and groups identical crashes together. The dashboard shows you the most impactful crashes ranked by frequency and affected player count, so you can prioritize fixes based on real-world impact rather than individual reports.

"One crash report is an anecdote. A thousand crash reports grouped by signature is a prioritized bug list."

Related Issues

For a beginner-friendly introduction to stack traces, see our guide to reading game stack traces. To learn about automated crash grouping and deduplication, read stack trace grouping and crash deduplication. For preventing the most common crashes in the first place, check out common game crashes and how to prevent them.

Look at thread states together, not in isolation. The crash is on one thread, but the cause is often on another.