Quick answer: Crashes when closing the game happen during teardown, the reverse-order cleanup that runs as the game exits. The usual causes: shutdown order problems where one system is destroyed while another still uses it, background threads not stopped cleanly, or a save-on-exit operation failing. They're easy to ignore (the game was closing anyway) but can corrupt saves and signal real lifecycle bugs. Capture the crash and make shutdown orderly.
A crash that happens when the player closes the game is easy to dismiss, the game was quitting anyway, so who cares? But shutdown crashes matter: they can corrupt a save that was being written on exit, they leave a bad final impression, and they often indicate real lifecycle bugs. They happen during teardown, a phase that's frequently under-tested, so the cause is usually something about how the game cleans up.
Why Games Crash on Close
Shutdown runs a lot of cleanup quickly, and several things can go wrong. Shutdown order problems: systems are torn down in an order where one is destroyed while another still references and uses it, causing a null/invalid access during teardown. Threads not stopped cleanly: background threads still running during shutdown touch state that's being destroyed, or aren't joined properly, causing a crash as the process tears down. And save-on-exit failures: many games save when closing, and if that save operation hits an error (a write failure, a serialization issue), it can crash, and worse, leave a corrupted save.
These are lifecycle bugs that only manifest during the specific sequence of shutdown, which is why they escape normal play testing, you don't 'play' the shutdown. A crash that always happens on close points at the teardown sequence; one tied to saving on exit points at the save path.
How to Diagnose It
Capture the crash and read the stack trace, it tells you what's failing during shutdown: a trace in cleanup/destructor code accessing something points at order or dangling-reference problems; a trace in thread code points at threads not stopped cleanly; a trace in save/serialization code points at the save-on-exit failing. The trace localizes which part of teardown is the problem.
Bugnet captures the stack trace and context with each crash and groups by signature, so close crashes cluster and you can see whether they share a cause (the same teardown step, the same save path) and whether they correlate with anything (a platform, an action just before closing). Because shutdown crashes can be quietly common and quietly corrupting saves, having them captured and visible rather than ignored is the first step to taking them seriously.
How to Fix It
Make shutdown orderly and defensive. For order problems, tear systems down in an order that respects dependencies, destroy dependents before the things they depend on, so nothing is used after it's destroyed. For threads, stop and join background threads cleanly before destroying the state they touch, and ensure they don't access objects during shutdown. For save-on-exit, make the save robust, handle write and serialization errors gracefully (and ideally write atomically so a failed save doesn't corrupt the existing one), so a problem saving on exit doesn't crash and doesn't destroy the player's data.
The save-on-exit case deserves special attention because a crash there can corrupt the save, turning a minor shutdown crash into lost progress or even a crash loop on next launch. Make exit-saving safe and atomic. After fixing, verify close crashes stop in the field, and remember that a clean shutdown protects both the player's final impression and, crucially, their save data.
A crash on close happens during teardown, and it can corrupt a save written on exit. Make shutdown orderly, stop threads cleanly, and save atomically.