A GenICam driver error that clears after a few restarts and returns the next morning is rarely a broken driver file. The GenICam stack loads its driver only when it can match every camera in the configured-device list to a camera it can reach on the network, so an intermittent load failure almost always lives in that match. The checks below run in the order that finds the cause fastest — discovery lists first, addressing second, registry third, antivirus last — and end with the addressing scheme that stops the failure coming back. They apply to GigE Vision and USB3 Vision cameras behind any GenICam or GenTL producer.
Why does the GenICam driver load on some restarts and fail on others?
Intermittent GenICam driver failures are almost always configuration-matching problems: the driver loads only when every camera in its configured-device list is present on the network at the recorded address, so a camera whose address drifted between boots fails one start and passes the next.
GenICam application drivers keep a persistent list of configured devices — names, addresses and serial numbers recorded when the station was set up. At each start the stack discovers what is actually available and tries to pair the two lists. One configured camera that cannot be reached fails the whole load, even when every other camera is healthy. That is why the error text is generic while the cause is specific.
Two mechanisms produce the on-and-off pattern. A race at load time — an antivirus scanner holding a file, a NIC that is not yet up when the stack reads the network — explains a failure that clears on the second or third start with nothing changed. A corrupt local device registry explains the same pattern when the camera, the configured entry and ping all look correct. A failure that never clears points at a deterministic mismatch: the address, the subnet or a process holding the device.
Work the causes in this order: address drift, registry corruption, a process holding the device, antivirus last. If the configuration tool itself reports the camera driver package as not configured, that is a related fault with its own fix — see camera driver package not configured: restore camera detection.
What should I check first in the camera discovery tool?
Open your camera configuration or discovery tool and compare the available-device list with the configured list before touching any driver file: where each camera appears decides the fix in almost every case.
Every GenICam camera family has a configuration tool that lists discovered devices, and many vision packages show available and configured devices side by side. Record what you see for each camera before changing anything.
| What you see | What it means | Where to go |
|---|---|---|
| Camera listed as available, configured entry shows a different address | The camera's address drifted; the recorded entry is stale | Static addressing, below |
| Camera available and configured entry matches, load still fails | Corrupt local device registry | Registry reset, below |
| Camera missing from the available list, ping still works | Another process holds the device | Close or restart the holding application |
| Camera missing from both lists, no ping, link LED off | Power, cable or switch problem | Check cable, PoE budget, power |
| Error names a missing driver file or producer DLL | Installation or path problem | GenTL producer not listed: check Windows DLL paths |
On Windows, many configuration tools need administrator rights before they can change network settings. If the tool misbehaves until you elevate it, work through GigE configurator tool admin rights: fix the Windows error.
Why did the camera's IP address change since I configured it?
A camera running DHCP keeps its address only while the lease lasts; when the lease expires or the camera powers up without a DHCP server, it falls back to an automatically chosen link-local address in 169.254.0.0/16, which cannot match the configured entry.
DHCP leases are finite: office servers commonly issue 8-hour to 24-hour leases, a typical default rather than a rule. A station powered down on Friday at 17:00 and restarted on Monday at 09:00 has been off for 64 hours — more than any 24-hour lease, so the old address is not guaranteed, and the server may hand it to another device in the meantime.
Without a valid lease, IPv4 equipment self-assigns from the link-local range 169.254.0.0/16, reserved by RFC 3927 for exactly this purpose. The range holds 2^16 = 65,536 addresses; RFC 3927 excludes the first and last /24, leaving 254 × 254 = 64,516 addresses a device may claim at random after probing. Two cameras left on DHCP can come back with different link-local addresses than last time, while the configured list still points at the old DHCP values.
The arithmetic for the classic Monday-morning failure: a 24-hour lease against a 64-hour shutdown; 24 < 64, so the lease lapses, and the camera returns at a new address or a 169.254.x.y one. If the server still holds the old address free, the camera gets it back and the driver loads — which is exactly why the fault shows up on some Mondays and not others.
A camera sitting on a 169.254.x.x address is reachable only from a PC that also self-assigned into that range, which is why the link sometimes works from a service laptop and never in production. Opening such a camera from Linux is covered in GigE camera on link local address: open it by IP from Linux, and the reason DHCP blocks firmware-style maintenance in static IP address for a 3D camera firmware update: why DHCP blocks it.
What static IP scheme should a vision camera use?
Give every vision camera a static private address on a dedicated NIC and a subnet the factory network does not use — for a single camera, host 192.168.10.1/24 and camera 192.168.10.10/24 is a clean, conflict-free pair.
Put the cameras on a network card of their own, not the card that talks to the office. A dedicated NIC gives you the whole /24, keeps discovery broadcasts off the corporate network and removes any dependence on the office DHCP server. A vision controller makes this easy: the MV-VC3301H-128G66 carries 5+ LAN ports and 4 built-in light-output channels, so each camera group gets its own subnet with no expansion cards.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
Use a private range IT has not routed: 192.168.10.0/24 for the first station, 192.168.20.0/24 for the next, and so on. Keep the mask at /24 so discovery broadcasts stay inside the station subnet. The host NIC takes .1, cameras take .10 upward, and none of these addresses appears in any DHCP scope.
The 254 usable hosts of one /24 are ample for a station of a dozen cameras. Worked example, one camera: pick a global-shutter GigE model such as the MV-CU020-90GC, a 2.5 MP color camera with a C-mount on a 1/1.7" sensor. Write 192.168.10.10 with mask 255.255.255.0 into its persistent IP settings, and 192.168.10.1 with the same mask into the host NIC. Open a command prompt and ping 192.168.10.10 — on a direct 1 Gbps link, replies come back in well under 1 ms. Then add the camera as a configured device in the discovery tool and record its serial number on the station sheet.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
How do I rebuild a corrupt GenICam device registry?
When the camera and its configured entry agree — same address, ping good — and the driver still fails, the local device registry is corrupt, and the reset is to delete its database file, empty the cache folder and restart so the stack rebuilds it.
The GenICam stack behind the classic "error loading driver" message keeps its configured devices in a local registry: a registry.db file inside a GenICam XML Registry folder under the software's data directory, with a Files cache folder beside it. Half-written entries, duplicated serial numbers and leftovers from camera swaps corrupt it, and the stack then refuses to load even though everything visible looks right.
The reset is short. Close the vision software. Delete registry.db. Empty the Files folder. Start the software again — the registry rebuilds from the network, and you re-add the configured devices. If your stack names its registry differently, look for the equivalent: a small persistent database of configured cameras, with the vendor's documented reset for it.
A rebuild is also the moment to revalidate everything else the software remembers. The same discipline applies to vision models after a restart — missing vision models after restart: fix and validate covers the recovery checks.
Is another program or a hardware fault holding the camera?
A camera that is missing from the available list while the link LED and ping are good is usually held by another process on the PC — a crashed acquisition program keeps the device claimed until you close it or restart the machine.
GigE Vision allows one control connection per camera. Close every acquisition program, check the tray and services for anything camera-related, and try again; if the PC has not rebooted since the last crash, the claim may still be held. The mechanism and the restart fix are the same on Windows and Linux — see release a camera after a crash on Linux: GigE restart fix.
If ping fails too, work down the physical layer. A healthy 1 Gbps link shows link LEDs at both ends; swap the cable next, since a damaged cable is the most common physical cause. On PoE, check the budget: an 802.3af port supplies up to 15.4 W at the switch and about 13 W at the camera end, which covers most area scan GigE cameras' typical 3-10 W draw but not much else sharing the port.
USB3 cameras fail the same way when another program owns the handle; the USB-side checks live in camera has power but not detected: USB link checks after a cable swap.
Is antivirus or a Windows update really blocking the driver?
Antivirus real-time scanning can hold a driver file during load, but it is the last suspect, not the first: an address or registry problem explains an error that clears after a few restarts, while a genuine antivirus block fails every time until you add the vendor's documented exclusions.
Test it in one move: turn real-time scanning off, start the application three times in a row, and turn scanning back on. If the driver now loads first time, every time, the scanner was racing the loader — add the vision software's install and data folders to the exclusions through the antivirus console and leave protection on.
A Windows update is usually correlation, not cause — but it can break discovery indirectly. Updates restart the machine, which is when address and registry faults surface, and they can reclassify the camera NIC's network profile from Private to Public, applying stricter firewall rules that block the UDP broadcasts discovery depends on. After an update, check the network profile of the camera NIC first. Why ping succeeds while discovery fails is covered in GenICam discovery uses subnet broadcast: why ping is not enough.
If the error text names a missing entry point or a stale DLL rather than a missing camera, that is an installation fault, not a matching fault — see vision software missing entry point: find the stale DLL.
How do I keep the failure from returning?
Pin the addressing, isolate the cameras on their own NIC and subnet, record the addresses, and add the software's install and data folders to antivirus exclusions once the load succeeds — those four habits remove every cause this guide covers.
- Static, persistent camera addresses on a private /24 per station, written into the camera, not the lease table.
- A dedicated NIC per camera group, so office DHCP, VLAN changes and firewall profiles never touch the vision subnet.
- The station sheet: host NIC address, camera addresses and serial numbers on one page, so a registry rebuild or a camera swap takes minutes.
- Antivirus exclusions for the vision software's install and data folders, applied through the antivirus console.
- A load check at shift start: start the application before the first part arrives, when a two-minute fix still costs nothing.
More connection faults live on the systems learn topic. Putting a new station together is the cheapest moment to apply all five habits: choose the camera in the area scan cameras range, plan addressing in the camera finder, and complete the chain in the configurator below. If an installation still misbehaves after these checks, the contact page is the fastest route to help.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Why can I ping the camera but the GenICam driver still cannot find it?
Ping is a unicast test between two known addresses. GigE Vision discovery instead sends UDP broadcasts on port 3956, so a firewall rule, a VLAN boundary or a network profile switched to Public after an update can pass ping and still block discovery. Keep the camera and the NIC in the same subnet and allow UDP 3956 locally.
Can I keep the camera on DHCP and simply reserve its address?
A DHCP reservation works only while the office DHCP server answers before the vision software starts, and it keeps the camera on a network whose scope, firewall and uptime you do not control. For a production station, write a static persistent IP on a dedicated NIC and subnet instead; keep reservations for office devices.
How many cameras can one static-subnet network card handle?
Addressing allows far more than bandwidth does. A /24 subnet offers 254 usable host addresses, so ten cameras fit easily. Bandwidth decides: one 2.5 MP camera at 30 fps in 8-bit mono moves 2,500,000 × 30 × 1 = 75 MB/s, about 600 Mbps of a 1 Gbps link, so roughly one such camera per port; put heavier loads on separate NICs.
How do I rescue a camera that already sits on a lost 169.254.x.x address?
Set a temporary address on the camera from the configuration tool — GigE Vision tools include a force-IP action for exactly this — then write the static address into the camera's persistent IP settings so it survives power cycles. Without the persistent write, the camera falls back to link-local again at the next boot.