Camera in Device Manager but not in your SDK: the missing plugin

Windows Device Manager lists the camera, the cable is new, and the SDK device list still comes back empty. That combination is rarely a broken camera: the PC has finished enumerating the USB device, and what is missing is the software layer between the operating system and your acquisition software. This guide gives the likely causes in order of probability, a test for each, the two worked checks that settle most cases — USB bandwidth and producer version matching — and the decision for each symptom at the end. Most benches close this in under ten minutes once they know which layer failed.

What a clean Device Manager entry proves

A device that appears in Device Manager has completed USB enumeration: the host controller assigned it an address and read its descriptors. When the entry shows the camera model name, the maker's driver loaded as well. When it shows a generic bridge or controller name, only the operating system USB class driver is in place — the camera-specific part never installed. Either way, the port, cable and camera electronics are alive.

That is why the usual first moves — re-plugging, another cable, another port, a reboot — almost never fix an empty SDK list. The missing component sits above the USB stack: the producer, also called a plugin, that your SDK loads so it can speak that camera family's control protocol. The full layer map, from USB driver up to producer, is in Vision software can't find your camera: the missing driver layer.

One producer speaks one camera family. Software from a different maker does not help, and a camera that needs its own plugin — event-based sensors are the usual case — stays invisible no matter how many generic runtimes you add.

The likely causes, most probable first

1. The producer is not installed. You installed the SDK or a viewer but not the camera maker's runtime that carries the producer. This cause fills most tickets.
2. Version mismatch. The producer is on the PC but was built for another SDK generation, so the SDK skips it or loads it and errors. See GenTL producer version compatibility: missing function errors.
3. Registration missing. The producer is installed but absent from the SDK's producer search path, so enumeration never consults it.
4. Exclusive hold. A viewer or a second SDK already holds the camera; USB3 Vision serves one control client at a time.
5. Driver lost after a Windows update. A feature update can drop the camera driver, leaving a warning icon or a fallback to a generic name — standard Windows behavior after major updates.
6. The hardware after all. Wrong port speed, a marginal cable or insufficient power. Rare once Device Manager shows a clean entry, but never zero.

Five-minute tests, in this order

1. Read the entry name. Under the cameras class or Universal Serial Bus controllers: the model name means the maker's driver loaded; a generic bridge name means only the OS layer is present.
2. Check for warning icons. Open the entry's properties and read the device status box. A problem code there is a driver-level fault: reinstall the camera maker's driver package before touching plugins. The Device Manager repair steps in Frame grabber driver manual installation: Device Manager fix apply to any device entry.
3. List the producers your SDK sees. Most SDKs and GenICam browser tools report the producer modules they loaded. An empty list, or no entry for your camera maker, confirms cause 1 or 3.
4. Compare the versions. Note the SDK package version and the producer package version, then apply the matching rule in the worked example below.
5. Close everything else and rescan. Shut every viewer and test panel that might hold the camera, then refresh the SDK's device list.
6. Check the negotiated USB speed. The USB view in Device Manager shows the link speed the port negotiated. A camera at high speed sits on a USB 2 link, where enumeration can succeed while streaming cannot.
7. Swap the cable last. Only after every layer above checks out: Camera has power but not detected: USB link checks after a cable swap takes over from there.

Two worked checks with the arithmetic shown

Bandwidth: why the camera enumerates but never streams

The LS-CMR-0166 streams 4000 × 3000 frames at 30 fps. Take 8 bits per pixel — mono 8, the working format for most inspections — and the payload is:

A USB 2 link runs at a nominal 480 Mbps (real throughput is lower still), about 6× short: 2.88 ÷ 0.48 = 6.0. Frames never arrive even though enumeration succeeds. On a USB 3 SuperSpeed link, 5 Gbps nominal, the same stream fits with roughly 1.7× headroom: 5 ÷ 2.88 ≈ 1.74. Decision: if the camera enumerates but the stream never starts, read the negotiated port speed before reinstalling anything. The numbers come from a current 12 MP USB3 camera in this range:

Version matching: one rule, three cases

Say your SDK installer package is version 4.5 and the camera maker publishes one producer package per SDK line. The rule: match the major version first, the minor version second.

• 4.5 producer with a 4.5 SDK — the supported pair. Install, rescan, done.
• Only a 4.2 producer exists for your camera — the maker's release notes decide. If they state support under 4.5, install it; if not, put the SDK back on the producer's line instead of mixing.
• A producer built for a different maker's SDK — never mixes. Every producer targets one SDK family, so the fix is always the package your camera maker publishes.

The same release discipline applies to the USB driver package: pull driver and producer from the same release when the maker ships them together, because an older driver can enumerate the camera while confusing the current producer.

Where the producer lives and how the SDK finds it

On Windows, a GenTL producer is a library file your SDK discovers through a documented search path: an environment variable listing producer folders, plus registrations its installer wrote. Two failures hide here. The file exists but no path entry points to it, so enumeration never reads it — GenTL producer not listed: check Windows DLL paths walks that diagnosis. Or the file loads but exports functions your SDK generation does not expect, which surfaces as missing-function errors — the compatibility article above covers that path.

The pattern is not unique to machine vision: automation software in general hides a device from its list when the module behind it is not registered, as in this guide to resolving a missing Ignition SDK module from the device list.

GigE Vision cameras behave differently: they need no USB driver, so Device Manager often shows nothing at all and the whole failure hides inside the SDK. The producer layer works the same, with one extra dependency — a network interface the camera maker supports. If the producer is installed and the camera still is not listed, check that camera and network card share a subnet before reinstalling anything.

When it is the hardware after all

If every software layer checks out and the list is still empty, work the physical suspects in this order:

• Negotiated speed. A USB3 camera on a USB 2 port, or through a USB 2 hub, enumerates at high speed and cannot stream. Move it to a root-controller port — on a desktop PC, the rear panel — and re-check.
• Cable. Passive USB 3 copper cables past about 3 m are a common source of flaky enumeration. Test with the short cable the camera shipped with.
• Power. A bus-powered camera on an unpowered hub can enumerate and still fail under load. Give it its own port or external power.
• Exclusive hold, again. It looks exactly like hardware: close every other viewer and rescan before swapping parts.

Linux benches have the same layer map under different names: USB camera in lsusb but not detected by the vision SDK on Linux covers the enumeration side and Camera SDK cannot find device: isolate Linux access errors the permission side.

Stop it on the next install

Three habits prevent most repeat tickets:

1. Install software before hardware. Put the SDK and the camera maker's runtime, from the same release line, on the PC before the camera is ever plugged in, so first enumeration finds every layer ready.
2. Record the version pair per station. One text file listing the SDK version and producer version per PC turns a two-hour mystery into a two-minute comparison.
3. Leave the driver stack alone. Skip generic driver-updater tools for the camera class, and re-check the camera entry after each Windows feature update — an entry that worked yesterday can show a warning icon the day after an update.

Do these three and the plugin conversation stays a ten-minute fix instead of a day of cable swaps.

The decision, case by case

• Model name in Device Manager, SDK list empty — causes 1 to 3. Install the producer matching your SDK version, check the search path, rescan. Ten minutes.
• Generic bridge name in Device Manager — the camera maker's USB driver package is missing. Install it from the same release as the producer, then rescan.
• Warning icon — driver-level repair first: status code, maker's driver package, another port. Plugins come after the entry is clean.
• Camera listed, stream never starts — bandwidth: negotiated USB speed first, then a root-controller port, then the cable.
• Nothing enumerates anywhere — physical: the cable-swap procedure, then power.
• One SDK sees it, another does not — the second SDK's producer search path, or the first program still holding the camera.

If the station itself is new, shorten the software stack as deliberately as you pick the optics: cameras from one maker family share one runtime. Browse the area scan cameras or use the camera finder. Two current models that start this stack on either interface:

For a bundled PC side, vision controllers pair camera ports and processing in one box; the MV-VC3301H-128G66 ships with 8 GB of memory, an Intel Core i3, 5+ LAN ports and a VM6200Pro license included.

Still invisible after all of this? Send the Device Manager entry name, the SDK version and the producer version through the contact page and we will pin the layer with you. The rest of the enumeration and driver-layer fixes sit on the systems topic page.