Your program opens the acquisition card and streams frames all day, while the configuration utility insists that no devices and no supporting software are installed. Nothing is wrong with the card. The layer that registers it with the utility is missing, mismatched, or was overwritten by another installer. This guide shows you how to tell those layers apart in Windows Device Manager, how to re-bind the card to the correct driver, why an all-in-one setup makes a working PC worse, and how to repair the utility without uninstalling your whole development stack. Most of these repairs take under half an hour and none of them touches your program.
Why does the card stream in code but not appear in the configuration utility?
Because acquisition and enumeration are two separate stacks: your program calls the runtime, the runtime talks to the kernel driver, and that chain works, while the utility lists only the devices a registered provider component reports to it.
A configuration utility never scans the PCIe bus itself. At start-up it asks a provider service which devices are registered, and it builds its device tree from that answer alone. Your program takes a different road and never asks the provider anything, which is why it keeps streaming while the utility shows an empty tree. The same mechanism explains the uglier symptom, a utility that claims not even the supporting software is installed: there the management layer lost its own registry, which is damage to the software above the driver, not to the driver or the card. It is the same missing-driver-layer pattern behind vision software that cannot find a camera, one level up, at the card instead of the camera.
Which layer is broken: the driver, the provider or the utility?
Open Device Manager before you touch any installer: a card listed under its correct name with no warning icon has a healthy slot, power supply and kernel driver, and the fault sits in the provider and utility above them.
Device Manager reads the bus directly, so it splits the problem cleanly. Read the card's entry against this table:
| Device Manager shows | It proves | The fault sits in | How often |
|---|---|---|---|
| Correct name, no warning icon | Slot, power and kernel driver all work | Provider or utility layer | Most cases when the program still streams |
| Correct name, warning icon | Driver bound but failing to start | Driver initialization | Occasional |
| No card at all | Hardware path or enumeration broken | Slot, power, BIOS, or a second card is the one your program opened | Rare under this symptom |
Work the rows in that order. A card that streams cannot honestly sit in the last row, so if the list looks empty, check whether a second card or an onboard adapter is the device your program actually opened. A warning icon that survives the re-detect cycle below means the driver started and failed, which is the territory of frame grabber initialization failures.
Does the installed driver version still support the card?
Each driver release supports a fixed window of cards, and an upgrade can drop an older board out of that window while the runtime your program was built against keeps working, so check the installed version's release notes before reinstalling anything.
Find the installed version first, in the utility's about box or the installed-programs list. Then open the release notes for that exact version and look for the card in the supported-device list. Every release keeps a window: new boards enter at the top and old boards drop out at the bottom. The position decides the fix. Inside the window: the version is not your problem, and the provider repair below applies. Outside the window: install the last release whose notes list the card, even though it is older, and pin it. Rolling back to regain a listed board is a routine, supported fix, because upgrades serve new hardware first. The same discipline belongs in every upgrade plan; a version jump that strands a card is the frame grabber driver mismatch after a software upgrade pattern.
How do you make Windows re-detect the card with the correct driver?
Uninstall the device in Device Manager, then scan for hardware changes: Windows re-enumerates the slot, finds the card again and binds whatever driver package is installed, repairing a corrupted binding in one pass that takes about a minute.
- Close every program and service that opens the card, so nothing holds the device during the swap.
- In Device Manager, find the card under network adapters or the vendor's capture class.
- Right-click it and choose uninstall device. Leave any delete-driver checkbox unticked unless you deliberately want that version gone.
- Choose scan for hardware changes; Windows re-detects the card and binds the installed driver.
- Reboot once if the utility still lists nothing, because provider services register at start-up.
- Open the utility, confirm the card lists cleanly, and run one test grab before changing anything else.
When Windows binds a generic in-box driver instead of the vendor's, or the binding keeps failing, the full procedure is in the frame grabber driver manual installation guide.
Why does the all-in-one installer overwrite a working driver stack?
A full setup routine is written for clean machines: on a PC that already runs, it detects the provider, support packages and utility already present and replaces the whole stack, including the runtime version your program depends on.
Install components individually instead. Open the driver package rather than accepting its top-level setup, and most installers then offer the pieces one by one: the provider that registers cards with the utility, the runtime your code links, the .NET or COM support package, and the utility itself. Repair in that order and leave every working component alone. The failure mode to avoid is the spiral: the auto-run gains the utility an entry while removing the program's runtime, and suddenly two layers disagree about what is installed — one tool works while another fails, which is the frame grabber SDK support problem in its most confusing form.
Can you fix it without reinstalling the whole development environment?
In almost every case, yes: a program that streams proves the kernel driver and runtime are healthy, so only the provider component and the utility need repair, and the compiler, SDK and your code can stay exactly as installed.
Work a two-step ladder before any clean rebuild. Step one, repair the provider with the component install or the re-detect cycle above; that clears most empty lists. Step two, repair the utility through its own entry in the installed-programs list, which rebuilds the management layer without touching drivers. Only if the utility still crashes on a repaired stack does a full rebuild earn its cost. Uninstalling the compiler, the vision library and every runtime to start clean costs most of a day, lands you on whatever versions the current installers carry, and usually reinstalls a stack that was never broken. Two targeted repairs first; a rebuild last.
Why does the configuration utility crash after another driver package is added?
Two driver stacks on one PC can register services for the same job, and the second installation can leave the utility starting against the wrong one, so remove the package added last and repair the utility before installing anything else.
The classic sequence runs like this: the list is empty, so an unrelated transport or runtime package goes in on spec, and the utility now crashes at launch. The management layer was already damaged, and the new package collided with it; two stacks claiming the same resources is a known source of frame grabber resource conflicts. Undo in reverse order: remove the newest package, repair the utility, re-test, and only then decide what the empty list really needed. A restore point from before the package works when an uninstaller leaves pieces behind. If the utility instead hangs while a card is listed, the fault is on the host side, and the frame grabber host PC configuration guide covers it.
When should you replace the card instead of repairing the software?
Replace the card when its driver no longer runs on the Windows image you must standardize on: if the last release that lists the board predates your OS, every repair holds only until the next update cycle.
Two more signals belong to the same decision: the interface your camera line has moved away from, and a board available only second-hand. Then rebuild deliberately and size the card from the numbers. For a GigE Vision build, the Ethernet line rate caps each port:
Four cameras therefore never exceed 4 × 125 = 500 MB/s worst case and land near 440 MB/s in practice. Any PCIe x4 slot moves about 2 GB/s raw since PCIe 2.0 — 4 lanes × 500 MB/s — more than four times that demand, which is why one quad-port card beats a stack of single-port boards. The frame grabbers category splits cleanly by interface, and each interface has a standard card shape.
For a GigE Vision rebuild, the baseline pair is a 4-port GigE frame grabber and a dual-port PoE NIC:
- Interface
- GigE
- Ports
- 4 ports
- Interface
- GigE
- Ports
- 2 ports
PoE cameras draw power and images through the same port, and the PCIe x4 4-port PoE Gigabit Ethernet card below is built for that:
- Interface
- GigE
Higher bandwidth moves the choice: 10GigE cameras pair with the quad-port copper 10GbE NIC, while CoaXPress cameras need a true frame grabber rather than a NIC — the octo CXP-6 card:
- Interface
- 10GigE
- Ports
- 4 ports
- Interface
- CoaXPress
How do you keep the card visible after the next software upgrade?
Pin the versions: record the driver, provider and utility versions that work, take a restore point before every change, and add one utility check to the acceptance test you run after any software or Windows update.
The list that keeps a repaired PC repaired:
- Before an upgrade: write the driver, provider and utility versions into the maintenance log, and take a restore point or disk image.
- During an upgrade: install component by component — provider, runtime, utility — never the top-level setup over a working stack.
- After an upgrade: open the utility, confirm every card lists, and run one grab per camera. The two-minute test catches a broken provider the day it breaks, not during production.
- With two or more cards: record slot order as well, so device order in a multi-card system stays predictable after any re-detect.
- With cameras feeding heavy processing on the same PC: after any driver reinstall, re-check buffer counts, because a changed driver can reopen the frame-rate gap between acquisition and processing.
One decision per case, then. Card listed in Device Manager but absent from the utility: repair the provider and the list returns. Card outside the driver's support window: install the last version that lists it and pin it. Utility crashing after a new package: remove that package, repair the utility. Driver stranded below your OS: replace the card and size it with the arithmetic above. The accessories finder filters the current cards by interface and port count, the configurator walks the acquisition layer slot by slot, and the systems topic page collects the host-side failure modes around this one.
CoaXPress, Camera Link and GigE cards
58 models · from $189.00Questions
Does uninstalling the configuration utility also remove the driver my program uses?
Usually not: the utility and the kernel driver are separate entries in the installed-programs list, and removing the utility normally leaves the driver your program uses in place. The risk sits in remove-all options that strip shared components with it. Before any uninstall, note the exact driver version that works, and run one test grab afterwards before you change anything else.
Can two cards from different vendors run in the same PC?
Yes, and it is a common build: one vendor's CoaXPress frame grabber beside a standard PoE NIC for GigE Vision cameras is a normal combination. The rule that matters is that each vendor's configuration utility lists only the cards its own provider registers, so an empty list in one utility tells you nothing about the other vendor's card.
What order should I install driver components in on a fresh PC?
Chipset and network drivers first, then the frame grabber runtime, then the provider component, then the configuration utility, then the camera SDK, testing one grab after each step. That order means any failure points at the step just added, and no later installer ever has to repair something an earlier one left half-registered.
Why does the utility list the card but my program still cannot open it?
Then the enumeration layer is fixed and the problem has moved to access: another process still holds the device, or your program links an SDK built against a different driver generation than the one now installed. Close every acquisition process first, then match the SDK version your build references to the installed driver version.