Camera stuck in use after a crash: recover without a reboot

A crashed acquisition program leaves the camera locked: your next run opens nothing, the live viewer refuses, and the quick fix everyone reaches for is a restart that costs two to three minutes each time. You do not need it. This guide gives the recovery ladder in the order that works — end the leftover process, wait out the lease, reset the driver, the host controller or the camera itself — with the time each step takes, the register-level reset for legacy IEEE 1394 cameras, and the teardown pattern that keeps the next crash from locking anything.

Why is the camera locked after the program crashed?

The crash skipped your close call, so the camera session is still marked open: the driver keeps the exclusive lock and the camera may still be streaming, which is why every new open returns in use.

A camera session is exclusive by design. The SDK's open call tells the driver to reserve the device and, on streaming buses, to allocate bandwidth; the close call stops the stream and releases the reservation. A hard crash skips both, and two leftovers remain. The first is host-side bookkeeping in the driver, which usually dies with the process but not always. The second is camera-side: the device never received a stop, so it can sit mid-stream, waiting for packets that will never arrive. Task Manager shows nothing because the process really is gone — the lock lives below it. On Linux the same class of fault appears as stale lock files; the stale /dev/shm device lock fix covers that variant.

One distinction before you start. If a live process is still listed and holding the device, that is a different case: find the owner and release access first. What follows is for the residue a dead process leaves.

Which recovery do you try first, and in what order?

Work down four steps — end the leftover process, wait out the session lease, reset the driver or host controller, then power-cycle the camera — and you will almost never reach for the reboot button.

1. End the leftover process. Check Task Manager (or ps on Linux) for a hung copy of your own executable and end it. The kernel closes the session with the last handle, so this alone clears many cases.
2. Wait out the lease. GigE Vision devices release control by themselves once heartbeats stop; the timing is in the GigE section below.
3. Reset the driver layer. Force a 1394 bus reset, or disable and re-enable the NIC or USB host controller in Device Manager. This is the step that clears host-side bookkeeping.
4. Power-cycle the camera. Ten seconds without power, then let it boot. This is the only step that reaches camera-side residue.

After each step, attempt the open. Stop at the first step that works and note it — that ordering is also your startup watchdog.

How do you reset a FireWire camera without a reboot?

Force a bus reset: disable and re-enable the IEEE 1394 host controller, and the bus re-enumerates in about one second, dropping the stale session and freeing the camera.

A bus reset is a normal event on this bus — every plug-in triggers one, and every node re-registers — so forcing it is a supported path, not a hack. Refresh the device list in your acquisition tool first; a stale enumeration sometimes clears on a refresh alone. If the open still fails, open Device Manager, find the 1394 bus host controller, disable it, count two seconds, enable it again. The re-enumeration sweep takes about one second with one or two cameras on the bus; give it five before you reopen. The stale isochronous allocation dies with the old enumeration, and the camera answers the next open.

For the stubborn case, go one layer lower. DCAM (IIDC) cameras define a reset register — INITIALIZE — in their control register set, and many SDKs expose a raw register-write call for it; some teams keep that call compiled as a tiny standalone recovery executable for exactly this moment. Take the register address and the reset value from the camera's IIDC register map, write it, and the camera re-initializes without losing power. Saved user sets survive, because a register reset is not a settings change.

Why won't a GigE camera open after a crash, and how long does the lock last?

The camera is holding a control lease that expires on its own: GigE Vision requires your application to send heartbeats, and when they stop, the device must release the session, usually within a few seconds.

The timeout is a device setting, and on machine-vision cameras it sits in the few-seconds range, so the recovery is mostly patience: end the hung process, wait ten seconds, reopen. If the open still fails, ping the camera. A camera that answers a ping but refuses to open is holding a session on its side — drop its power for ten seconds (unplug the Ethernet cable at the camera, or at the injector), let it boot, and it comes back with a clean session table. Disabling and re-enabling the NIC is the host-side version of the same move; on a PoE port it usually withdraws power too, so the camera reboots rather than only losing packets.

Keep the camera network on its own interface card, so a disable-and-enable during recovery never takes the office network down with it.

On a two-port card you can reset one camera's link while the second port keeps its camera streaming — one crashed run need not stop the whole cell.

An open failure with no crash behind it is a different fault tree; camera detected but cannot be opened walks the adapter and pipeline checks worth ruling out.

What is the equivalent reset for USB3 and CoaXPress cameras?

Reset the layer that owns the link: for USB3 that is the camera cable or the USB host controller, for CoaXPress it is the frame grabber card the camera is plugged into.

USB is the forgiving interface. When the process dies, the operating system cancels its transfers, so most USB3 crashes clear with a plain reopen. When the camera was killed mid-stream and stays wedged, unplug it for ten seconds and replug; enumeration takes a few seconds. If the controller itself is stuck — the camera vanishes from the device list and stays gone — disable and re-enable its USB host controller in Device Manager. The checks that separate a dead camera from a dead controller are in the USB recovery after a capture crash guide.

The catch with controller resets is collateral damage: disable the wrong controller and the keyboard, dongles or network go down with it. Put the cameras on a controller card of their own.

Four dedicated ports mean a reset there never touches the controller serving the keyboard and mouse.

CoaXPress has no session lease to wait out: the frame grabber owns the link, and the camera never learns that your program crashed. Reset the grabber — most SDKs expose a device reset for it — and power-cycle the camera as well. For a CoaXPress camera the recovery lever is the frame grabber itself.

How do you stop the next crash from locking the camera?

Put the close call where the crash cannot skip it: a finally block (or RAII or a context manager) that stops the stream and closes the session on every exit path, with one session kept open for the camera's life.

Close calls fail in crashes because they sit in the normal path, after the loop. Move them where unhandled exceptions and control-c still reach:

cam = None                        # session handle, SDK's own type
try:
    cam = sdk.open(device_id)     # your SDK's open call
    cam.start()
    while running:                # acquisition loop
        frame = cam.get(timeout_s=5.0)
finally:
    if cam is not None:
        cam.stop()                # end the stream first
        cam.close()               # release the exclusive session

The names are illustrative; every SDK has equivalents for open, start, stop and close, and the order matters — stop the stream before the close, or the close can fail mid-frame. The test that proves the pattern: raise an exception deliberately inside the loop in a debug build. The finally block runs, and the next open succeeds with no reset.

Then cover the exits a finally cannot catch: register a handler for control-c and termination signals that stops and closes the session, and accept that a hard kill leaves the recovery ladder above as the remedy. Keep exactly one session for the camera's life instead of opening and closing per frame — repeated open-close cycles leak handles, which the open-close cycle leak guide documents — and stopping a camera safely from several program loops covers the multi-consumer case.

When is a reboot still the right answer?

Reboot when the host controller itself is wedged: the disable-and-enable never completes, the bus vanishes from Device Manager, or the camera stays silent even after a clean power cycle.

Three signals, three responses. A controller that hangs mid-reset means the kernel driver is wedged; only a restart clears it, and the restart is doing the same disable-and-enable at a deeper level. A camera with no ping and no enumeration after a clean ten-second power cycle and a known-good cable is a camera fault, not a session fault — send it down the vendor's documented recovery path, firmware reload with their own tool, not third-party firmware. And if the crashes repeat daily, the ladder is treating a symptom: audit the teardown, because the prevention section is the fix that ends the reboots.

That is the whole ladder. If it keeps pointing at hardware — a grabber that will not re-enumerate, a NIC that drops link under load — pick replacements from the frame grabbers and area scan cameras categories, or set the camera and controller pair up in the camera configurator. If the camera is still locked after the full ladder, contact the applications team with the SDK, the interface and the exact error string; more capture-pipeline fixes sit on the systems topic page.