Fix STATUS_LOCK_NOT_GRANTED 0xC0000055 – Windows File Lock Error

1. Stale Lock Handle from a Crashed Program (Most Common Cause)

This is the culprit nine times out of ten. A program — often a text editor, PDF viewer, or database tool — crashed while holding a lock on the file. Windows doesn't always release that lock cleanly. You try to open the same file again, and bam: 0xC0000055.

Here's how to find and kill the offending handle:

Download Handle from Microsoft Sysinternals (no install needed).
Open a command prompt as Administrator.
Run this to find the lock:
```
handle.exe -a -u "C:\path\to\your\file.txt"
```
Replace the path with your actual file.
Look for output like:
```
pid: 1234 type: File 2C4: \Path\To\File.txt
```
The pid is the process ID holding the lock.
Kill that process:
```
taskkill /PID 1234 /F
```

If Handle doesn't find anything, try Process Explorer (also from Sysinternals). Open it, hit Ctrl+F, type the filename. It'll show you every handle. Right-click and close the handle — or kill the whole process.

Don't bother rebooting unless you're desperate. Killing the handle is faster and won't disturb other work.

2. Antivirus or Security Software Holding the Lock

Your antivirus is paranoid. It scans every file you open, and sometimes it takes an exclusive lock that conflicts with your application. This happens most often with real-time scanning on network shares or mounted ISO files.

Quick test: temporarily disable your antivirus real-time protection. If the error goes away, you've found the issue. Don't leave it off — just confirm the cause.

If it's your AV, here's the permanent fix:

Add the file's folder or drive to your AV's exclusion list.
For Windows Defender, go to Virus & threat protection > Manage settings > Exclusions.
For third-party AV, check their support docs — most have a similar exclusion list.

Skip the whole “repair the AV installation” thing — it rarely helps. Just add the exclusion.

3. Network File Lock (NAS or SMB Share) – OpLock Conflicts

If the file lives on a network drive, the issue is likely opportunistic locking (OpLock). Two computers fight over who gets to lock the file. This error pops up when you try to open a file right after someone else closed it.

You can't fix this from your computer alone — you need to adjust the server-side settings. Here's what to do on the NAS or Windows server hosting the share:

On a Windows server, disable OpLocks for that share:
```
net config server /srv:disableoplocks
```
Run this from an elevated command prompt on the server. You'll need to restart the Server service after.
On a Synology or QNAP NAS, go to Control Panel > File Services > SMB > Advanced Settings and uncheck Enable Opportunistic Locking.

If you can't touch the server, your only workaround is to copy the file locally, edit it, then copy back. Not elegant, but it works.

Quick-Reference Summary Table

Cause	Diagnostic Step	Fix
Stale handle from crashed process	Run `handle.exe` or Process Explorer to find the PID	Kill the process with `taskkill /PID /F`
Antivirus locking the file	Disable real-time protection temporarily	Add file/folder to AV exclusion list
OpLock conflict on network share	Check if another machine accessed the file recently	Disable OpLocks on the server, or copy file locally

That's it. Three causes, three fixes. Start with #1 — it's the most common. If you're on a network share, skip straight to #3. Don't waste time reinstalling Windows or running SFC scans. They won't touch this error.