Doom crash after 2.5 years of real-world runtime confirmed on real hardware

Crash cause and reproducibility

• Several commenters are skeptical until they see an independent reproduction, noting the port is for PocketPC with no code snippet shared.
• Debate over whether the crash was due to the game or the OS: some argue the OS error dialog suggests a system-level failure; others point out the article explicitly attributes it to a game-engine counter overflowing, so any OS would see the same crash.
• One commenter dissects the description (a counter compared to its previous value) and notes that alone shouldn’t obviously crash, suggesting more detail is needed; they also note that Doom’s core tick rate (35 Hz) doesn’t neatly match the ~2.5-year 32-bit overflow timeframe, which raises questions.

Tiny hosting stack and HN “hug of death”

• The original forum runs on extremely constrained hardware (reported as 32 MB RAM, even an IP camera), which impressed many, especially given how slow tools like Jira feel by comparison.
• The site struggled to load for many due to Hacker News traffic; the operator later reported about 1,500 concurrent users exhausted RAM and caused restarts, but it recovered.
• Some find the minimalist, fast setup admirable; others joke about it being run on a router or disposable vape.

Time overflows and 2038/NTP concerns

• The Doom bug triggers a broader discussion of 32‑bit time counters and the 2038 problem.
• People highlight that 2038 feels much closer than Y2K did, and that many embedded or closed-source systems may fail unless moved to 64‑bit time.
• NTP’s 2036 era rollover is mentioned; correct implementations should handle it, but many cheap devices may not.

Game timer glitches and design intent

• Commenters supply similar examples: Crash Bandicoot’s timer overflowing after ~2.26 years, Final Fantasy IX’s two‑year wraparound used to obtain a late-game weapon, and long‑horizon glitches in titles like Paper Mario.
• There’s discussion of how, in the 32‑bit era, assuming no one runs a game continuously for years was reasonable, given design lifetimes and hardware constraints.
• Some frame this as analogous to engineering for a finite “design life” rather than indefinite reliability.

C integer overflow and undefined behavior

• Several comments dig into C semantics: signed overflow is undefined behavior, unsigned is well-defined wraparound.
• They speculate that incorrect assumptions about a monotonically increasing counter, combined with UB or unchecked cases (e.g., unexpected comparison results, division by zero, bad indices), could cause deterministic crashes even on different platforms.

Doom, modern FPS design, and ownership

• Many express enduring affection for classic Doom and Doom 2016, while criticizing more arena‑style, “hub‑based” modern shooters.
• There’s mention of “boomer shooters” as a genre recapturing classic, linear, run‑and‑gun gameplay.
• Side discussion notes that Doom and many other historic PC franchises now belong to Microsoft, prompting debate about how much of PC gaming they effectively control.

Historical uptime bugs and test horizons

• A Windows NT 4 uptime bug (~49 days) is recalled as a similar timer overflow issue that forced scheduled reboots on servers.
• Several remark that running any modern stack or game cleanly for 2.5 years is itself remarkable, and far beyond what most testing cycles ever cover.