STATUS_SHARING_VIOLATION 0XC0000043: File locked by another process

30-Second Fix: Kill suspenders, then retry

This error means the file's share access flags don't match what the requesting process asked for. What's actually happening here is that Process A opened the file with FILE_SHARE_READ only (denying write access), and now Process B wants write access — or Process A opened it exclusively (0 share flags), locking everyone out.

Before you dig deep, do this quick check:

1. Close the obvious culprit. If you edited this file in Notepad, Photoshop, or a code editor — close that program entirely. Don't just save, actually exit it.
2. Reboot Explorer. Sometimes Windows Explorer itself holds the lock. Open Task Manager (Ctrl+Shift+Esc), find Windows Explorer, right-click, select Restart.
3. Try again. Still getting 0XC0000043? Move on.

If the file's on a network share, also check if someone else has it open. But for local files, this fix works about 30% of the time. The real lock is usually deeper.

5-Minute Fix: Find and kill the locking process

You need to identify the exact process that's holding the lock. Don't guess — use Microsoft's own tool, Handle (part of Sysinternals). It's the most reliable way to see file locks.

Step 1: Download Handle

Grab it from Microsoft's site. No install needed — it's a single .exe.

Step 2: Find the lock

Open Command Prompt as Administrator. Run:

handle64.exe -a -u "C:\Path\To\Your\File.txt"

Replace the path with your actual file. If you're on 32-bit Windows, use handle.exe instead.

This command does two things: -a shows all handles (including locked ones), -u shows the owning username. The output will look something like:

chrome.exe pid: 1234 type: File  ABC: C:\Path\To\Your\File.txt

The reason this works: Handle scans the kernel object manager for every open handle to that file path. It's not guessing — it's reading the actual NT handle table.

Step 3: Kill the process

Once you have the PID (the number after pid:), run:

taskkill /F /PID 1234

Replace 1234 with the actual PID. /F forces termination — use it only if you know the process is safe to kill. If it's explorer.exe, it'll restart automatically.

Alternative: Process Explorer

If you prefer a GUI, use Process Explorer. Open it, press Ctrl+F, type your file name, hit Enter. It shows you every process with a handle to that file. Right-click the process and select Kill Process or Close Handle (if you only want to release the lock without killing the process).

15+ Minute Fix: Permanent solutions & root causes

If the lock keeps coming back, you've got a recurring problem. Here's how to trace and fix it permanently.

1. Check for systematic lockers

Some programs are notorious for leaving file handles open:

• Windows Search Indexer (SearchIndexer.exe) — can lock files for indexing. Disable indexing on that folder: right-click the folder, Properties → Advanced → uncheck Allow files to have contents indexed.
• Antivirus real-time scanning — some scanners (especially McAfee, Norton) hold files open during scan. Temporarily disable real-time protection and test. If that fixes it, add the folder to your AV's exclusion list.
• Backup software (Veeam, Acronis, Windows Backup) — they snapshot open files. Schedule backups when you're not working on those files.

2. Use Sysinternals Autoruns to find startup lockers

If the lock occurs immediately after boot, some program is starting up and grabbing the file. Download Autoruns from Sysinternals. Look for entries that reference your file's path. Disable anything suspicious.

3. Registry: Disable caching for network files (if applicable)

If the file is on a network share, Windows can cache open file handles longer than expected. This isn't well documented, but you can force behavior by adjusting the redirector cache:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v FileInfoCacheLifetime /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v FileNotFoundCacheLifetime /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v DirectoryCacheLifetime /t REG_DWORD /d 0 /f

Set the values to 0 (disable caching). Reboot. This has a performance cost — it'll hammer the server for every file lookup — so only do it if you're desperate.

4. Check your own code (developers)

If you're writing software that hits this error, you're likely not setting share flags correctly. In C#:

// Bad: locks exclusive
using (var fs = new FileStream(path, FileMode.Open, FileAccess.Read))

// Good: allows others to read & write
using (var fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))

The third parameter in FileStream is share flags — default is FileShare.Read which blocks writes. Pass FileShare.ReadWrite unless you have a reason not to.

5. Last resort: Reboot and check disk

If nothing works and the file is consistently locked even after booting clean (no startup programs), run chkdsk /f C: to rule out filesystem corruption. A corrupted MFT can report phantom locks. Then reboot — chkdsk runs at boot time.

One specific real-world scenario that triggers this: You're editing a large Photoshop file, saving from Lightroom (which writes to it), while Dropbox is syncing. That's three processes fighting over share flags — Dropbox often opens files with FILE_SHARE_READ only, and Lightroom demands write. The fix: pause Dropbox sync while editing, or set Dropbox to use FILE_SHARE_READ | FILE_SHARE_WRITE (you can't — it's Dropbox's decision, so pause it).

That's the full chain. Start at the top, stop when the file opens. You don't need to run through all five steps unless the first ones fail.