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. Together they turn a crash into a diagnosable, understood bug.

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 across instances. Together these let you find both where and why a crash happened, which is what good crash reporting captures automatically so you have the evidence to diagnose.

Why can't I find the cause 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. So combine the trace (where) with context and patterns (why) to find the full cause.

Tips for Finding the Cause of a Crash

Quick answer: Read the symbolicated stack trace to find where it crashed, use breadcrumbs and device context to understand the conditions, and group occurrences to spot the shared trigger. The trace tells you where; the context and pattern tell you why.

Finding a crash's cause means answering two questions: where did it happen, and why? With the right data captured, most crashes are diagnosable. Here are practical tips for finding the cause of a crash.

Read the Stack Trace for Where

The first tip: read the symbolicated stack trace, 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 it 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 at a specific line is frequently the whole story.

Use Context for Why

Where isn't always why. The tip: use 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, to understand the state that triggered the failure. 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 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. The tip: group occurrences of the same crash to reveal 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. So find a crash's cause by 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.