Skip to content

OBS Studio — Update Fails with "Files in Use" Even Though OBS Is Closed

Symptom

Updating OBS Studio through winget (directly, or via a front end such as UniGetUI) fails within seconds:

Starting package install...
Files modified by the installer are currently in use by a different application. Exit the applications then try again.
Installer failed with exit code: 6
Process return value: "-1978334959" (0x8A150111)
OBS Studio is currently running. Close it and try again

OBS is not running — Task Manager shows no obs64.exe — and retrying as administrator fails the same way.

Why it happens

OBS installs a virtual camera driver (obs-virtualcam-module64.dll). Any Windows program that lists the system's cameras loads every camera module it finds — including OBS's — and keeps it loaded for as long as it runs. Browsers (Chrome, Edge), chat and meeting apps (Discord, Zoom, Teams) and Electron desktop apps (the Claude desktop app, for example) all do this, often without the camera ever being used.

The OBS installer needs to replace that DLL, finds it locked by another process, and aborts. winget then translates the generic "files in use" exit code into the misleading "OBS Studio is currently running" message. Elevation doesn't help: the lock belongs to the other program, not to a permissions problem.

Diagnose

Ask Windows which processes have an OBS module loaded (works from PowerShell, cmd, or WSL):

tasklist.exe /fo csv /nh /m "obs*"

Typical output when the update is blocked:

"claude.exe","95096","obs-virtualcam-module64.dll"

No obs64.exe in the list, but some other program holding obs-virtualcam-module64.dll — that program is the blocker.

Fix

Open OBS Studio and use Help → Check for Updates. In the case this article is based on, two winget attempts failed and the built-in updater then completed cleanly — every file, virtual-camera DLLs included, ended up on the new version — and it installed a newer release (33.0.1) than the winget catalog was offering at the time (33.0.0). Whether it can replace a DLL that another program is actively holding wasn't tested; if it ever reports files in use, close the programs the diagnostic below lists and run it again.

If you manage software with UniGetUI, mark OBS Studio to ignore future updates there so it stops offering an update that will keep failing, and let OBS handle its own.

Alternative: free the DLL, then retry winget

  1. Run the diagnostic above.
  2. Fully quit every program it lists — use Quit/Exit from the system tray icon, not just the window's close button; tray apps keep running and keep the DLL loaded.
  3. Re-run the diagnostic until it prints nothing.
  4. Retry the update.

The lock comes back

The blocking programs reload the new DLL as soon as they start again, so every future winget update of OBS will hit the same wall. That's why the built-in updater is the better long-term route.

Verify

Confirm the program and the virtual-camera modules are all on the new version:

Get-ChildItem "C:\Program Files\obs-studio" -Recurse -Include obs64.exe,obs-virtualcam-module*.dll |
  ForEach-Object { "{0} | {1} | {2:yyyy-MM-dd HH:mm}" -f $_.Name, $_.VersionInfo.ProductVersion, $_.LastWriteTime }

Every line should show the same version and the time of the update.

The virtual-camera files moved in OBS 33

Older releases kept them under data\obs-plugins\win-dshow\. From OBS 33 they live under core\win-dshow\data\. A check that looks only at the old path will report them missing even though the update succeeded — search the whole install folder as above.