USB camera shows a generic UVC name: reinstall the device entry

You plug a USB camera into a Windows PC and Device Manager lists it as "USB Video Device" or "UVC Device" instead of the model on the label. The camera streams and your software opens it, but every entry carries the same generic string, so anything that picks cameras by name gets lost. This is a Windows enumeration problem, not a camera failure: the name string was not read when the device was first installed, and Windows cached the fallback. The fix is short and needs nothing but Device Manager: uninstall the camera entry, disconnect the camera, reconnect it, and Windows reads the model name from the camera's firmware on the fresh enumeration. This guide gives the fix, the likely causes in order, a worked example with four cameras on one hub, and the cases where this answer does not apply.

What the generic name actually is

When Windows meets a new USB device it reads the device descriptors first, then the string descriptors they point to. The product field in the device descriptor points at a string carrying the model name, and that string lives in the camera's firmware EEPROM. If the read fails or comes back empty, Windows installs the camera anyway on the inbox UVC class driver, usbvideo.sys, and labels the entry with the class name: "USB Video Device" on most Windows 10 and 11 systems, plain "UVC Device" on others. The camera works. Only the label is wrong.

Windows then writes that name into the device's registry entry and reuses it every time the camera reappears on the same port. That is the trap: unplugging and replugging alone reuses the cached entry, so the symptom survives a reboot. Removing the entry itself is what forces Windows to read the descriptors again from scratch.

Any camera the inbox driver claims can show this, and in a vision shop that means compact USB area scan cameras and board-level cameras built into machines. The LS-CMR-0166, a 12 MP USB3 area scan camera, is one example. If you build cameras into your own machines and control what that string says, building a USB UVC camera: sensor and bridge selection covers where the bridge firmware stores it.

The fix: uninstall, disconnect, reconnect

If the camera feeds a running machine, put the cell in a safe state first: a vision system that loses its camera mid-cycle trips a fault, and you want that on your schedule, not the machine's.

1. Close your acquisition software so nothing holds the camera open.
2. Open Device Manager (devmgmt.msc) and turn on View → Show hidden devices, so stale entries appear too.
3. Find the camera under Cameras — on older systems under Imaging devices — and confirm it carries the generic name.
4. Right-click the entry and choose Uninstall device. Leave any "remove driver" checkbox clear: the driver that runs a UVC camera ships inside Windows and is not the problem.
5. Disconnect the camera. With several cameras on one hub, cutting hub power disconnects them all in one action.
6. Reconnect and give Windows a few seconds to reinstall the entry.
7. Check the name under Cameras against the model printed on the camera label.

This fixes the name whenever the camera streams normally but carries the class label. If the entry is still generic, run the same uninstall once more on a different port with a short, known-good cable. If the name is generic on a second PC as well, stop reinstalling: the name string in that camera is blank or unreadable, the failure is in the unit, and it goes back for support.

For cells with many cameras, script the uninstall instead of clicking through them:

Get-PnpDevice -PresentOnly -Class Camera |
  Where-Object FriendlyName -in "USB Video Device","UVC Device" |
  ForEach-Object { pnputil /remove-device $_.InstanceId }

pnputil /remove-device needs Windows 10 version 2004 or later; on older builds do the same job by hand in Device Manager.

Why the name goes missing, in order of probability

1. Interrupted first enumeration. String descriptors travel as USB control transfers, the first traffic to fail on a marginal cable, a worn hub port or a noisy cabinet. Test: repeat the fix on a motherboard port with a short cable. If the name arrives, replace the cable or hub before it costs you an evening.
2. The camera was not ready when Windows scanned. A camera powered from a machine supply can enumerate while its firmware is still initialising, so the string read times out and the class name sticks. Fast Startup then preserves it, because Windows restores the previous session's device state instead of enumerating fresh — which is why an ordinary reboot does not fix it. Test: plug the camera into a second USB port. A new port forces a new entry, and a correct name there clears the camera and convicts the cached entry.
3. A stale cached entry. A camera without a serial number gets its identity from the physical port, so the same port keeps serving the day-old bad name. The uninstall in the fix section deletes exactly this cache.
4. A blank string in firmware. Rare, and indistinguishable from the others on one PC — which is why the second-PC test in the fix section is the closing move.

Worked example: four board cameras on one hub after a Windows update

A labelling cell runs four USB3 board cameras of one model, the LS-BCM-0003. Its data prints 3.1 MP, a 1/1.8" global-shutter sensor and 120 fps. The four sit on a powered hub, and after a Windows feature update the vision software cannot tell its cameras apart: Device Manager lists four identical "USB Video Device" entries.

The rule: each of those entries is a separate device node with its own cached name, so each must be removed once, and one hub power cycle re-enumerates all four together.

Count before:

Get-PnpDevice -PresentOnly -Class Camera | Group-Object FriendlyName

One group comes back: name "USB Video Device", count 4. Four cameras went in, so four entries must come out — the count is the check that no camera fell off the bus during the fix.

Remove all four, then cut hub power for a few seconds and restore it:

Get-PnpDevice -PresentOnly -Class Camera |
  ForEach-Object { pnputil /remove-device $_.InstanceId }

Count after, with the same Group-Object command: one group again, this time named for the camera model, count still 4. The name changed and the population did not, which is the pass condition.

Two follow-ups decide the restart. First, check the four instance IDs against your station map; if a camera changed ports during the fix, reassign it once in software. Second, stop selecting cameras by friendly name — four identical models all carry the same, now correct, model name. Select by instance ID and fix each camera to a labelled port; assign cameras to ports reliably in a multi-camera system works through that mapping.

Decision threshold: if the count after the power cycle is 3, the fourth camera never enumerated — a power or hub problem, not a naming problem, and the hardware path comes first.

When the usual answer is wrong

The second row wastes the most time, because USB3 Vision and UVC cameras look identical from the outside. UVC camera compatibility: what plug-and-play really means separates the two by interface and driver. Software can also miss a camera that Windows filed under a different class node than the one it scans; USB camera configuration file missing: check device class covers that variant.

Checks before you close the ticket

• The Device Manager name equals the model on the camera's label.
• Your acquisition software's device list shows the same name.
• A live capture runs at the format the cell expects.
• In multi-camera cells, every instance ID still matches the station map.
• Exposure, gain and trigger settings reapplied: a reinstalled camera answers with its factory settings until configured.

Prevention

• Select cameras by instance ID, never by friendly name, and keep each camera on a labelled port.
• Power the camera hub from a supply that is on before the PC finishes booting, so no camera is mid-initialisation when Windows scans.
• Turn Fast Startup off on operator PCs, so every boot is a fresh enumeration instead of a restored device state.
• Keep one known-good short USB cable at the cell; most one-off name failures trace to the link.
• On Linux cells the identity problem moves to device paths: multiple USB cameras on Linux: stop device path conflicts handles it with udev rules. When the UVC driver will not bind at all on an industrial Linux box, a UVC camera a Linux kernel does not recognize walks the kernel options.

The fix applies to any USB camera across the area scan cameras and board-level cameras ranges, and the camera finder filters both by interface. A unit whose name stays generic on a second PC is a firmware failure in the camera: send it to our support team instead of reinstalling it a third time.