A device attached to the system is not functioning: isolate it

Your depth camera has vanished from the SDK viewer with HResult 0x8007001F, 'a device attached to the system is not functioning', while the RGB half of the same unit still opens in any webcam app. Device Manager lists the device with no complaint, and the log carries a 'malformed vid string: hid_device_system_vhf' warning beside the failure. That combination looks like a dead camera, and it usually is one — but a dead camera is a conclusion you prove, not guess. This guide gives the elimination sequence that settles it: flip and reseat the plug, swap the cable against a known-good one, uninstall both device instances, then run the suspect and a healthy twin through every PC on the bench. Nine plug-ins later you hold one decision: rescue, recable, or return.

What does 'a device attached to the system is not functioning' actually mean?

HResult 0x8007001F is Windows reporting a failed transfer to a USB device: the 0x8007 part of the code marks the Win32 facility, the trailing 0x001F is error code 31 in decimal, and code 31 carries exactly this message — 'a device attached to the system is not functioning'.

The number decodes cleanly, and it tells you where the fault sits:

Windows raises code 31 when a transfer to an attached device fails below the driver layer, so it reports a hardware-level failure on the USB bus, not an exception in your own code.

The second clue sits one line below in the log. A depth SDK builds its device list by reading descriptors — the self-introduction strings every USB device serves — and one read came back as a 'malformed vid string: hid_device_system_vhf' warning. VID is the vendor ID carried in those strings; 'malformed' means the camera's HID interface, the depth-control side, answered with data the parser could not use. Descriptors are generated inside the camera, so garbage in a descriptor points at the camera rather than the host. The pairing matrix later in this guide turns that pointer into proof.

Why does the RGB camera still work when the depth camera will not start?

Because the RGB and depth interfaces are separate logical devices behind one USB cable: video-call apps open the RGB side as a standard UVC webcam, while the depth/HID side returns corrupt descriptor data, so power, the cable and the port are already proven good.

A depth camera of this kind is a composite USB device: one cable carries several independent interfaces — an RGB webcam that follows the USB video class, a HID interface for depth control, and the bulk depth stream itself. The host talks to each interface separately. If the RGB side enumerates and streams in a video call, the physical link and its power delivery work, because they serve every interface at once. The working side is a standard USB video device; what UVC plug-and-play really means explains why any app can open it.

Device Manager's clean bill covers the same ground: it judges the interfaces that enumerated, and those are precisely the ones that work. That leaves two suspects — a stale or corrupt device instance recorded in Windows for the depth interface, which software can fix, or the depth interface's own controller and descriptor memory inside the camera, which software cannot. Everything below separates the two.

Which 60-second checks come before any software work?

Flip the camera-end plug over, reseat it firmly, power-cycle and move to a direct host port: a reversed or half-seated plug is a known cause of exactly this signature, with RGB alive and the depth/HID interface missing.

Run them in this order and watch for the depth interface reappearing:

1. Flip and reseat the plug. Unplug the cable at the camera, inspect the connector for bent pins or debris, then reinsert it fully — flip a reversible USB-C plug over, and push a keyed micro-B plug home until it seats.
2. Use a direct host port. Move to a port soldered to the motherboard, with no hub, dock or extension in the path.
3. Power-cycle both ends. Replug the camera and reboot the PC once, so enumeration starts clean.

If the depth side returns, the seat or the port was the whole problem. If the same HRESULT and malformed-string warning come back, the checks below decide between software and hardware. A unit with no life at all is a different case: camera has power but not detected: USB link checks after a cable swap starts one level earlier, and a camera that misbehaves only through an extension is yet another — USB extension cable fails only when you record the depth stream covers that pattern.

How do you prove the cable is innocent in ten minutes?

Borrow the cable from a camera that is known good and run the swap both ways: your camera on its own cable, your camera on the good cable, and the good camera on your cable, on the same port.

Four pairings on one port give the answer:

1. Suspect camera + suspect cable: depth fails. The starting condition.
2. Suspect camera + known-good cable: depth still fails. The cable is exonerated.
3. Good camera + suspect cable: depth works. The cable is exonerated again.
4. Good camera + known-good cable: depth works. The control case.

The fault must land on one side. If every failure follows the camera regardless of which cable is fitted, you are chasing the camera itself, and the matrix in the proof section below settles it. If failures follow the cable, replace the cable and stop; a shielded USB3.0 camera cable with a firm, locked fit, such as the LS-CBL-0219, is the part to change.

Keep the known-good cable as a permanent bench reference and label it, because every future fault isolation will lean on it. The same swap logic works inside a camera housing too — identical USB camera timeout: a swap test isolates the FFC cable applies it to the internal ribbon — and USB camera keeps disconnecting: isolate cable and hardware faults covers the intermittent version of the question. Replacement cables live in the camera cables range; the accessories finder filters them by length and use.

Which device entries should you uninstall before touching drivers?

Open Device Manager, find the camera's two entries — the depth and the RGB interfaces enumerate as separate devices — and uninstall each entry so Windows rebuilds both records from scratch at the next plug-in.

Windows keeps a record of every device instance it has seen, and a corrupt record for one interface of a composite device survives reboots. Clear the records rather than layering a driver reinstall over them:

1. Open Device Manager and find the camera's entries. Expect two: the RGB webcam under cameras or imaging devices, and the depth composite device with its HID child.
2. Right-click the depth entry, choose Uninstall device, and tick the option to delete the driver software for this device if the dialog offers it.
3. Repeat for the RGB entry.
4. Unplug the camera, wait ten seconds, and plug it back into the direct port so Windows re-enumerates and rebuilds both records.

Update the depth SDK to the current vendor release before retesting, and close video-call apps first — a camera held open by another process fails with different errors. Then retest in the SDK viewer. The same 0x8007001F and the same malformed vid string mean the software layer is exhausted; the uninstall-and-rebuild move is the one in USB camera shows a generic UVC name: reinstall the device entry, applied to a different symptom. An error that changes shape — enumerated but refusing to stream — is progress of a kind, and 3D camera ping works but no image: reset apps and check the trigger starts that branch.

When is the camera itself dead, and how do you prove it?

The camera is dead when the fault follows the unit across PCs and cables while a known-good identical camera works on the same PC and port: three PCs, three cameras and nine pairings settle it, and in that matrix every depth failure sits with one camera.

The proof needs one suspect camera, one known-good twin and three PCs — your bench machine plus any two others with the depth SDK installed. Hold the port, the known-good cable and the SDK version identical everywhere, so the camera unit is the only variable:

The arithmetic is the argument. Three cameras times three PCs is nine pairings; depth fails in exactly three of the nine, and every failure includes camera A. The twins pass six of six on the same ports with the same cable, and camera A's RGB side streams in nine of nine pairings. The only variable that predicts failure is the camera unit. One entry closes the record: run the vendor's firmware update tool once on camera A, with the known-good cable on a direct port. On a camera this far gone the tool exits at once with the same malformed-string warning, which means the write never starts — a camera that will not enumerate cleanly cannot accept firmware, so the rescue path is closed as well.

That is the signature of an internal hardware fault in the depth/HID interface: its controller or descriptor memory serves garbage, and no host-side action — driver, SDK, cable, port or registry edit — reaches it. Stop testing and open the return. The habit is worth keeping beyond this case: camera fault isolation for repeatable unit-specific failures turns it into a standing procedure, one 3D camera not detected while others work: isolate it is the same matrix for cameras that vanish entirely, and device descriptor request failed: a USB camera that died electrically is the neighbouring fault where the descriptor stage dies outright.

What do you send with the return so it is approved first time?

Attach the record you produced in the last section: the exact error line, the nine-pairing matrix, the cable swap, the device-instance uninstalls and the single failed firmware attempt — reviewers approve a return that already contains their own diagnostic sequence.

Add the SDK version, the operating system build and the purchase date, and follow the seller's Return Material Authorization (RMA) process from your order page. For cameras bought here, the 3D cameras range carries a 3-year warranty minimum and returns are accepted within 90 days; the order's support contact can pre-check a replacement against your matrix while the paperwork runs.

If you need the depth channel back in the meantime, a projected structured-light camera such as the MV-DPS200P-02 covers close-range inspection, and a ToF sensing camera such as the MV-DT01WMU suits volume and range work.

The full chain — camera, cable, controller and mount — comes together in the camera finder or straight in the configurator:

How do you keep the replacement camera alive for years?

Most of the same tests become habits: burn in every new camera on arrival, fix the cabling once, pin the SDK and firmware versions while the camera still works, and unit-specific faults stay rare enough that the matrix above remains a half-hour exercise, not a weekly one.

• Burn in every camera on arrival. Enumerate it in the SDK viewer and run a capture for ten minutes; a unit destined to fail young usually shows it in the first week, inside the return window.
• Fix the cabling once. One known-good, strain-relieved cable per camera, labelled as the bench reference, removes the most common false suspect from every future fault call.
• Tame power management. USB selective suspend has silently dropped streams on healthy cameras before; depth camera accelerometer stream fails second run: USB autosuspend is that fault met in the wild.
• Update software while the camera is healthy. Firmware and SDK updates go smoothly on a camera that enumerates cleanly; after a fault like this one, that window stays shut.
• Write the matrix into your runbook. The next occurrence should end in nine plug-ins and one decision, not a week of reinstalls.

More fault-isolation walkthroughs sit on the 3D topic page. If this one ends in an RMA for you, the fastest path back to a working depth channel is the replacement configured above.