STATUS_WAIT_FOR_OPLOCK (0x00000367) Fix – Oplock Blocked

Quick Answer

Run !oplock in WinDbg attached to the target process, or kill the process holding the lock with handle64.exe -a -p from Sysinternals Handle.

What's Actually Happening Here

STATUS_WAIT_FOR_OPLOCK (0x00000367) means your application tried to open or modify a file that another process has an opportunistic lock (oplock) on. Oplocks are a cache-coherency mechanism in Windows—a process can ask the OS: “Tell me before anyone else touches this file, so I can flush my cache first.” If that process hasn't responded yet, your operation sits in a waiting state. You'll see this most often when copying files to a network share (SMB) while an app like a database server or a backup tool is holding an oplock, or on local NTFS volumes when an antivirus scanner is scanning a file you're trying to write to.

The error isn't a crash—it's a stall. The system hasn't locked up; it's just waiting for the lock holder to acknowledge the break request. If the holder never responds (buggy app, dead network connection), you get a timeout that lasts up to 60 seconds by default.

How to Fix It (Step by Step)

Identify which process holds the oplock. Download Handle v5.0 from Sysinternals. Open an admin Command Prompt or PowerShell. Run:
```
handle64.exe -a -p explorer.exe
```
Replace explorer.exe with the PID or process name you suspect. If you don't know, run handle64.exe -a and pipe to findstr /i "oplock". The output lists file handles with lock type—look for Oplock in the “Type” column.
Release the oplock without killing the program. The cleanest way is to close the file handle that holds the oplock. You can't do that from Handle—you need Process Explorer (Sysinternals) or the kernel debugger. In Process Explorer, find the process, open Properties → Threads tab, look for a thread stuck on a wait related to FsRtlOplock. Right-click the thread and select “Suspend” then “Resume” to break it out of the wait. This doesn't always work because the oplock break handler might be in a tight loop. More reliable: kill the process that owns the handle. Save the process's data first if it's a database or editor.
Kill the process holding the oplock. Use taskkill /F /PID <PID>. After the process terminates, Windows breaks the oplock automatically and your waiting operation proceeds. You'll lose unsaved work in that process, but the file will be accessible again.
If the oplock timeout is too long, shorten it. This is a workaround—not a fix—but it prevents the 60-second stall. Add a DWORD registry value:
```
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"OplockBreakWait"=dword:0000000a   (10 seconds)
```
Reboot or restart the Server service. Changes affect all SMB shares on this machine. Don't set below 5 seconds—you might cause spurious break failures.

Alternative Fixes (When the Main One Fails)

Use WinDbg to manually break the oplock. Attach to the process that holds the lock. Run !process 0 0 to list threads, find the one waiting on FsRtlOplock, then .thread /p /r to switch to it. Command !oplock dumps the oplock structure. You can't directly release it from the debugger, but you can .kill the process from the debugger if it's unresponsive.
Disable oplocks entirely on a problematic volume. Not recommended for performance—oplocks reduce network round-trips. But if one database app keeps causing issues, disable them on that share with PowerShell:
```
Set-SmbShare -Name "ShareName" -OplocksEnabled $false
```
This only works for SMB shares. For local NTFS, you'd need to disable oplocks via fsutil which isn't supported on modern Windows 10/11—ignore that old advice.
Update the buggy application. I've seen this with outdated antivirus scanners (especially McAfee and Symantec) that hold oplocks indefinitely. Update or disable real-time scanning for the specific folder. Also check backup software like Veeam or Acronis—they can leave orphaned oplocks after a crash.

Prevention Tips

Set SMB oplock break wait to a reasonable value. As shown in step 4, 10 seconds is enough for legitimate cache flushes but doesn't let a hung app block you for a minute.
Monitor for stuck oplocks. Use handle64.exe -a -nobanner -accepteula 2>&1 | findstr /i "oplock" in a scheduled task. Log the output to Event Log with a custom PowerShell script. If you see the same PID holding an oplock for more than 30 seconds, that's your culprit.
Isolate file-server workloads. Don't run a database server and a backup client on the same machine if both touch the same files. They fight over oplocks.
Upgrade to Windows Server 2022 or Windows 11 22H2 or later. Microsoft added better oplock break handling in SMB 3.1.1—the client now breaks oplocks faster when a timeout is detected, and the server doesn't get stuck waiting on dead clients.

One last thing: If you're running an old NAS or a Linux Samba server, check its oplock configuration. Samba's default oplock behavior can cause STATUS_WAIT_FOR_OPLOCK on Windows clients. Set oplocks = no on the Samba share as a test. If the error stops, you know where the problem lives.