Camera enumeration fails: clear the camera XML cache safely

Your camera enumerated reliably for months; then a firmware update, a new SDK install or a PC rebuild, and the discovery tool shows nothing, or shows the device with an error that names a description file. Most of the time the cached camera XML is the cause, and the fix is a two-minute folder clear on Windows or Linux. This guide gives you the failure mechanism, the date test that confirms it, the exact hidden folders on each operating system, the checks that follow if the camera stays dark, and the habits that keep the cache from going stale again. The same logic covers GigE Vision and USB3 Vision cameras; only the folder names change.

Why does a camera stop enumerating after a firmware or driver update?

In most update-related failures the cached camera description file is stale: your SDK still parses the XML it generated for the old firmware, the new register map no longer matches, and the producer drops the device before it reaches your camera list.

Enumeration is a negotiation. The camera holds its register map in firmware and describes it to the host as a camera description file, an XML document written to the GenICam standard. To keep start-up fast, the SDK writes that file into a hidden cache folder the first time it sees a camera of a given model and firmware revision, and reuses it on every later enumeration.

Update the firmware, and the camera answers with a revision the cached file does not describe. Parsing fails, the producer raises an error that names the description file, and the camera never appears. A file-path error is the sibling failure — the host cannot find the file at all — and it is repaired in the same folder. The GenTL XML file location guide covers the path side in detail.

How does a cached camera description file break enumeration?

The break happens at parse time, before any image settings are negotiated: the SDK reads the cached XML, meets a register layout the camera no longer uses, raises an error that names the description file, and marks the device unavailable.

At each enumeration the SDK discovers the device, reads its identity, opens the cached description file for that model and revision, and checks it against what the camera reports. On a mismatch, or on a file that arrived on disk half-written, parsing stops right there.

Two error signatures point at this folder. One names the description XML directly. The other involves a ZIP archive, because many SDKs ship and cache the file compressed; the camera XML ZIP errors guide handles that variant. A schema validation assertion reads more alarming than it is: it means the parser rejected a file, not that the camera is damaged, and the schema assertion guide walks through why.

How do I confirm the cache is stale before deleting anything?

Check the dates: if the cached file's last-modified timestamp is older than the day you updated the camera firmware or installed the SDK, the cache is stale, and clearing it is the correct next step.

Sort the cache folder by date modified: a file generated before the update, now serving a camera that changed under it, is the failure made visible. Two checks sharpen the diagnosis. Does another camera of the same model, first connected after the update, enumerate normally on this PC? Then the host handles the new revision fine and only the old file is stale. Does the failing camera enumerate on a second PC? Then the camera is healthy and the fault is local. Only when it fails on both machines, after a cache clear on both, does the camera itself come under suspicion.

When the dates do not settle it, work this table top to bottom; each row has a test that takes minutes.

Where is the camera XML cache on Windows and on Linux?

On Windows the cache sits in a hidden folder under C:\ProgramData, in a folder named after your camera SDK; on Linux it lives in a hidden directory under ~/.config, in a directory named for your SDK with an xml subfolder holding the generated files.

On Windows:

1. Close every application that opens the camera, including any background service that streams from it.
2. In File Explorer, open the View tab and tick "Hidden items"; on Windows 11 it is View → Show → Hidden items.
3. Open C:\ProgramData and enter the folder named for your camera SDK, then its description-file subfolder.
4. Delete the files named for the failing camera's model and serial, or empty the whole subfolder; every file in it is generated output, so both are safe.
5. Re-run enumeration. The SDK rebuilds the file from the camera within seconds and the device appears.

On Linux, hidden directories start with a dot, so a plain ls skips them; ls -la ~/.config/ shows them. Delete the contents of that xml subfolder, re-run enumeration, and the producer regenerates the file from the camera at the next attempt.

One neighbouring Linux trap: with several USB cameras attached, unstable device paths can mimic an enumeration failure. The multiple USB cameras on Linux guide covers that case.

The camera still won't enumerate — what should I check next?

Work the remaining causes in order — full power-cycle, version match, cable swap, second PC, then driver isolation — and each test removes one suspect in under five minutes.

1. Power-cycle the camera, not the PC. Switch the camera's power off, or disable its PoE port on the switch, wait about 10 seconds, and restore it. A link reset re-establishes the network path; only a power cycle resets the camera's own state.
2. Match the SDK to the firmware. Confirm the installed SDK release supports the firmware version you loaded; if not, update the SDK first. A validation warning naming firmware compatibility is the tell, and the firmware validation guide explains the checks.
3. Swap the cable. A marginal cable can fail enumeration exactly as it drops frames mid-stream. Replace it with a known-good camera data cable of the right family for your interface; for drag chains and moving axes, a high-flex build with locking connectors removes the most common physical cause. The accessories finder filters cables by type and length.

4. Try a second PC. One test separates machine-side from camera-side faults. If the system device list reports an error for the camera, work the isolation steps in the device-not-functioning guide.
5. Condemn the camera last. Dark on two PCs, two known-good cables and a cleared cache on both, the fault is inside the camera. The area scan cameras category, the camera finder and the camera configurator narrow a replacement by interface, resolution and sensor format.

How do I keep the cache from going stale again?

Update the SDK and the camera firmware as a matched pair, power-cycle the camera after every update, and let one SDK version own each cache folder.

• Match versions before you update. Read the SDK release notes for the firmware version, and install the pair together rather than firmware today and SDK next week.
• Keep one SDK version per PC where you can. Two installed versions can share one cache folder and overwrite each other's files; if you must keep both, expect a cache clear after every switch.
• Power-cycle after updates. The first enumeration after an update rebuilds the cache, and a cold camera makes that rebuild clean.
• Treat description-file errors as cache problems first. An error naming the XML, or a schema assertion, points at the cache before it points at hardware.

The decisions, in one line: cache file older than the firmware update — clear it; every camera of that model fails — match the SDK to the firmware; fails on two PCs — swap the cable, then replace the camera.

The pattern reaches past vision: a generated file cached for speed goes stale after a version change, and clearing the cache regenerates it. The same cache-clear logic, for an HMI project that refuses to open, is documented in this guide to an HMI project that won't open until its cache is cleared.

More systems-side troubleshooting like this lives on the systems topic page. If a cache clear and every check above leave the camera dark, send the enumeration log through the contact page and we will read it with you.