Fixing ERROR_LOCK_FAILED (0x000000A7) – Lock Region

When This Error Hits

You'll see ERROR_LOCK_FAILED (0x000000A7) when an application tries to lock a specific byte range in a file, and that range is already locked by another process. Common triggers: SQL Server's transaction log, Exchange database files, or any app writing to a shared log file on a network share. The error pops up randomly during backups, file copies, or after a crash. I've seen it most often on Windows Server 2012R2 and 2016 with third-party backup tools conflicting with VSS writers.

What's Actually Going On

Windows lets multiple processes open the same file, but only one can lock a specific region (byte range). When process A holds a lock on bytes 100-200, and process B tries to lock bytes 150-250, B gets ERROR_LOCK_FAILED. The culprit is almost always a leftover handle from a crashed or slow process. NTFS doesn't automatically clean up orphaned locks — you have to kill the holding process manually. Don't bother with chkdsk or SFC — they rarely fix this.

The Fix – Step by Step

1. Identify the file. Check your app's error log to find which file triggered the lock. If it's not obvious, enable Process Monitor with a filter on Lock operation.
2. Find who's holding the lock. Download Handle from Sysinternals. Run this as admin:
   

   handle.exe -a -p ""

   Or if you know the file name:
   

   handle.exe "C:\path\to\your\file.log"

3. Kill the offending process. The output shows PID and process name. If it's a critical service like SQL Server, restart the service via net stop MSSQLSERVER then net start MSSQLSERVER. For non-critical processes, use taskkill /PID /F. Do this during maintenance windows — forced kills can corrupt data.
4. Check for sticky locks on network shares. If the file sits on a NAS or file server, run openfiles /query /v on the server. Disconnect stale sessions with openfiles /disconnect /id . On the client, clear the offline file cache with net use \\server\share /delete then remap.
5. Reboot if nothing works. A full restart clears all locks. On SQL Server clusters, failover to the other node. This is your last resort — but it works.

Still Failing? Check These

• Antivirus real-time scanning. Some AV products (especially McAfee and Symantec) hold file locks during scans. Add your database/log folders to the exclusion list.
• Backup software. VSS writers can leave orphaned locks. Restart the Volume Shadow Copy service (net stop VSS then net start VSS). Test with a manual snapshot to isolate the issue.
• NTFS permissions. If the app can't even open the file, you'll get ERROR_ACCESS_DENIED, but sometimes combined with lock failures. Ensure the service account has Read and Write – not just Modify. Modify includes delete permissions that can cause conflicts.
• Network share settings. On the server hosting the share, disable Opportunistic Locking via registry: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters, set EnableOplocks to 0. Reboot. This is a blunt instrument – only do it if the problem persists across multiple file types.

Tip: Use Process Explorer (also from Sysinternals) with the lower pane set to 'Handles'. Search for the file path. It shows the exact thread holding the lock, which helps when the process has many threads (like SQL Server).

If you've tried all this and the error still shows up, it's probably a bug in the application itself. Check for updates or hotfixes from the vendor. SQL Server 2014 SP2 had a known issue with lock escalation — SP3 fixed it.