Fix ERROR_LOCK_VIOLATION (0x00000021) Blue Screen on Windows

I know this blue screen is infuriating. You're in the middle of a backup, a build, or just saving a Word doc, and boom — ERROR_LOCK_VIOLATION, 0x00000021. Reboot, try again, same crash. The message says "the process cannot access the file because another process has locked a portion of the file," but it never tells you which process. That's the part that drives people up the wall.

Here's the truth: 9 times out of 10, this isn't random hardware failure. It's a driver or a background service holding a lock on a memory-mapped file, and something else is trying to yank it away. The kernel notices the conflict and halts. Let's find the actual offender.

Cause 1: A misbehaving third-party driver (usually antivirus or backup software)

This is the number one cause, and I'll be blunt — it's almost always antivirus, endpoint protection, or backup/imaging software. They hook into the file system to scan or snapshot files, and when they hold a lock longer than the kernel allows, you get 0x00000021.

Real trigger I've seen repeatedly: Acronis True Image or a similar image backup kicks off at 2 AM while Windows Defender or a third-party AV (Kaspersky, Bitdefender, Sophos) is mid-scan on the same volume. Both grab locks on the same shadow copy file. Crash.

Fix it

1. Boot into Safe Mode with Networking (hold Shift while clicking Restart, then Troubleshoot → Advanced options → Startup Settings).
2. Open an elevated Command Prompt and run:

verifier /standard /driver * !ntfs.sys !volsnap.sys

That turns on Driver Verifier for everything except the two Windows drivers that legitimately take file locks. Reboot and use the machine normally. When it BSODs again, the crash dump will name the guilty driver.

Now pull the dump file from C:\Windows\Minidump and run it through WinDbg (or BlueScreenView if you want the lazy version). Look for the line that says Probably caused by : xxxx.sys. That's your culprit.

Once you know it, update it. If it's already current, uninstall it and switch to something else — I've watched people waste three weekends chasing a driver bug the vendor hadn't fixed yet.

Cause 2: A stuck file handle from a hung application

Less common, but it happens. A process locks a file, then hangs or crashes without releasing the lock. Windows usually cleans this up, but memory-mapped files can linger. If something crashes during a large file operation — think Visual Studio indexing a solution folder, or a database engine doing a checkpoint — you can end up with an orphaned lock that triggers the bugcheck on the next access.

Fix it

You need to see who's holding the handle. Sysinternals handle.exe is the tool. Download it, then from an elevated prompt:

handle.exe -a -u C:\Path\To\Suspicious\File

The -a flag shows all handle types, and -u shows the user owning each handle. If you see a PID that matches a process you thought was closed, that's your ghost.

Kill it from Task Manager (Details tab, right-click the PID, End task). If it refuses to die, taskkill /F /PID #### usually does the trick.

If the crash keeps recurring on the same file, it's a sign the app itself is buggy. Check the vendor's release notes for "handle leak" or "lock not released" in the changelog. I've seen this exact pattern in older versions of SQL Server Management Studio and some JetBrains IDEs.

Cause 3: A failing drive or corrupted NTFS metadata

I'll be honest — this one is rarer, but you can't rule it out. If the physical disk is returning bad sectors, or the NTFS master file table has gone sideways, the file system can throw a lock violation because it literally can't resolve which process owns what. It's not a software conflict at all; it's the storage layer lying to the kernel.

You'll usually see this paired with other symptoms: slow file copies, random Event ID 55 errors in the System log, or CHKDSK running on every boot.

Fix it

First, check the drive's SMART status. CrystalDiskInfo is free and takes ten seconds:

wmic diskdrive get model,status,size

If any drive reports anything other than OK, back up immediately and replace it. Don't mess around with a dying disk.

If SMART is fine, run an offline NTFS repair:

chkdsk C: /f /r

Schedule it for next reboot (it'll ask). The /r flag scans for bad sectors, which takes hours on large drives. Let it finish. Then run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth for good measure.

One more thing — if you're on an SSD with a cheap SATA controller or a USB enclosure, the firmware can mishandle FUA (Force Unit Access) commands, which leads to lock conflicts under load. Move the drive to a direct SATA or NVMe port and the crashes often vanish.

Quick-reference summary

One last tip that'll save you a headache: if you can reproduce the crash on demand, don't guess. Enable Driver Verifier first, get the dump, and read it. Nine times out of ten the answer is sitting right there in Probably caused by, and you'll save yourself hours of uninstalling perfectly innocent software.