What Happens When DOOM Runs for 2.5 Years? A 32‑Bit Overflow Experiment

DOOM, released in December 1993, is a landmark first‑person shooter that has endured for more than three decades.

A geek named Minki wondered whether a rarely noticed 32‑bit integer overflow bug in the engine would ever trigger in reality, so he set up an experiment running the game continuously on an old handheld device.

He installed a port of WinDOOM on a 2003 ASUS MyPal A620 handheld (Windows Mobile, Intel XScale ARMv5) and DIY‑modified a 18650 lithium‑ion cell UPS, feeding it power through a router’s USB port to keep a stable 5 V supply.

The device was left untouched for about two and a half years, after which the game finally displayed an “application has crashed” prompt.

The root cause lies in the gametic timer variable, which increments at a fixed 35 Hz using a signed 32‑bit integer. Because it never resets, after roughly 2.147 billion increments—about 1.95 years at 35 Hz—it overflows, wrapping around to the negative range and causing the crash.

John Carmack, the original engine developer, likely considered this harmless because reaching the overflow would require more than two billion frames—an amount no normal gameplay would achieve.

The experiment confirms the theoretical overflow: after about 2.5 years the game indeed crashes, illustrating that long‑running client programs can hit hidden boundary conditions.

Similar issues have been reported in other games: a constantly increasing int32 counter in Crash Bandicoot 3 would overflow after roughly 2.26 years, and a hidden weapon in Final Fantasy IX becomes obtainable after the game’s timer wraps around after more than a year.

The takeaway is that developers often assume users won’t keep programs running indefinitely, overlooking edge cases like integer overflow, and that undefined behavior in C can produce surprising results.