Camera driver file corrupted: reinstall, don't copy files

A vision station that ran clean for months suddenly refuses to open one camera type. The configuration tool lists the other descriptor files without complaint, this one throws an open or parse error, and the camera itself works on the bench machine. The reflex is to grab the suspect file from a look-alike station and drop it in. That reflex turns a 20-minute repair into an afternoon, because the file is only half of what the tool checks. This guide shows how to confirm what is actually broken, repair it the vendor-documented way — uninstall, reinstall from the installer, reboot, verify — and keep every station on the floor rebuildable in under half an hour. It is written for anyone maintaining Windows vision stations built on area scan cameras and vision controllers.

One descriptor fails, the rest load

A camera configuration tool keeps a library of driver and descriptor files, one per camera family or video standard: an .icd descriptor for a legacy frame grabber, a GenICam camera description XML for a GigE Vision or USB3 Vision camera. Damage to one file produces a distinctive pattern. Every other camera type still lists, opens and acquires. Only the damaged type fails, and it fails at load, with a read or parse error before any camera hardware is touched. The camera itself usually acquires fine in a second application, which tells you the fault lives in the file and its registration rather than in the device.

Corruption has a short list of origins. An install or update interrupted mid-write is the most common. An unclean shutdown while the tool was writing is the second. A hand edit that saved malformed content is the third. A failing disk is the rare case and the serious one, because it will damage the replacement file too.

The repair path below handles the first three origins identically. Before running it, spend two minutes proving the file is actually the problem.

Know which family you are repairing before you fetch anything. The family follows the camera's interface, not its brand: a GigE camera such as the MV-CU020-90GC loads through the standard GigE Vision and GenICam path, so the SDK installer that covers it is the package to keep with the build sheet.

Test first: compare bytes, don't replace them

Copy the same-named file from a station running the same software version, then run a byte-for-byte comparison between the two copies. The result decides the path:

• The files differ. The suspect copy is genuinely altered — an interrupted write, a bad edit, or disk damage. The documented fix below rebuilds the file and its registration together.
• The files are identical. The file was never corrupted. The fault sits in the registration and version state around it, which is exactly what a file copy cannot repair — and in practice this is the more common result.

Two quick tests close the loop. Open the same camera type in a second application to take the hardware out of the question. Then check the installed-programs list for two SDK versions sitting side by side, which is the classic mismatch behind a seemingly broken descriptor.

Why a copied file fails anyway

The tool checks more than bytes. Ranked by how often each cause turns up on the bench:

1. Stale or missing registration. The installer records the descriptor's location and version in entries the runtime reads at start-up. A file dropped in by hand updates none of them, so the tool keeps reading the old record and keeps failing.
2. Version mismatch. The descriptor format moves with the SDK that writes it. Call your installed tool version 4.2 and the donor station's file 3.9 — an illustrative pair, but the shape is common: intact bytes, a runtime that validates against the 4.2 registration, and a 3.9 file that was never registered there.
3. Genuine damage. The interrupted-write case. The copy does fix the bytes, and fixes nothing else, so the station fails exactly as before.
4. Wrong family. The donor file belongs to a different SDK generation than the one installed. This one has its own diagnosis; see the last section.

Version drift between builds is what makes donor files unreliable, which is why step 2 of the fix insists on the exact installer your station was built with.

The documented fix, in order

Work in a maintenance window; the camera is down for the length of the repair. Back up the application's saved jobs, calibrations and camera user sets first — a driver reinstall should not touch them, and a backup makes that assumption free to test.

1. Record what is installed. Note the driver package and its version from the installed-programs list. The replacement must match the software the station runs.
2. Fetch the matching installer from the vendor's official download or the supplying distributor. Keep the file — it becomes the station's recovery media.
3. Uninstall the existing driver entry from the installed-programs list, and reboot if the uninstaller asks. This clears the stale registration that a file copy never could.
4. Run the installer as administrator. Choose the repair option when the installer offers one; otherwise run the full install over the existing path. If it stops on a permissions error before installing anything, clear that first — see the admin rights fix.
5. Reboot and reconnect the camera, letting Windows re-enumerate it against the fresh driver.
6. Open the tool and load the descriptor. It should list and open without error. The checks below prove it.

Verify: four checks that prove the repair

• The tool lists the descriptor and opens it, and shows the version you installed rather than a leftover one.
• The camera enumerates with its correct model string, both in the vendor tool and under Windows Device Manager.
• A 100-frame acquisition completes with no dropped frames and no errors in the log.
• A cold start holds: full shutdown, power off, boot, and the same descriptor loads again. This one matters because an unclean shutdown is one of the two common origins of the damage.

After the repair, leave the driver alone in daily operation. Exposure, gain and white balance changes run through the runtime and need no driver operation — the runtime exposure control article shows the pattern. If a fix seems to demand pulling driver files again, treat that as the sign that the root cause was never repaired.

Worked example: two paths in minutes

Assume one Windows station, one camera family, no hardware faults, and the installer already sitting on the network share. The times are typical bench estimates; add five minutes to the documented path if the package has to be downloaded first.

Documented path: 5 minutes to fetch the installer, 2 to uninstall the broken entry, 6 to run the repair, 2 to reboot, 5 to re-enumerate and run the 100-frame check. That totals 5 + 2 + 6 + 2 + 5 = 20 minutes.

Copy path: 10 minutes to find a donor station at the same version, 2 to drop the file in, 90 for two rounds of compare-adjust-reboot while the tool keeps failing, then 20 for the documented repair you end up running anyway. That totals 10 + 2 + 90 + 20 = 122 minutes.

The decision follows from the arithmetic, not from principle. Any scenario where the donor file is even slightly uncertain — different patch level, unknown SDK history — makes the copy path longer still, because the 90 minutes of troubleshooting grows faster than the 20-minute repair shrinks.

Prevention: keep every station rebuildable

• A golden image per station model. A documented OS image restores driver files and registration as one tested state, which is the right heavy repair when several components are suspect at once.
• A build sheet with versions. SDK version, driver version, camera models and the installer files themselves, kept together. Version drift between stations is what makes donor files useless.
• Scheduled application backups. Jobs, models and calibrations, backed up on a schedule and after every change, so a rebuild never becomes a re-teach. Losing models after a restart is its own failure mode — see the configuration recovery article.
• One camera family per station type. A standard fleet means identical driver sets and images; the camera finder narrows models by interface, resolution and shutter when you set that standard.

The right hardware keeps the rebuild small. A vision controller such as the MV-VC2140-128G40-1T holds the OS, the SDK and the camera drivers on a single box, so the golden image and its installer set describe the whole station rather than a bare Windows install.

When a reinstall will not fix it

• Every camera of one family fails, not one descriptor type. That points at the SDK generation rather than a damaged file; the driver family mismatch article walks that diagnosis.
• A Linux station loads the wrong sensor driver at boot. Different fault, different fix: read the kernel log and correct the sensor overlay, as the wrong sensor driver article shows.
• A USB camera reports a missing configuration file. That is a device-class problem, not corruption; see the USB configuration file article.
• Two frame grabbers error only while both run. Bus resource contention, not any descriptor file. Sort out slot and resource allocation before touching software again.
• The same file corrupts again after a clean reinstall. Stop reinstalling and suspect storage or an unclean-shutdown loop. Cameras and controllers ordered from us include free expert support, so start at the contact page.

Building or standardizing a station now is the cheapest time to make this repair unnecessary: pick the camera family once, keep its installer with the build sheet, and the 20-minute path stays a 20-minute path. The camera configurator walks the camera, lens, light and controller choices in order.