Quick answer: A crash loop happens when the game crashes, the player relaunches, and it crashes again at the same point, usually startup, making it unplayable. The cause is almost always persistent bad state: a corrupted save, config, or cache that the game reads on launch and that re-triggers the crash every time because the bad data is still there. The fix is defensive loading, detect and reset bad persistent data instead of crashing on it.
A normal crash is bad; a crash loop is catastrophic. When the game crashes once, the player can restart and continue, but in a crash loop, it crashes every single launch at the same spot, locking the player out completely. These are among the most urgent bugs you can have, they take a player from 'annoyed' to 'cannot play at all,' and they generate refunds and one-star reviews fast.
Why Crash Loops Happen
The defining feature of a crash loop is persistence: something that survives between launches keeps re-triggering the crash. The classic cause is corrupted persistent state. The game writes a save, config, or cache; that data gets into a bad state (through a bug, an interrupted write, or a version mismatch from an update); and on each launch the game reads it, hits the bad data, and crashes, every time, because the bad data is still there.
Startup crash loops are especially common because so much state loads at boot: settings, the last save, cached data, account info. If any of it is corrupt and the loading code isn't defensive, the game crashes before the player can do anything. Version transitions are a frequent trigger, an update changes a data format and chokes on data written by the old version, producing a loop for players who had old data.
How to Diagnose It
Crash loops have a distinctive signature in crash data: the same crash signature occurring repeatedly, often concentrated among relatively few players who relaunch and re-crash. A crash with a very high occurrence count but a comparatively small number of affected users, pointing at startup or save-loading code in the trace, is the fingerprint of a loop, each trapped player generates crash after crash.
Bugnet's crash grouping and occurrence data surface this: a crash whose count climbs fast, traces to boot/load code, and concentrates among repeat-crashing users is a likely crash loop, and one to treat as top priority. The stack trace tells you which persistent data is being read when it crashes (the save, the config, the cache), which is the bad state to handle.
How to Fix It
Break the cycle of re-reading bad state. The robust fix is defensive loading: wrap the reading of persistent data (save, config, cache) so that if it fails or is invalid, the game catches the error, resets or discards the bad data, and continues rather than crashing. A game that detects a corrupt save and falls back to a default turns a crash loop into a recoverable hiccup. Add validation and versioning to your save/config formats so old or malformed data is handled, not fatal, and consider a safe mode that boots with minimal state.
For players already trapped in a loop, provide a recovery path, a documented way to clear the offending file, or auto-detection that resets it, so they're not stuck. Then ship the defensive-loading fix so it can't recur. Because a crash loop makes the game unplayable for everyone it hits, it almost always warrants an emergency hotfix; spotting it fast in your crash data (the many-crashes-few-users pattern) is what lets you respond before the refunds and reviews pile up.
A crash loop locks players out entirely, and the cause is almost always bad data that survives restarts. Load persistent state defensively so a corrupt value resets instead of looping.