Why `sudo killall VDCAssistant` Fixes MacBook Camera Black Screen Errors

Every time an app opens your Mac's camera — FaceTime, Photo Booth, a browser tab, Zoom — it doesn't talk to the camera hardware directly. Instead, it requests access through this shared system process, which is responsible for actually initializing the sensor, managing which single app currently "owns" the stream, and cleanly handing that ownership back when the app is done.

This arrangement exists because only one process can realistically own the physical camera hardware at a time on macOS, so having one dedicated system service broker that access consistently is simpler and more reliable than letting every app try to talk to the hardware independently.

The problem arises when this handoff doesn't complete cleanly — most commonly after a sleep/wake cycle, an app crash while the camera was active, or occasionally a rapid succession of apps requesting the camera in quick succession. When that happens, the process can be left believing it still owns an active session that no longer corresponds to any real running app, effectively locking the camera in limbo: not available to new requests, but not actually streaming to anything either.

From the outside, this looks exactly like a generic black screen or "camera in use" error, with no obvious cause, since the app you're currently trying to use did nothing wrong itself — the stale state was left behind by whatever used the camera previously.

Step 1: Open Terminal

Via Spotlight (Cmd + Space, type "Terminal").

Step 2: Run

sudo killall VDCAssistant.

Step 3: Enter your admin password when prompted.

The sudo prefix requires elevated permissions since this is a system-level process, not a regular user app.

Step 4: Reopen whichever app needs the camera.

MacOS relaunches a clean instance of the process automatically — there is nothing to manually restart yourself. ↑ Test now with the widget above.

This command is safe: it only affects the current camera session, not any files, settings, or other running applications.

What is AppleCameraAssistant, and do I need to kill it too?

AppleCameraAssistant runs alongside VDCAssistant as a companion process, and the two are commonly restarted together: sudo killall VDCAssistant AppleCameraAssistant. If restarting VDCAssistant alone doesn’t resolve the issue, AppleCameraAssistant may be the one still holding the camera.

What is UVCAssistant, and is it different from VDCAssistant?

On some macOS versions, Apple introduced UVCAssistant as an additional process specifically for USB Video Class (UVC) compliant external webcams — the standard most third-party USB cameras follow. If you’re using an external webcam rather than the built-in camera, and killing VDCAssistant alone doesn’t resolve a stuck camera, check Activity Monitor (View → All Processes) for UVCAssistant specifically and force-quit it the same way.

Does Apple Silicon (M1/M2/M3/M4) handle the camera differently than Intel Macs did?

Yes — Apple Silicon Macs route camera video through the chip’s own dedicated image signal processor rather than the path Intel Macs used, and the exact background processes involved can differ across specific Apple Silicon generations. If a fix written for an Intel Mac, or for a different chip generation, doesn’t fully apply on your machine, checking Activity Monitor’s actual running process list — rather than assuming a name from an older guide — is the most reliable way to identify what’s genuinely holding your camera.