Camera access denied 0x80070005 on Windows: the privacy fix

You connect a machine-vision or depth camera to a Windows 10 or 11 PC, start the vendor's viewer, and the device refuses to open: the log shows acquire_power failed, with MFCreateDeviceSource returning HRESULT 0x80070005, "Access is denied". The same camera streams on a second PC, so suspicion lands on the USB controller — often an add-in card in an older laptop. Resist that first move. 0x80070005 from a device-source call is a permission refusal: Windows blocked the app from the camera before a single frame moved. In the large majority of cases the gate is the camera privacy setting, one desktop-apps toggle in particular, and the fix takes about two minutes. Here is the decision, the residual causes in order of probability, a worked case, and the settings to put on every deployment PC.

What 0x80070005 means at camera open

Viewers built on the Windows media stack open a camera by asking Media Foundation to create a device source; MFCreateDeviceSource is that call. 0x80070005 is the generic Windows access-denied code, returned when a security check blocks the operation — you meet the same HRESULT anywhere permissions get in the way, for instance when a Windows 11 update install fails with 0x80070005. At camera open it means the refusal happened after enumeration, at the moment the app requested the stream source.

That ordering is the whole diagnosis:

• The camera is listed under its host controller in Device Manager, and it works on another PC: enumeration, driver and camera are good.
• The failure is a denial at source creation — not a timeout, a "device not found", or a bandwidth complaint.
• Therefore the block is policy on this PC, and on Windows 10 and 11 the camera privacy page is where that policy lives.

USB controller and ExpressCard faults produce different signatures: the device disappearing from Device Manager, enumeration drops, black frames, or frame rate collapsing once streams start. None of them hands the application an access-denied HRESULT at open. The same logic is why the privacy page, not the USB stack, is the place to start when apps cannot open a USB camera at all.

The fix: three toggles, then a clean restart

1. Open Settings > Privacy > Camera on Windows 10, or Settings > Privacy & security > Camera on Windows 11.
2. Set Camera access (the device-level switch) to On. Every switch below it is inert while this one is off.
3. Set Allow apps to access your camera to On.
4. Set Allow desktop apps to access your camera to On — this is the switch that governs viewers, SDK tools and most machine-vision software.
5. Close the viewer completely and start it again. An application that already received the denial can keep the failed source cached, so a retry inside the same process is not a clean test.

The retest is simple: after the restart the viewer should list the camera's stream profiles and start streaming within seconds. If the device now opens but the picture stays blank, move one layer out with restoring a blocked camera preview.

Why the desktop-apps toggle is the one that bites

Most machine-vision viewers, SDK samples and capture services are desktop (Win32) applications, not Microsoft Store apps. The per-app list under "Allow apps to access your camera" only shows Store apps; desktop applications are governed by the single "Allow desktop apps to access your camera" switch. A factory laptop can show every Store app allowed and still deny your SDK.

"Works at the other PC" usually just means that machine was imaged with desktop-app camera access left on, while this one — an OEM image, a company policy, or a privacy tool — shipped with it off. On a PC whose only job is the vision application, turning all three switches on is the intended operating state. On a shared office machine, remember the switch applies to every desktop app, not only your viewer.

If the error stays: causes in order of probability

1. The viewer was never restarted. Test: fully close and relaunch it as a new process. This clears most "I changed the setting and nothing happened" reports.
2. A Group Policy or MDM baseline holds camera access off. Test: the device-level switch is greyed out or reverts after you set it. Fix: your IT administrator must allow camera access, including desktop apps, by policy — no viewer reinstall changes that HRESULT.
3. Endpoint security software with webcam control. Some security products enforce their own camera block on top of Windows. Test: open the product's camera-protection module and look for the viewer executable. Fix: allow that executable.
4. The driver stack after an update. Windows updates can strip or mispair camera drivers, but the symptom then shifts to "no device found" rather than access denied. Reinstall in order — see driver install order for depth cameras on Windows and depth camera drivers missing after a Windows update.
5. It really is USB — with a different symptom. Not detected, black window, or frame rate below the camera's rating: now the ExpressCard, hub or dock is a suspect. Work the hardware side with the USB power budget check, black window from a USB dock or hub and budgeting USB hub bandwidth for camera frame rate. If Windows will not detect the camera at all, start from a USB camera that Windows will not detect.

Worked case: laptop, add-in USB3 card, access denied

A concrete case, with the arithmetic of the decision:

• Setup: Windows 10 laptop, USB3 add-in card whose host controller shows in Device Manager, one depth camera, vendor viewer.
• Evidence 1: the camera sits under that controller in Device Manager — enumeration and driver binding are done.
• Evidence 2: the viewer log reads sensor.cpp:661 - acquire_power failed, with MFCreateDeviceSource returning 0x80070005.
• Evidence 3: the same camera and viewer stream on a desktop PC — camera, cable and firmware are good.

Three facts, one conclusion: found + denied at source creation + works elsewhere = local policy. The privacy page showed camera access off; all three switches went to On and the viewer was restarted as a new process. Elapsed time about three minutes, against a hardware detour that would have left the HRESULT untouched. With permissions clear, the add-in USB3 card carried the camera at full bandwidth — the card was never the problem.

Prevention on deployment PCs

• Put the three camera-access switches on the imaging checklist for every vision PC, next to driver install order.
• On managed fleets, have IT write camera access (including desktop apps) into the Group Policy or MDM baseline before commissioning, not after the first denied-open ticket.
• Recheck the switches after Windows feature updates and policy pushes; monthly patches rarely touch them.
• Expect this gate on any UVC-style USB camera from the area scan cameras and 3D sensors ranges on a fresh Windows install — network cameras opened through their own GenTL producer bypass this pipeline entirely.

Quick checklist before you blame the hardware

• Camera visible in Device Manager under its host controller?
• Error is 0x80070005 at open — not "device not found", not a bandwidth complaint?
• Same camera streams on a second PC?
• All three privacy switches On, including "Allow desktop apps to access your camera"?
• Viewer restarted as a new process after the change?
• Switches not greyed out and not reverting (policy lock)?
• Security software's webcam module checked for the viewer executable?

If every line above is clean and the open still fails, collect the viewer's log line and the state of the privacy page and send both to us on the contact page. Free expert support comes with every order, and a one-line HRESULT plus the switch states usually settles it in a single reply.