Respondus LockDown Browser & Monitor: Fixing Every Common Error

Respondus LockDown Browser is a custom browser that replaces your normal one during a quiz: it disables copy-paste, blocks other applications, prevents screen capture and locks the test window until submission. Respondus Monitor adds webcam and audio recording plus automated flagging on top of it. Together they are the most widely deployed proctoring stack in U.S. higher education, and also the most rigid — LockDown Browser is deliberately intolerant of anything running alongside it.

"Another application is blocking LockDown Browser"

This message names the offending program, but often only the first one it found. The fix is a full clean start.

1. Restart the computer — this alone resolves most instances.

2. Before launching, quit: Zoom, Teams, Slack, Discord, OneDrive/Dropbox/Google Drive sync clients, screen recorders, remote-desktop tools (TeamViewer, AnyDesk, Chrome Remote Desktop), virtual camera software and second-monitor utilities.

3. On Windows, open Task Manager and end background instances that survive closing the window.

4. Disconnect second monitors. Many institutions configure LockDown Browser to refuse multi-display setups outright.

It installs but will not launch, or crashes instantly

Reinstall from the *institution-specific* download link found inside your course — the generic Respondus site build is not licensed to your school and can fail to authenticate. Uninstall the old version first, reboot, then install. On macOS, drag the app to Applications rather than running it from the disk image, and approve it under Privacy & Security if Gatekeeper blocks it.

Webcam and microphone checks fail in Monitor

Monitor runs a startup sequence: webcam check, audio check, photo, ID capture, environment scan.

If the camera shows black: another app owns the device (see above), or system-level privacy permissions are off. On macOS, LockDown Browser needs Camera, Microphone *and* Screen Recording in System Settings → Privacy & Security. Grant them, then relaunch. On Windows, allow camera and microphone access for desktop apps.

If audio fails: speak at a normal volume during the check, use the built-in microphone rather than Bluetooth, and confirm the correct input device in the dropdown.

If the ID capture keeps failing: hold the card steady until the image sharpens, avoid glare, and make sure the whole card is inside the frame.

The exam submits but the recording will not upload

Monitor uploads video after submission. Do not close the laptop lid, sleep the machine or switch off Wi-Fi while the progress bar is running. If it stalls, keep the browser open and stay connected — the upload resumes. An abandoned upload is why instructors sometimes see a submitted quiz with no video, which can trigger a review even though the student did nothing wrong.

iPad, Chromebook and phone support

LockDown Browser supports iPad only when the instructor enables it, and phones are not supported at all. The Chromebook version requires an institutional deployment. If your only device is unsupported, arrange an alternative *before* the testing window — instructors can rarely change quiz settings after it opens.

Reducing false flags in Monitor

Monitor's review video is timestamped and instructors typically skim flagged segments. Keep your face centered and lit from the front, avoid leaving the frame, silence phone notifications, tell housemates the room is off-limits, and keep permitted materials visible on the desk so a proctor reviewing later can see they were authorized.

The universal pre-exam checklist

Roughly nine out of ten proctoring incidents trace back to the same five conditions. Run this list the day before, not fifteen minutes before.

• Use the same machine, browser and network you will test on. A system check passed on a laptop at home does not certify the desktop at work.
• Reboot fully. A cold restart releases the camera handle that Zoom, Teams, Discord, OBS, Snap Camera or Windows Camera quietly kept open.
• Update the browser and the secure application. Version mismatch is the single most common launch failure.
• Test upload, not download. Live proctoring streams video *out*. You need a stable 1.5–3 Mbps upload; a 500 Mbps download does not help if upload collapses.
• Disable VPNs, proxies, corporate firewalls, parental filters and antivirus web shields. Managed work or school devices block the ports proctoring platforms use, and administrators cannot always unblock them in time.

Fast diagnostic sequence when something breaks

1. Note the exact error code or message and screenshot it — support resolves coded errors in minutes and vague descriptions in hours.

2. Check whether the failure is *device*, *network* or *account*. Device: the check fails offline too. Network: it fails only on this connection. Account: it fails on every device.

3. Switch one variable at a time: hotspot instead of Wi-Fi, Chrome instead of Edge, second machine, guest OS profile.

4. Re-run the vendor system check and save the report ID.

5. Contact live support *before* the appointment window closes — most vendors will not reinstate a session once you have exceeded the launch grace period.

What to do if the session is lost anyway

If the exam terminates, do three things immediately, in this order: screenshot the error, open the vendor's live chat and get an incident or case number, and email your institution or licensing board the same day with that number attached. Reinstatement decisions almost always hinge on documented, timestamped evidence created during or immediately after the incident — not on a request filed a week later.

Then use the retake window deliberately. Rehearse the launch flow on the exact machine, run one full-length timed practice test under the same conditions, and treat the technical setup as part of your study plan rather than an afterthought.