What is the difference between a soft crash and a hard crash?

A hard crash terminates the program, the process dies and the game closes. A soft crash (or freeze) leaves the process alive but completely unresponsive, stuck on a frozen frame ignoring input, usually due to an infinite loop or deadlock. The player has to force-quit a soft crash, whereas a hard crash closes on its own.

What causes a game to freeze?

Most often an infinite loop (code stuck repeating forever, never returning to render or process input), a deadlock (two parts each waiting for the other so neither proceeds), or a blocked main thread waiting on something slow or stuck. All leave the process running but unable to advance, producing a frozen, unresponsive game.

Why don't freezes show up in crash reporting?

Because a freeze does not terminate the process or throw an exception, there is nothing for termination-based monitoring to catch. Detecting soft crashes takes a deliberate watchdog that notices the game loop has stopped advancing, then captures the frozen main thread's state and reports it, so hangs are tracked alongside hard crashes rather than going unmeasured.

What Is a Soft Crash or Freeze?

Quick answer: A soft crash (or freeze, hang, or lock-up) is when a game becomes completely unresponsive without the process actually crashing. Unlike a hard crash where the program terminates, a soft crash leaves the game running but frozen, typically because of an infinite loop, a deadlock, or a blocked main thread. The player is stuck staring at a non-responding game.

Not every catastrophic failure is a crash. Sometimes the game does not close, it just stops, frozen on a static frame, ignoring all input, the program technically still running but going nowhere. This is a soft crash, and from the player's perspective it can be worse than a hard crash, because the game does not even have the decency to close; they have to force-quit it. Soft crashes are a distinct failure mode that crash-only monitoring misses.

Frozen but Not Dead

The defining characteristic of a soft crash is that the process is still alive, it just is not making progress. The game loop has stopped advancing: the screen is frozen, input is ignored, but the program has not terminated. This is fundamentally different from a hard crash, where the process dies and is gone. A soft crash is a stuck process, not a dead one.

Because the program is still running, a soft crash often produces no error and no crash report by default, there was no exception, no termination, just a halt. This makes soft crashes invisible to monitoring that only catches process termination, which is part of why they are easy to under-measure even though players hit them.

What Causes Freezes

The usual causes are infinite loops and deadlocks. An infinite loop is code that never exits, a loop whose end condition is never met, so the game gets stuck executing it forever and never returns to render or process input. A deadlock is when two parts of the program are each waiting for the other, so neither can proceed and the game halts. Both leave the process alive but permanently stuck.

A blocked main thread is a related cause, the main loop is waiting on something slow or stuck (a hung network call, a lock), so it cannot advance. On mobile this is exactly what triggers an ANR. In all cases, the symptom is the same to the player: the game freezes and stops responding, requiring a force-quit.

Detecting Soft Crashes

Because soft crashes produce no automatic termination, detecting them takes deliberate effort. A common technique is a watchdog: a check that the game loop is still advancing, and if it has not progressed for too long, treat it as a hang, capture the state (especially the main thread's stack trace to see what it is stuck on), and report it. This is conceptually how ANR detection works, and it can be applied beyond mobile.

Capturing the frozen main thread's stack is the key to diagnosing a soft crash, it shows you exactly what the game was stuck doing. Bugnet's reporting captures context and state around a problem, so a detected hang arrives with the information to identify the infinite loop or deadlock behind it. Tracking soft crashes alongside hard crashes gives you the complete stability picture, because a game that freezes is as broken to the player as one that closes, and you cannot fix freezes you are not measuring.

A soft crash is a game frozen but not dead, stuck in a loop or deadlock. It throws no error, so you only catch it if you watch for the loop going silent.