Device descriptor request failed: a USB camera that died electrically

You unplugged a USB3 camera that had been running all morning, plugged it back in, and Windows now calls it Unknown USB Device (Device Descriptor Request Failed). On Linux, dmesg logs descriptor read errors and lsusb never lists the camera. You have swapped cables and ports, and the failure still follows the camera. The path below runs the way a bench engineer would run it: what the host is actually reporting, a five-minute exclusion pass, a worked 5 V power budget that shows why a damaged input stage fails in exactly this way, and the decision rule for when to stop debugging and replace the unit under warranty.

What the host is reporting when the descriptor request fails

Attaching a USB camera is a fixed conversation. The port senses the attach, resets the device, then asks for the device descriptor: the 18-byte table that names the camera, its class and its endpoints. Device Descriptor Request Failed is the host's report that this one exchange produced no usable reply - a timeout, a stall, or bytes that failed validation. Everything you normally adjust sits one stage later: drivers, SDK settings, exposure and pixel format are only touched after the descriptor arrives, so reinstalling software cannot reach this failure.

Linux shows the conversation directly. lsusb lists only devices that completed enumeration, so a missing entry is evidence in itself, and dmesg tells you where the exchange died: attach line, reset, then a read error. The numbers carry meaning - -71 is a protocol error, -110 a timeout, -32 a stall - and the dmesg error trail for a camera that disconnects with -71 decodes them line by line. Windows compresses the story into the Device Manager entry: the code describes the descriptor exchange itself, before any driver is involved. If you need the wire-level view, a hardware USB protocol analyzer or the platform's event tracing shows the stalled request on the bus the same way dmesg does on Linux.

The five-minute exclusion pass

Run these before touching the camera housing. Each has a pass/fail outcome, and together they take less time than a driver reinstall.

1. One known-good cable, straight into a motherboard port. Rear-panel port on a desktop, no hub, no front-panel header, no extension. The USB 3.0 specification caps passive cables at 3 m, so a longer run is its own variable - borrow a short one for this test, and see the USB-C cable length and data-rate limits on a USB3 camera. A cable that survived months on the bench is not automatically good: kinked shields and worn latches produce exactly this failure.
2. A second host. Different computer, ideally a different operating system. The camera tells one story; if any host enumerates it, the unit is alive and the investigation moves to the host side, starting with the link checks after a cable swap.
3. lsusb with the camera connected. Absent from the list means it never enumerated. If a twin unit still works, leave it plugged in and diff the two trails - the point where the stories diverge is the fault.
4. Watch the trail while you replug: run sudo dmesg -w (or journalctl -kf) and read. The discipline is the same whatever the bus, as in reading a camera's dmesg error trail. Record the last line before the failure; it is your evidence.
5. The cool-down test. Thirty minutes unplugged, then retry. If the camera comes back and dies again minutes into a full-load run, protection or thermal limiting is the fault - the unit still needs service, but you have learned the failure is load-dependent, not random.
6. Signs of life. A status LED, a warm body, any attach line at all. A completely cold camera with no attach message points at the power path; a warm camera with attach attempts points at the data pair.

Two hosts and two known-good cables that all fail the same way is a camera-side electrical fault. If your cable drawer is full of unlabelled spares, browse the camera data cables shelf - a purpose-built USB3 cable looks like this:

The signature of an electrically dead camera

The story that matches a dead unit is consistent: the camera ran for months, then a long session at maximum resolution and frame rate, then unplug, replug, and dead on every port, cable and host from then on. No settings dialog mentions it, because enumeration happens before any settings exist.

Four things fail this way, in descending order of probability:

1. Tripped or aged input protection on the 5 V rail. A polyfuse or protection IC sits between the connector and the board. A polyfuse resets after a trip, but its resistance climbs with each event and does not fully return, and a hot-plug at full load is exactly the event that trips one. Tell: a storm of protocol errors at attach, or total silence if it opened.
2. ESD damage to the USB transceiver. The silicon behind the connector is the most discharge-sensitive part of the camera, the damage is cumulative, and it is invisible. Dry air, carpeted floors and cables yanked by the lead all contribute. Tell: the device appears briefly, attaches at the wrong speed, or stalls mid-descriptor.
3. A failed onboard regulator or shorted rail. The camera is cold, draws no current, and the port logs no attach at all.
4. Mechanical damage to the receptacle. If flexing the plug changes the trail, the fault moves with the connector, not the silicon.

The physics behind the story is ordinary: a full-load run leaves the input protection at its hottest, and the next plug-in charges the camera's bulk capacitors through that same protection in one surge. Cameras die at plug-in events, not at rest.

Working the case: a 900 mA USB 3.0 camera on a 3 m cable with a tired fuse

This example uses specification values plus one stated fault assumption, and it shows how a camera that streamed perfectly can fail enumeration after its protection degrades.

Inputs:

• 5.00 V - nominal USB 3.0 VBUS at the host port; real ports sit anywhere from 4.75 V to 5.25 V
• 900 mA - the maximum a USB 3.0 port must supply to a configured device, per the USB 3.0 specification; 150 mA is the maximum before configuration
• 4.45 V - the minimum the specification guarantees reaches the device end of the cable
• 0.084 Ω/m - resistance of 24 AWG power wire from standard wire tables; a 3 m cable carries power and return, so 6 m of copper: 6 × 0.084 = 0.50 Ω round trip
• 4 Ω - the assumed resistance of the input polyfuse after a trip and recovery; this is the scenario's degraded value

The rule: the camera's rail equals the port voltage minus the drop across everything in series, and the descriptor exchange only works while that rail stays above the 4.45 V floor.

Healthy cable, undamaged fuse:

• Enumeration load: V_drop = 0.15 A × 0.50 Ω = 0.08 V, so V_camera = 5.00 − 0.08 = 4.93 V - comfortably above the floor.
• Full configured load: V_drop = 0.90 A × 0.50 Ω = 0.45 V, so V_camera = 5.00 − 0.45 = 4.55 V - 0.10 V of margin.

Degraded fuse in series, 4.50 Ω total:

• Enumeration load: V_drop = 0.15 A × 4.50 Ω = 0.68 V, so V_camera = 5.00 − 0.68 = 4.33 V - below the floor before the camera is even configured. The descriptor request dies here, and the host logs a failed descriptor read on every port and every cable.
• Full load: V_drop = 0.90 A × 4.50 Ω = 4.05 V, leaving 0.95 V - the camera would drop out instantly if it ever got that far.

The budget behind the decision:

• Allowed drop: 5.00 − 4.45 = 0.55 V. At the 900 mA load, total series resistance must stay under 0.55 / 0.90 = 0.61 Ω. The cable alone takes 0.50 Ω, leaving about 0.11 Ω for the fuse, both connector pairs and the board traces.
• At the 150 mA enumeration load the budget is 0.55 / 0.15 = 3.67 Ω, so one 4 Ω aged fuse breaks it while the camera sits idle.
• The numbers scale linearly: a 500 mA camera drops 0.25 V on the same cable, leaving 4.75 V and 0.30 V of margin, while the same 4 Ω fuse still drops 2.25 V at that load and leaves 2.75 V - fatal.

Decision: a full-load camera on a 3 m cable carries only about 0.1 Ω of headroom beyond the cable itself. Any protection device left holding ohms fails the descriptor exchange on every host and every cable - the worked-yesterday, dead-everywhere-today signature. The confirming measurement is the 5 V line at the camera connector during the first second after plug-in: about 4.9 V at attach means the rail is healthy and the fault is data-side; 4.3 V or a sag toward it means the power path killed the unit.

One look-alike belongs here: a weak 4.75 V port still enumerates a healthy camera (4.68 V at the 150 mA load) but drops it the moment streaming pulls the full 900 mA (4.30 V at the connector). That failure appears at stream start, not at attach, and it points at the port or hub - see isolating cable and hardware faults when a USB camera keeps disconnecting.

What actually dies inside the camera

You rarely need to know which part failed to make the decision, but the signatures map cleanly:

• Input protection: silent attach when it opens, protocol-error storms when it holds elevated resistance. Measurable from outside as low or sagging 5 V at the connector.
• USB transceiver: brief appearances, wrong-speed attach, stalls mid-descriptor. Provable with a protocol analyzer between camera and host - the request goes out and nothing, or garbage, comes back.
• Onboard rail: a cold camera, no attach line, no current draw.

A protocol analyzer is the definitive instrument, but the two-host, two-cable pattern plus the connector voltage measurement reaches the same conclusion without one.

The decision: declare it dead or keep debugging

Declare the unit electrically dead when all four hold:

1. The same failure appears on at least two hosts.
2. It survives at least two known-good cables, one of them short and direct into a motherboard port.
3. The camera never appears in lsusb on any of them, or Device Manager shows the same unknown device everywhere.
4. The log or trace shows the descriptor exchange itself failing - protocol error, timeout or stall - not a class-driver failure after a successful enumeration.

When all four hold, stop debugging: the fault travels with the camera, and no software reaches it. Cameras we ship carry a 3-year warranty minimum, and in-stock replacements ship within one business day. Send the dmesg trail with the claim.

If any of the four fails, the unit is not proven dead. Work the fault-isolation sequence for repeatable unit-specific failures or return to the exclusion pass with fresh cables; once the real variable is in the test, the failure will move with a host or a cable.

Look-alikes that are not a dead camera

• Enumerates on exactly one host: suspect that host's controller or OS stack before the camera. A camera that dies electrically fails everywhere.
• Returns after cooling, dies again minutes into a full-load run: thermal or protection limiting. The unit still needs service, but the prevention is airflow and duty cycle, not a different model.
• The trail changes when you flex the cable or wiggle the plug: mechanical. Replace the cable first - cables fail far more often than cameras - then look at the receptacle.
• Appears in lsusb but no video device exists: a different stage entirely, after successful enumeration. The USB class check for a camera in lsusb without a video device picks that thread up.

Ordering the replacement and preventing a repeat

A like-for-like USB3 replacement is the usual outcome, and any of these enumerates the way your dead unit did on its first day:

LS-CMR-0166 covers general inspection work: 12 MP at 4000 × 3000 and 30 fps over USB3. MV-CH120-11UC takes the high-speed seat, with 12 MP on a 1.1-inch global-shutter sensor. MV-CS200-10UM is the 20 MP mono option on a 1-inch sensor over USB3.0.

Prevention is mostly feed and handling:

• Feed a full-load camera from a motherboard port. An unpowered hub splits one port's budget across everything downstream, and hubs add their own bandwidth traps - see budgeting the bandwidth before adding a second USB3 camera to a hub.
• Strain-relieve every connector so the cable takes the pull, not the solder joints.
• Ground yourself before handling a bare-board camera; ESD damage accumulates invisibly until enumeration dies.
• Keep passive runs within the 3 m the USB 3.0 cable specification allows. Beyond that, change interface class rather than stacking extensions - the 5GBASE-T camera interface guide covers the same trade at higher rates and longer distance.
• A camera body too hot to hold at full settings is running its protection at the edge; add airflow before summer runs the test for you.

If the decision rule says your unit is dead, send the dmesg trail through the contact page and we will start the warranty path and spec the replacement with you - free expert support comes with every order. If you are building the station from scratch, the area scan cameras category and the camera finder narrow the field fast, and the camera configurator assembles the matched set. More fault trees like this one sit on the systems topic page.