Crash Reporting for Kiosk and Arcade Cabinet Games

A game on a desktop has a player who can take a screenshot, write a sentence, and click submit. A game running on an arcade cabinet at a festival or a kiosk in a museum lobby has none of that. When it crashes, the only witness is a confused visitor who shrugs and walks away, and the only sign anything went wrong is a black screen that stays black until someone notices days later. Unattended games invert the whole crash-reporting problem: the machine must detect its own failure, recover on its own, and report what happened to you without anyone touching it. This post covers how to build that.

There is no user to file the report

Every consumer crash-reporting flow assumes a person who noticed the problem and chose to tell you. On a cabinet there is no such person. The visitor who triggered the crash is not your customer, has no account, and will not fill in a form. The operator who owns the machine may visit it once a week. This means a crash that would generate fifty reports on a desktop game generates zero on a cabinet, and the only evidence is lost playtime. Your reporting cannot depend on a human pressing a button, because no human ever will.

The practical consequence is that the game has to be its own reporter. An uncaught exception, a renderer hang, or a hard freeze must be detected by the software itself or by a supervising process and turned into a report automatically. You are not asking a player what they did, you are reconstructing it from logs and state you captured before the crash. That shifts the design toward heavy automatic context capture and a supervising watchdog, because once the screen goes black there is nobody around who can help you understand why.

Recover first, report second

The visitor experience matters more than your debugging convenience, so the first priority is getting the game back on screen fast. A watchdog process that monitors the game and relaunches it within a couple of seconds of a crash turns a dead cabinet into a momentary flicker that the next visitor never notices. The watchdog should also catch hangs, not just hard crashes, by checking that the game is still rendering frames or answering a heartbeat, because a frozen attract loop is just as broken as a crashed one even though the process is still alive.

Recovery and reporting are separate jobs and should not block each other. The watchdog restarts the game immediately, while the crash details get written to local disk to be uploaded later. Never make recovery wait on a network call, because the venue wifi may be down and you cannot leave the cabinet dark while a report retries. Design it so the worst network conditions still produce a fast restart and a queued report, and the best conditions simply upload that report sooner. The machine should always favor being playable over being perfectly observed.

Queue locally, upload when you can

Cabinet network access is unreliable by nature. The machine may be on a flaky venue connection, behind a captive portal, or entirely offline for the duration of an event. If your reporter drops a crash because the upload failed, you lose the one piece of evidence you had. Instead, write every crash and its context to a durable local queue on disk first, then drain that queue opportunistically whenever connectivity returns. A crash that happened on Saturday at a convention can still reach you on Monday when the operator brings the unit back online.

A local queue also smooths the case where one bad build crashes repeatedly. Rather than hammering your endpoint when the network finally comes back, batch and deduplicate before upload so a cabinet that crashed two hundred times sends a compact summary instead of two hundred near-identical payloads. Cap the queue size and age so a long offline stretch does not fill the disk. The principle is simple: capture is local and reliable, upload is remote and best-effort, and the two are decoupled so a missing network never costs you data.

Fixed hardware is a debugging gift

The flip side of unattended operation is that the hardware never changes. A cabinet has one GPU, one driver version, one screen resolution, one input setup, and it stays that way for years. This is a luxury that desktop and mobile developers never get. It means a crash you reproduce once is a crash you can reproduce forever, and a fix you verify on one identical unit holds on all of them. Stamp every report with a stable machine identifier and the exact hardware and OS profile so you can confirm a fleet is uniform and spot the one unit running an outdated image.

Use that stability. Track uptime and restart counts per machine so a unit that quietly reboots every twenty minutes stands out against a fleet that runs for days. Capture the attract-mode versus active-play state at crash time, because the failure modes differ: a leak that only shows after hours of idle attract looping is a different bug than one that fires mid-game. With fixed hardware and good per-machine context, you move from guessing to a tight, repeatable loop where every crash maps to a known unit you can physically go inspect.

Setting it up with Bugnet

Wire the Bugnet SDK into your cabinet build and the automatic capture does the job no visitor ever will: uncaught exceptions and crashes are recorded with stack traces, the machine identity, OS and driver profile, and recent state, then queued locally and uploaded when the network allows. There is no button to press and no form to fill, which is exactly right for a runtime with no user. Pair it with your watchdog so the game restarts instantly while the report travels separately, keeping the screen alive and your evidence intact.

Because the same handful of cabinets crash in the same handful of ways, Bugnet occurrence grouping collapses a fleet-wide failure into one issue with a count and a list of affected machines, so you immediately see whether one unit is sick or the whole installation is. Custom fields carry your build version, venue, and machine ID, and player attributes become machine attributes, letting you filter to a single problematic cabinet from one dashboard. That turns a silent black screen across the country into a prioritized, attributable issue you can act on.

Build a self-healing, self-reporting cabinet

Treat the cabinet as an appliance that must run for weeks untouched. Boot directly into a watchdog that launches the game, restarts it on crash or hang, and logs every restart. Disable OS update prompts, screensavers, and notifications that can steal focus or interrupt the attract loop. Ship a known-good image you can reflash, and keep one identical unit on your bench so reproduction is trivial. The aim is a machine that an operator can power on and ignore, confident it will recover from anything short of a hardware failure.

Then close the loop with telemetry. A nightly heartbeat that reports uptime, restart count, and queued-crash count tells you a cabinet is healthy even when it has not crashed, which is the signal you actually want from an unattended fleet. When a new build goes out, watch the restart rate across machines for a day before declaring it stable. A cabinet game that heals itself and reports for itself lets a tiny team run installations in venues they will never visit, and still know exactly how every screen is doing.

On a cabinet the machine is the only witness. Make it recover instantly and report for itself, because no visitor will ever file a bug for you.