When Zoom Cannot See the Microphone or Camera: Permission, Conflict, and Host Layers

A Zoom session where nobody can hear you, or where the video tile stays dark, almost always fails at one of three separate places: the operating system never handed the device to the process that asked for it, another running program already has the device open, or the meeting itself is withholding the control. Those three failures look identical from the participant's seat and have nothing in common as fixes. Reinstalling Zoom addresses none of them.

The order below is built so that a single two-minute test tells you which of the three layers to work on, before any setting is changed.

The Two-Minute Test That Names the Layer

Zoom publishes a permanent test meeting at zoom.us/test. It is a real meeting with no host, no other participants, and no host-side restrictions, which makes it useful as a control condition: anything that fails there cannot be blamed on the meeting you were trying to join.

Inside the Zoom Workplace desktop app, the same check runs from profile picture > Settings > Audio. Zoom documents a Test speaker button that plays a tone, a Test microphone button that records and plays back, and an Input volume bar that moves when audio is detected. There is also an Automatically adjust microphone volume option in the same tab. When a meeting is launched without automatic audio join, Zoom presents a Test speaker and microphone option before entry.

Two outcomes matter, and they split the problem cleanly.

• The device is not in the dropdown at all. The operating system or another process is the cause. Layers 1 and 2 below.
• The device is listed, the tone plays, the input bar moves, and the meeting still shows no audio or video. The hardware and permission layers are clean. Layer 3 below.

Layer 1: The Operating System Permission Gate

Both Windows and macOS gate camera and microphone access per application, and both grant that access to the process that opens the device. That last point is where most of the confusion sits, because the process is not always the Zoom app.

Windows 11 and Windows 10

Microsoft documents the same path for both versions: Start > Settings > Privacy & security > Camera, and Start > Settings > Privacy & security > Microphone. Each page carries three separate switches, and all three have to be on for a desktop application:

• Camera access (or Microphone access) — the device-wide master switch.
• Let apps access your camera (or your microphone) — governs Microsoft Store apps.
• Let desktop apps access your camera (or your microphone) — governs everything installed outside the Store, which includes the Zoom Workplace desktop app.

The third switch is the one that gets missed, because the first two are on by default on most machines and the page reads as though it is already configured. Microsoft also notes that desktop app permissions are granted collectively — there is no per-desktop-app switch — and that if Camera access cannot be changed at all, an administrator controls it. On a managed work laptop that is the likely explanation, and no amount of local troubleshooting will move it.

Zoom's own documentation for this points at the older Windows 10 wording (Settings > Privacy > Microphones, with "Allow apps to access your microphone"). On Windows 11 the section is renamed Privacy & security and the toggle wording is the shorter form listed above. Zoom lists Windows 10 as its minimum supported Windows version, and states that Windows 10 in S Mode is not supported at all.

macOS

Apple's current path, which applies to macOS Ventura 13 through macOS Tahoe 26, is Apple menu > System Settings > Privacy & Security, then Microphone or Camera. On macOS Monterey 12 and earlier the equivalent is Apple menu > System Preferences > Security & Privacy > Privacy, then select Microphone. If a guide sends you to "System Preferences" on a recent Mac, it is written for the older layout.

Zoom documents which macOS releases each permission applies from: Camera and Microphone from macOS 10.14 onward, and Screen and System Audio Recording from macOS 10.15 onward. Zoom's stated minimum supported macOS for the desktop app is 10.15. Zoom also documents that if the app is already running when the permission is granted, a prompt appears to restart the app before the new setting takes effect — a granted checkbox with a still-dark camera usually means that restart never happened.

The Web App Is a Different Application Entirely

Joining through a browser changes which process needs the permission. Zoom's web app instructions grant camera and microphone access to the browser in the operating system list, not to Zoom. Zoom will not appear in that list at all for a browser join. Zoom then documents a second, separate step: when the meeting starts, the browser prompts for microphone and then camera, and both need Allow.

That double gate produces a specific symptom worth recognising: the desktop app works and the browser join does not, on the same machine, with the same hardware. Zoom supports Chrome, Firefox, Edge and Safari for the web app within the current and past two versions, and documents that starting a screen share from a mobile browser is not supported because of Screen Capture API limits imposed by Google and Apple.

Layer 2: Another Process Already Holds the Device

Zoom names this directly in two places. Its camera-detection article lists "interference from other programs or devices" as a cause and instructs that "all other programs that utilize the camera are not using the camera or are closed" — naming pre-installed camera apps, competing conferencing tools, and websites holding the camera. Its audio troubleshooting article carries the parallel instruction to "ensure that no other applications are using the microphone at the same time."

Windows makes this diagnosable, because the Camera stack returns distinct codes. Microsoft documents the following:

0xA00F4243	Another app or process is using the camera
0xA00F4289	Another app or process is using the camera
0x80070005	Access denied to the camera
0xA00F4244	The system cannot detect the camera
0xA00F4292	Camera access restricted by policy
0xA00F4246	Camera locked by security software
0x800705AA	Insufficient system resources to run the camera

Those codes surface in the Windows Camera app rather than inside Zoom, which makes the Camera app a useful second control test: open it, and whichever code appears tells you whether the block is a conflict, a policy, or a missing device. Microsoft's documented remedy for the conflict codes is to right-click the taskbar > Task Manager, then right-click any app using the camera and select End Task. The same article notes the physical layer that no software step will reach — a sliding shutter on the laptop edge, a dedicated camera key, or a camera toggle on an Fn key combination.

macOS exposes less. Apple documents an orange dot next to Control Center in the menu bar when the microphone is in use and a green dot when the camera is in use. From macOS 13.3 onward, opening Control Center may show a field at the top listing which apps are using the microphone, camera, location, or system audio. That field is the closest macOS equivalent to reading a Windows error code, and it names the process to quit.

Layer 3: The Meeting Is Withholding the Control

If the device tests clean and the meeting still shows nothing, the restriction is inside the session. Zoom documents a specific set of host controls, and each produces a different participant-side symptom.

• Mute All — mutes everyone at once. On its own, participants can still unmute.
• Allow Participants to Unmute Themselves — when the host turns this off after muting all, the unmute control stops working for participants. This is the setting behind "the button does nothing."
• Mute participants upon entry — every new joiner arrives muted, which reads as a broken microphone to anyone who does not check the icon.
• Ask All to Unmute — a request only. Participants keep the choice.
• Stop Video — the host ends a participant's video stream, and the participant cannot restart it.
• Ask to Start Video — an invitation the participant can decline.

The asymmetry matters. Zoom does not give hosts a blanket power to switch a participant's microphone on. The documented mechanism is an account setting called Request permission to unmute participants, found under In Meeting (Advanced) in the meeting settings. When it is enabled, participants see a dialog at join asking whether the host may mute or unmute them. Only after that consent can the host unmute individuals from the participants list, and Zoom notes the consent is remembered for future meetings with the same host and setting. Zoom lists desktop and mobile client version 5.2.1 or higher as the requirement. Participants who declined will find that the host genuinely cannot help.

Webinars are stricter again. Zoom describes attendees as "view-only participants who can be unmuted if the host chooses," and its role tables give attendees no ability to start or stop their own video and no independent audio control — interaction runs through Q&A and chat instead. An attendee looking for a missing camera button in a webinar is looking for a control that the role never had. Promotion to panelist is the only path to video, and that decision sits with the host.

A Test Order That Does Not Waste Steps

1. Check the meeting role first if the device already works elsewhere. A webinar attendee has no audio or video control to fix.
2. Open zoom.us/test. Working there and failing in a specific meeting isolates the problem to Layer 3.
3. Open Settings > Audio and Settings > Video. A missing device in the dropdown is a Layer 1 or Layer 2 fault; a listed device that produces no tone or no input movement points at the wrong device being selected.
4. On Windows, open the Camera app. Read the error code against the table above. It separates conflict from policy from missing hardware in one step.
5. Verify all three Windows switches at Start > Settings > Privacy & security > Camera and the matching Microphone page — including Let desktop apps access your camera.
6. On macOS, check System Settings > Privacy & Security for Camera and Microphone, then quit and reopen Zoom. The restart is documented and is not optional.
7. Close the conflicting process. On Windows, Task Manager and End Task. On macOS 13.3 or later, read the app list at the top of Control Center.
8. If joining in a browser, grant the browser the permission, then accept the in-page prompts. These are two separate gates.
9. Switch device mid-meeting using the up arrow beside the Mute control rather than leaving and rejoining.
10. On Windows, try disabling Signal processing by Windows audio device drivers in Zoom's advanced audio settings if the microphone is detected but the captured audio is unusable.

What the Public Documentation Does Not Settle

Several popular explanations for this failure do not survive a check against primary sources, and it is worth naming them rather than repeating them.

• Zoom does not publish how its client acquires or releases a camera or microphone handle. Explanations built on Zoom's internal codec or device-arbitration behaviour are not verifiable from Zoom's documentation, and are omitted here for that reason.
• There is no published rule about which applications can share a camera. Microsoft documents error codes for the conflict and instructs users to close the other app, but does not publish a general sharing model. Assume nothing beyond the codes.
• No release time is documented. Neither Microsoft nor Zoom publishes how long a device stays held after the owning process closes, so "wait a few seconds" is a habit rather than a specification.
• macOS publishes no camera error-code taxonomy comparable to Windows. Diagnosis on a Mac relies on the privacy indicators and the Control Center app list instead.

When This Doesn't Apply

This three-layer frame assumes the device itself works and the failure is one of access. It stops being the right frame in several situations.

• The hardware has actually failed. If the Windows Camera app returns 0xA00F4244 and Device Manager shows nothing under Cameras or Imaging devices even after Action > Scan for hardware changes, the problem is a driver or a dead device, not a permission.
• The account is managed. Error 0xA00F4292, or a greyed-out Camera access switch, means policy is enforcing the block. Nothing on the local machine overrides it; that is an IT ticket.
• Security software is the gate. Zoom lists antivirus blocking as a documented cause, and Windows reports 0xA00F4246 for a camera locked by security software. The setting to change is in that product, not in Zoom or Windows.
• The platform is below Zoom's minimum. Zoom lists Windows 10 and macOS 10.15 as minimums for the desktop app, and does not support Windows 10 in S Mode. On an older system, permission paths are the wrong thing to audit.
• The browser is out of the support window. Zoom supports the current and past two versions of Chrome, Firefox, Edge and Safari for the web app. An older browser can fail the media handshake regardless of how the permissions are set.
• Audio was never joined. A participant who dismissed the audio join prompt has a working microphone that is not connected to the meeting. Zoom's web portal setting for this is Settings > Meetings & webinars > Join experience, then Automatically connect to computer audio.
• The installation is damaged. If everything above checks out, Zoom's own documented remedy is a clean reinstall using its CleanZoom utility rather than an in-place repair.