Fix 0XC0000054 File Lock Conflict in Windows 10/11

You're not alone—this error pops up when you try to move, delete, or open a file and Windows says "nope, someone else is using it." It's frustrating, but it's usually easy to fix. Let's get straight to it.

The Quick Fix: Find and Close the Locking Process

The direct approach is to see which process has your file locked and kill it. You'll need a free tool from Microsoft called Process Explorer—not the built-in Task Manager, because Task Manager won't show you file handles.

1. Download Process Explorer from the official Sysinternals site: https://learn.microsoft.com/sysinternals/downloads/process-explorer
2. Extract the ZIP to a folder like C:\ProcessExplorer and run procexp.exe as administrator (right-click → Run as administrator).
3. Go to Find → Find Handle or DLL... (or press Ctrl+F).
4. Type in the full path of the locked file (e.g., C:\Users\you\Documents\report.xlsx) and click Search.
5. Wait a few seconds. You'll see a list of processes that have that file open. Each line shows the process name and the handle type (File, Key, etc.).
6. Double-click a result to jump to that process in the main window.
7. Right-click the process and choose Kill Process. Confirm if asked.

After killing the process, try your file operation again. It should work now. If the error comes right back, the same process is probably restarting itself—we'll handle that in the next section.

What if Process Explorer doesn't find anything? Then the file might be locked by a system service or a kernel driver. Continue to the next step.

When the Lock Isn't a User Process: Check SMB and Services

In many real-world cases, especially on network shares, the lock comes from a SMB session or a service like Windows Search Indexer or antivirus. Here's how to handle those.

Close SMB sessions on the server

If you're accessing the file over a network, the lock may be held by another computer. On the server (the machine that hosts the file), open an elevated PowerShell and run:

Get-SmbSession | Close-SmbSession -Force

This forcefully disconnects all active SMB sessions. Users will lose their connections, so do this when nobody's working. Alternatively, you can narrow it down:

Get-SmbOpenFile | Where-Object { $_.Path -like "*report.xlsx" }

That shows which client holds the lock. Then close only that session using the returned ClientComputerName.

Disable Windows Search Indexer temporarily

The indexer has a habit of locking files while scanning. If the error happens on a file inside a folder that's indexed, try this:

1. Press Win + R, type services.msc, press Enter.
2. Scroll to Windows Search. Right-click → Stop.
3. Try your file operation again.

If it works, you'll want to exclude that folder from indexing permanently (right-click the folder → Properties → Advanced → uncheck "Allow this folder to be indexed").

Check antivirus real-time scanning

Some AVs lock files while scanning. Temporarily pause real-time protection (most have a toggle in the tray icon) and see if the error goes away. If it does, add your working folder to the exclusion list.

Why This Error Happens

Windows uses file locks to prevent two programs from writing to the same file at once—otherwise you'd get corrupted data. But sometimes a program crashes without releasing its lock, or a network hiccup leaves a ghost session. The lock stays, and your new request gets STATUS_FILE_LOCK_CONFLICT. It's the system being overly cautious. The tools above force the lock to be released, which is safe as long as the locking process isn't doing critical work.

Less Common Variations

You might see the error in different contexts. Here's how to handle each.

When it's a specific program like SQL Server or Adobe

Databases and design software often lock files for long periods. If Process Explorer shows sqlservr.exe or Acrobat.exe, you can't just kill it—that could damage data. Instead, close the file properly in that program. For SQL Server, use:

ALTER DATABASE [YourDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

That forces other connections off. Then back up and set it back to multi-user.

When you get 0XC0000054 during Windows Update

Rare, but it happens when the update tries to replace a file that's locked by a pending restart. The fix is a clean reboot, then run sfc /scannow in an elevated Command Prompt. If that doesn't help, restart the Windows Update service.

When it happens on an external drive

Often it's a file handle from a crashed explorer.exe. Restart Explorer: right-click the taskbar → Task Manager → Details tab → find explorer.exe → End Task. Then in Task Manager go to File → Run new task → type explorer.exe. That clears the dead handles.

Prevention for the Future

The simplest habit: close programs before you move or delete files. It sounds obvious, but most people skip it. For network files, make sure all users log off properly, not just close the laptop lid. And if you're a developer, use proper file sharing modes when opening files (e.g., FileShare.ReadWrite in .NET) so your own apps don't cause this error.

Also, disable indexing on folders you change often—gives you one less thing to trip over. And keep Process Explorer handy; it's a 10-second fix once you're comfortable with it.

That's it. You should be back to work now. If the error still appears after all this, you might have a hardware issue like a failing disk—run chkdsk /f on the drive to be safe.