For most of a year our unattended booth failed on somewhere between one in ten and one in twenty capture sequences, and almost none of it was the software’s fault in the way we thought. We were running an established booth application, one with a long track record, and we spent months blaming it. When we finally sorted the failures by actual cause, the list looked nothing like our assumptions. This post is that list. If your photo booth software keeps crashing, work down it in order before you switch tools, because switching tools does not fix a USB cable. We did eventually write our own software, so there is an interest here, and we will point to the two places where the software itself was the answer.
Photo booth software crashing: first, decide whether it crashed
Photo booth software crashing is four different events wearing one name. “The booth crashed” covers four of them, and they have different causes.
The application closed and the desktop is showing. Or it is open but frozen on one screen. Sometimes it is open and working, with something else sitting on top of it. And sometimes nothing is wrong with it at all, because the camera, printer or reader has gone away. Only the first one is a crash. Look at the machine before you touch it, and write down which of the four you saw, because the fix for each is different and the logs for each are in different places.
Cause 1: the camera dropped and the software fell over
This was most of our failures. A tethered camera is a USB device, and USB devices leave for reasons that have nothing to do with the booth application.
The cable. Longer than six feet, or a cheap one, or one routed past the printer’s power supply. Both LumaBooth’s and Darkroom’s support pages open with the cable, and they are right to. Use the cable that came with the camera and keep it short.
The hub. An unpowered hub cannot feed a camera and a touchscreen at once. Plug the camera directly into the computer, or into a powered hub, and never into the hub on the back of the monitor.
Where the power actually goes
Windows cutting power to the port. USB selective suspend is on by default and it will drop an idle camera after a quiet hour. It is in the advanced power plan settings. Turn it off on every booth machine. This one setting removed a whole category of our “overnight” failures.
The camera set up for photography instead of for a booth. Auto power-off, wireless radios and anything that makes the body think between shots all cost you captures, and disabling them is a menu job rather than a software one. The full list of what to change and what to lock is in photo booth camera settings; the reason it belongs on this page is that every one of those defaults produces a failure an operator reads as a crash.
Somebody has to own these failures. On our placed machines that is us, through permanent photo booth installation in Florida.
Another application holding the camera. Canon’s EOS Utility launches itself when a body is plugged in and claims the connection before the booth can. Disable its autolaunch. The Canon community forums are full of this one.
Heat. We investigated overheating on a Canon R50 as a source of what looked like software crashes, because a body that thermally shuts down looks, from the software’s side, exactly like a body that was unplugged. A closed cabinet in Florida is warm. If your failures cluster in the afternoon, suspect heat before suspecting code.
Cause 2: photo booth software crashing over one of its own settings
One failure was the application’s. Our previous software polled a status URL every second, and that polling was implicated in the intermittent crash; the vendor’s support recommended stretching the interval to sixty seconds and doing a clean reinstall. It helped. It also told us something about how the software was built: a feature meant for monitoring was destabilising the thing it monitored.
The lesson we carried into VertexBooth is that anything the booth does on a timer, whether that is a status check, a gallery upload or an update, must be unable to interrupt a capture. Our own updates run on a schedule and are blocked while a session is open, for exactly this reason.
Cause 3: nothing crashed, but something got on top
This is photo booth software crashing in appearance only. One morning our booth was invisible under a full-screen browser that an overnight Windows update had launched. Nothing had failed. A guest saw a browser and walked away. We covered the Windows side of this in the computer post; the software side is that kiosk mode has to keep the booth window on top and reclaim the screen if something else takes it. That is a software job, and it is one of the two places where switching software was the actual fix for us.
Almost every list of camera disconnect causes agrees on the cable and the hub, including Darkroom’s own troubleshooting page, which opens with both.
Cause 4: the payment hardware went away quietly
A booth that takes cards has a reader and a bridge, and either can drop. Our bridge board reset intermittently for a week until we found it was a grounding issue: two jumpers that needed to be closed, one of them missing its cap. The reader’s connectivity alerts, which looked like hardware faults, turned out to be network drops. Neither was the software, and both looked like “the booth is down” from across the lobby.
The software’s job here is to fail well: keep the session going for a guest who has already paid, show a clear message if payment is unavailable, and log it so you know in the morning. Ask any vendor what their software does when the reader disappears mid-transaction. The answer tells you whether they have run a machine unattended.
Software that tells you it is down
Twelve kinds of phone alert and a live status page per booth, so a failure reaches you before it reaches a guest.
Two things we changed in ours after living with this. Every line to and from the bridge goes to a payment trace log, so a disputed evening has a record instead of an opinion. And a serial port that Windows closed underneath the booth is reopened on the next request rather than staying dead until somebody reboots the machine.
Cause 5: photo booth software crashing with nothing to restart it
Everything above assumes the application is running. When it does exit, on an attended booth somebody double-clicks the icon. On an unattended one, the machine stays dark until the next service visit. We built a watchdog for our previous software with Task Scheduler that relaunched the process if it disappeared. In VertexBooth the launcher does that job itself, restarting the booth if the process ends.
Photo booth software crashing: the order to work through it
| Symptom | Check first | Then |
|---|---|---|
| Camera “not detected” after idle time | USB selective suspend, camera auto power-off | Cable, hub, EOS Utility autolaunch |
| Random failures mid-session | Cable and hub | Timer-driven features in the software |
| Failures cluster in the afternoon | Heat inside the cabinet | Camera thermal shutdown |
| Booth invisible, something else on screen | Windows Update, browser autolaunch | Kiosk mode that reclaims the screen |
| Reader drops, bridge resets | Grounding jumpers on the bridge | Network, then the reader |
| Application gone, desktop showing | Watchdog or launcher restart | Application logs |
Photo booth software crashing: questions we get mid-crisis
Is my photo booth software crashing, or is it my hardware?
Count the failures for a week and note what you saw each time. If most are “camera not detected,” it is USB and power, not software. If most are “application closed,” it is software or heat.
Should I reinstall the software?
After the checks above, yes. Before them, a reinstall resets your settings and teaches you nothing.
Will switching to VertexBooth stop my photo booth software crashing?
It will fix the two that are the software’s to fix: something covering the booth window, and a timed feature interrupting a capture. It will not fix a cable, a hub, a hot cabinet or a grounding jumper, and we would rather tell you that here than have you find out.
Why does an unattended booth fail more than an attended one?
It does not. It fails the same amount and nobody notices for a day. Every failure above happened on machines that would have been fine with a person beside them. That is the real argument for alerting: not that unattended machines break more, but that nothing is standing there to see it.
How do I find out about a failure before a guest does?
Have the machine tell you. Ours pushes twelve kinds of alert to a phone, each with its own switch, including a card declined and a text or email that did not send, because the guest whose photos never arrived has already walked off. Word-for-word repeats are held for ten minutes, which matters more than it sounds: a printer that faults and clears every few seconds is forty pushes in a minute, after which the notification service starts refusing them and the one that mattered never lands.
We are going to keep publishing the failure list as it grows, with the causes sorted by what actually happened, because the year we lost blaming the wrong thing is the year we would most like to give somebody else back.
Software that tells you it is down
Twelve kinds of phone alert and a live status page per booth, so a failure reaches you before it reaches a guest.
