What information do I need to diagnose a crash?

A symbolicated stack trace (so you can see where it crashed in readable function names and lines), device and version context (to narrow the conditions), and a breadcrumb trail (to see what led up to it). For crashes that only emerge as a pattern, grouped occurrences reveal shared conditions. Together these let you find both where and why a crash happened, which is what good crash reporting captures automatically.

Why can't I find the cause of a crash from the stack trace alone?

Sometimes you can, a clear trace often reveals the immediate cause directly. But the trace tells you where the crash happened, not always why, the state, input, or device that made that line fail. That's where context (device, version, breadcrumbs) and grouped occurrences come in: they reveal the conditions and the shared pattern across instances, which explain the why the stack trace alone can't.

How Do I Find the Cause of a Crash?

Q: How do I find the cause of a crash?

Read the symbolicated stack trace top-down to find where it crashed (the top frame is usually the crash site, often revealing the immediate cause), use the device, version, and breadcrumb context to understand the conditions that triggered it, and group occurrences to spot the shared pattern, a common device or trigger, across everyone who hit it. The stack trace tells you where; the context and pattern tell you why.

Quick answer: Read the symbolicated stack trace to find where it crashed, use the breadcrumb trail and device context to understand the conditions, and group occurrences to spot the shared trigger.

Finding a crash's cause means answering two questions: where did it happen, and why? The stack trace answers the first; context and patterns answer the second. With the right data captured, most crashes are diagnosable. Here's how to find the cause of a crash.

Read the Stack Trace for Where

The stack trace is your primary clue, it shows where the program was when it crashed. Read it top-down: the top frame is usually the crash site, and the frames below show how the code got there. A symbolicated trace names real functions and lines, often revealing the immediate cause directly.

Bugnet symbolicates stack traces and shows them per issue, so you can read the trace and find the failing line. The stack trace answers 'where', which is often most of the battle, a null dereference or out-of-bounds access at a specific line is frequently the whole story.

Use Context for Why

Where isn't always why. The surrounding context, the device, OS, and version narrow the conditions, and a breadcrumb trail shows what the player did leading up to the crash, explains the state that triggered the failure the trace points to. Context turns 'it crashed here' into 'it crashed here because of this.'

Bugnet attaches device, version, and breadcrumb context to each crash, so you can reconstruct the conditions. Using context for why is what gets you from the crash site to the actual cause, the state or input that made that line fail.

Group Occurrences for the Pattern

Some causes only emerge from the aggregate. Grouping occurrences of the same crash reveals shared conditions, all on one GPU, all after a certain action, that single reports hide. That common pattern frequently points straight at a cause you couldn't see from one instance.

Bugnet groups occurrences and surfaces their shared context, so the pattern across everyone who hit the crash is visible. Finding the cause of a crash is reading the stack trace for where, using context for why, and grouping occurrences for the pattern, which together turn a crash into a fixable, understood bug.

Read the symbolicated stack trace for where, use device and breadcrumb context for why, and group occurrences for the shared pattern. Together they turn a crash into a fixable, understood bug.