A depth camera that shows live video in a normal app while your vision SDK reports "No device detected" is almost never broken hardware. It is a half-installed Windows driver stack: the RGB entry works, the depth and virtual entries never finished installing. The tell-tales are a UserPnp event 20001 with InstallStatus 0x643 in the System log, one camera entry in Device Manager where a working install shows three, and on some machines an enumeration tool that stops with HRESULT 0x800704ec. This guide decodes those numbers, ranks the causes, and walks the sequence that clears the failure: remove the stack, shut down rather than restart, then reconnect and let Windows reinstall.
What the two numbers mean
Open Event Viewer (eventvwr.msc), go to Windows Logs, System, and filter for Event ID 20001 from the UserPnp provider. Each 20001 row is one device-driver install attempt, carrying DriverName, DriverVersion, DeviceInstanceID and InstallStatus plus the UpgradeDevice and RebootOption flags.
0x643 in InstallStatus is decimal 1603, the generic fatal-error-during-installation status: it says the package install aborted, not why. The fields beside it carry the diagnosis. UpgradeDevice true means Windows tried to upgrade an existing install in place, and RebootOption false means it finished without asking for a reboot, the signature of an install replaying over its own wreckage.
0x800704ec is a different animal: HRESULT_FROM_WIN32 of error 1260, access disabled by policy. When it comes out of CoCreateInstance(CLSID_SensorManager, ...) inside your SDK's enumeration, a Group Policy, AppLocker rule or Software Restriction Policy is blocking the Windows sensor manager, and the camera is irrelevant to that failure.
| Code | Where you see it | Decodes to | What it tells you |
|---|---|---|---|
| 0x643 | InstallStatus, UserPnp event 20001 | Win32 1603, fatal error during installation | The driver package install aborted; read UpgradeDevice and RebootOption beside it |
| 0x800704ec | Enumeration tool, CoCreateInstance(CLSID_SensorManager) | Win32 1260, access disabled by policy | A policy blocks the sensor manager; no driver reinstall fixes this |
| 20001 | System log, UserPnp provider | Device install audit record | One row per attempt; repeated identical rows mean the same failed upgrade keeps replaying |
Why video apps stream while the SDK sees nothing
A depth camera is a composite USB device: each stream rides its own interface function, and an instance path ending in MI_02 is the third of them. A complete install puts three entries in Device Manager: depth, RGB, and a virtual driver that stitches the streams into one logical camera. Consumer video apps open only the RGB entry through the standard Windows camera path, so they stream while the stack is half-built. Your SDK enumerates every interface and needs all three; with two missing it reports no device, which is the correct answer to the question it asked.
The same missing-entries pattern after a Windows feature update has its own trigger and is covered in Depth camera RGB and virtual drivers missing after Windows update.
The likely causes, in order of probability
- Stale driver state. The 0x643 install was an in-place upgrade, UpgradeDevice true, over an earlier failed attempt, and Windows keeps replaying it. Test: repeated 20001 rows with the same InstallStatus, and one Device Manager entry where three belong. This is the most common case, and the ordered rebuild below clears it.
- A policy block. Enumeration prints 0x800704ec before it ever reaches the device. Test: run the SDK's device-enumeration tool; the HRESULT and the blocked-by-group-policy text appear in its first lines. Nothing about the driver is wrong.
- A legacy service runtime stacked on a current SDK. Older depth stacks shipped a service-style runtime with its own installer; when both exist, the installs collide. Test: appwiz.cpl lists a depth-camera manager or service package next to your current SDK.
- A weak USB path. Front-panel ports, unpowered hubs and long thin cables drop enumeration mid-install. Test: a rear USB 3 port on the machine itself with a short cable, the same link-quality problem that makes a camera detected as USB 2 drop streams.
The fix: remove the stack in order, then cold-boot
- Close the viewer and every SDK tool. Unplug the camera.
- Run appwiz.cpl and uninstall the vendor's depth-camera service or manager package if one is listed. Leave the current SDK installed.
- Run devmgmt.msc, enable View, Show hidden devices, and uninstall every entry belonging to this camera, depth, RGB and virtual, checking "Delete the driver software for this device" each time.
- Shut the machine down. Do not restart. Removal while the camera is unplugged, plus a full power cycle, converts the next install from another in-place upgrade into a fresh one. Disable fast startup first (Power Options, "Choose what the power buttons do"), or remove AC power for 30 seconds on a desktop so the USB controllers reset.
- Power on, sign in, let the machine reach idle, then plug the camera into a different USB 3 port than before, directly on the machine.
- Watch Device Manager: the entries reappear one by one as Windows Update delivers the driver. Wait until you count three, with no warning icons.
- Open the enumeration tool that failed before. It should now list the camera with its depth, RGB and infrared stream profiles instead of reporting no device.
- If it lists the camera but still prints 0x800704ec, go to the policy section below; if the install fails again with 0x643, note the new event row and take the hardware path.
Confirm the reinstall
Check three things before you trust the station again:
- Three Device Manager entries for the camera, depth, RGB and virtual driver, with no warning triangles.
- The enumeration tool lists the camera and its stream profiles, run once elevated and once as a normal user; both runs must list it.
- A sustained capture, not one frame: at 30 fps for 60 s the log should show 60 x 30 = 1,800 frames with contiguous indices. Gaps in the first minute after install mean the link, not the driver, is still unstable.
If enumeration is clean but frames will not start after a firmware change, the failure has moved past the install into the stream stack; the sequence in Depth stream missing after firmware update: rebuild the driver stack picks it up from there.
When the reinstall still fails
The policy block: 0x800704ec
This is error 1260, the policy block decoded above. Work it in this order. First, run the tool from an elevated prompt under a local administrator account; a restricted or roaming profile produces the same HRESULT. Second, open gpedit.msc and read Computer Configuration and User Configuration, Administrative Templates, for entries blocking app deployment or sensor components. Third, check AppLocker and Software Restriction Policies in secpol.msc for rules covering your SDK folder. Fourth, on a company-managed machine, hand that list to IT, because a device-management agent will push the block back after every change. Driver reinstalls never clear 1260, so stop retrying them.
The hardware path
If fresh installs fail with 0x643 on every attempt: rear USB 3 port, no hub, and a known-good cable. The LS-CBL-0219 is a 3 m USB3.0 camera cable rated for drag-chain use, short enough to keep the link solid on a fixed mount and specified for moving ones. Then test the camera on a second PC: if it installs three entries there, the camera is fine and the first machine's stack or policy is the problem. An entry that appears under a generic camera name instead of the vendor's is a different failure mode, handled in USB camera shows a generic UVC name: reinstall the device entry.
The end-of-life model
When the vendor has stopped serving the driver package for a first-generation coded-light camera on current Windows builds, Windows Update finds nothing and the 0x643 rows never stop. The decision at that point is to move the station to a supported camera rather than fight the update channel. Describe the station's working distance and field of view on the contact page and we will map it to a current sensor. Current 3D sensors run from time-of-flight units such as the MV-DT01WMU to laser galvanometer stereo models such as the MV-DLS300P-04.
- Type
- Depth / ToF camera
- Type
- Stereo / structured light
Prevention
- Install the SDK once, elevated, before the camera's first plug-in, and let Windows Update finish the driver before launching anything.
- Run one stack only: when you move to a current SDK, uninstall the legacy service runtime in appwiz.cpl the same day.
- Give the camera a dedicated rear USB 3 port, no hubs, a strain-relieved cable on moving mounts, and a spare from cables kept with the station.
- After every Windows feature update, open Device Manager and count the three entries before the next production run.
- On managed machines, agree the sensor-manager exemption with IT once, in writing, so a policy refresh cannot blind the cell.
Match the fix to your symptom
| What you see | Cause | Do this |
|---|---|---|
| RGB streams in an app, SDK reports no device, one entry of three present, 0x643 in the log | Half-installed driver stack | Ordered uninstall, shut down rather than restart, reconnect, reinstall |
| Enumeration prints 0x800704ec before reaching the device | Policy block on the sensor manager | Local-admin test, gpedit.msc, secpol.msc, then IT; no driver work |
| 0x643 repeats on every port and cable | USB path or the machine's stack | Rear USB 3 port, known-good cable, second-PC test |
| Reinstall finishes but nothing ever detects the camera | SDK older than the driver stack | Depth camera not detected: check the SDK version before the cable |
Start the default path with step 1 above the moment you see 0x643, and treat the policy check as the first move whenever 0x800704ec appears. When the table points at replacement rather than repair, the camera finder lists the current depth and stereo models by type and interface.
Questions
What does InstallStatus 0x643 mean in a UserPnp 20001 event?
It is hexadecimal 1603, the generic Windows fatal-error-during-installation status: the driver package aborted, and the code alone never says which component died. Read the fields next to it. DriverName and DeviceInstanceID identify the entry that failed, UpgradeDevice true means Windows replayed an upgrade over existing state, and RebootOption false means it never asked for a reboot. That combination is the signature of stale driver state, which the ordered uninstall sequence clears.
Why does the depth camera show video in a normal app but not in the SDK?
A normal video application touches a single interface of the camera, the RGB one, using the standard Windows camera path, so a half-built stack is enough for it. A vision SDK enumerates every interface of the composite USB device, depth, RGB and the virtual driver, and composes one logical camera from all three. When a failed install leaves two entries missing, no device is the correct answer to the question the SDK asked. You can watch the missing entries stay absent in Device Manager while the app streams.
Why shut down instead of restart when reinstalling the driver?
A warm reboot carries the Plug and Play state that produced the failed install forward, and with fast startup enabled the shutdown path can preserve device state too. Uninstall with the camera unplugged, disable fast startup or remove AC power for about 30 seconds on a desktop so the USB controllers reset, then power on and reconnect. Use a different port as well: a new port creates a fresh device instance path, so Windows runs a first install there instead of another in-place upgrade.
How do you clear HRESULT 0x800704ec from a depth camera SDK?
0x800704ec is Win32 error 1260, access disabled by policy: a Group Policy, AppLocker rule or Software Restriction Policy is blocking the sensor manager COM class the SDK calls. Run the enumeration tool elevated from a local administrator account, read Administrative Templates in gpedit.msc and the rule sets in secpol.msc, and on managed machines have IT exempt the SDK folder. Reinstalling the driver never clears this error, so stop retrying installs and fix the policy.
Should the legacy depth camera service stay installed next to a current SDK?
No. Current depth SDKs talk to the driver stack directly, and the older service-style runtime, the DCM-type package you see in Programs and Features, holds device handles and runs its own installer on top of yours. If a failed install of that runtime is your 0x643 source, remove it and keep only the current SDK before rebuilding the stack. Check the version numbers of both in appwiz.cpl so you know exactly what remains.
Which USB port and cable should a depth camera use?
A rear USB 3 port on the machine itself, the shortest cable the mount allows, and no hubs or extension leads in the path. Partial installs that repeat 0x643 are common on front-panel ports and unpowered hubs, and a USB 2 port halves depth throughput even when the install completes. On a moving mount use a drag-chain rated cable and strain-relieve both ends so the connector cannot work loose mid-install.