Fix STATUS_RANGE_NOT_LOCKED (0XC000007E) — Range Not Locked

This error means one thing

Some program on your machine tried to unlock a range of bytes in a file — but it never locked that range in the first place. Windows saw the mismatch and returned STATUS_RANGE_NOT_LOCKED (0XC000007E). The system is working correctly. The program is not.

The real fix: find and update the broken software

Skip the registry edits, the SFC scans, the DISM repairs. Those won't help here because the source of this error isn't a corrupt system file or a misconfigured kernel setting. It's a bug in an application that mismanages file locks.

Identify the program that triggered the error. Open Event Viewer (eventvwr.msc). Go to Windows Logs > Application. Look for an event with source Application Error or .NET Runtime around the time the error popped up. The event details usually name the executable — something like badapp.exe or plugin_host.exe.
Check which files that program touches. If the event log doesn't name the file, use Process Monitor. Filter by Result containing NOT_LOCKED. You'll see the exact path the program tried to unlock.
Update, reinstall, or remove the offending program. This is almost always a third-party app — not Microsoft software. Common culprits are backup tools, antivirus suites, media players, and VPN clients that do weird things with file handles.

Why step 3 works

What's actually happening here is that a developer wrote code that calls NtUnlockFile (or the higher-level UnlockFile) without having first called NtLockFile on the same byte range. Maybe they forgot to check the return value of the lock call. Maybe they unlocked a range that was already unlocked by another thread. Either way, the fix has to come from the developer. On your end, you can only swap that buggy code for a clean version.

There's no Windows setting that changes how file locking works. NtLockFile and NtUnlockFile are documented kernel APIs. The behavior is hard-coded. If you try to unlock a range that isn't locked, you get exactly this status code. That's not a bug — it's a contract enforcement.

Less common variations

Custom shell extensions or context menu handlers

Some file manager extensions (like TortoiseGit, Dropbox Explorer integration, or 7-Zip context menus) trigger this error when they try to unlock temp files they didn't properly lock. Disable them one by one via shell:AppsFolder or by removing their DLL registration with regsvr32 /u.

Database applications with shared file access

If you see this error from an app like SQLite, Access, or a local CRM tool, the issue is usually a poorly written transaction that tries to unlock rows or pages outside the locked region. The fix is the same: update the database driver or the application itself.

Antivirus real-time scanning hooking file operations

Rare, but I've seen it. Some antivirus drivers intercept lock/unlock calls and get confused when multiple processes contend for the same file. Disable real-time scanning temporarily. If the error stops, switch to a different AV vendor — one that doesn't break basic file system contracts.

Prevention

You can't prevent every developer from writing buggy lock/unlock code. But you can reduce your exposure:

Keep software updated. Developers fix these bugs when they find them. Patch regularly.
Use a limited user account for daily work. Some programs only exhibit this bug when they run with admin privileges and can mess with system-owned files.
Test new software in a VM first. If an app triggers 0XC000007E on a clean install, skip it — that's a red flag for sloppy file handling.

This error is a symptom, not a disease. Treat the app, not the OS.