What causes a death screen showing incorrect run summary stats?

The death handler resets or replaces the run state before the summary screen reads it, so the summary pulls zeroed or stale values.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix the Death Screen Showing Wrong Run Stats

Quick answer: Snapshot the run's stats into an immutable summary object at the moment of death, before any reset, and have the death screen read only that snapshot.

A run summary that shows zero kills or floor 0 is reading state that was already cleared. Capturing a snapshot at death, before the reset, gives the summary correct numbers.

How to fix it

1. Snapshot before reset

In the death handler, copy floor, kills, time, gold, and items into a separate RunSummary object first, then perform any cleanup of the live run state.

2. Render from the snapshot only

Have the death screen read exclusively from the snapshot, never from the live run manager, so a reset elsewhere cannot blank the displayed stats.

3. Bank stats incrementally too

Update the running totals (kills, damage) as they happen rather than recomputing at death, so the snapshot is accurate even if some entity was destroyed early.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Unity error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

The bug you can't reproduce isn't gone — it's just invisible until you capture it from the player's device.