What's Going On with 0XC00000E3?
You're trying to open or save a file on a network drive—maybe a mapped drive or a shared folder on a NAS—and boom, you get the error STATUS_INVALID_OPLOCK_PROTOCOL (0XC00000E3). I've seen this most often when someone runs a backup app like Veeam or a database server (SQL Server) that uses oplocks aggressively. It's not a hardware failure—it's a communication glitch between your PC and the file server over SMB. The oplock (opportunistic lock) negotiation went sideways.
Let's fix it. Start with the quickest fix, and only move down if the error persists.
Fix 1: Restart the Workstation Service (30 seconds)
This is the laziest fix, but it works more often than you'd think. An SMB oplock session can get corrupted in memory. Killing and restarting the Workstation service clears that out.
- Press Win + R, type
services.msc, hit Enter. - Scroll down to Workstation service. Right-click it and choose Restart.
- If Restart is greyed out, right-click and choose Stop, then Start.
- Try accessing the file again.
If the error's gone, you're done. If not, move to Fix 2.
Fix 2: Disable Unnecessary Oplock Features via Registry (5 minutes)
Sometimes the server or client negotiates oplocks in a way your local Windows build doesn't handle well—especially on older Windows 10 versions (pre-1903) or with certain NAS devices like Synology or QNAP. You can disable oplocks for the specific share or globally. I recommend the global approach if you only use this PC for file access (no SQL or Exchange roles).
Warning: Disabling oplocks can slow down file copying. Only do this if you're hitting the error regularly.
- Open Registry Editor (
regedit.exeas Admin). - Go to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters. - Create a new DWORD (32-bit) named
EnableOplocks. - Set its value to
0. - Restart the Workstation service (see Fix 1) or reboot.
This forces the SMB client to never request oplocks. If you want to be more targeted, you can set the same key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters—but that affects your PC as a server, not a client. For client-side oplock issues, the Workstation key is the one.
Fix 3: Adjust SMB Protocol and Oplock Behavior via PowerShell (15+ minutes)
If you're on a domain or dealing with a finicky NAS, you might need to fine-tune the SMB protocol version or disable specific oplock types. I've seen this fix work when the error occurs with large file transfers (like 4K video files) over SMB 3.0.
- Open PowerShell as Admin.
- Check your current SMB client configuration:
Get-SmbClientConfiguration - Look for
EnableOplocks,EnableLeasing, andEnableLargeMtu. These all affect oplock behavior. - Disable oplocks and leasing (leasing extends oplocks):
Set-SmbClientConfiguration -EnableOplocks $false -EnableLeasing $false -Force - If the error still appears, also try disabling large MTU (which can cause oplock timeouts on slow networks):
Set-SmbClientConfiguration -EnableLargeMtu $false -Force - Reboot to apply all changes.
These commands modify the same registry keys as Fix 2, but with more granularity. If you're on a server OS (Windows Server 2016/2019), you can also increase the OplockBreakWait value via the registry or PowerShell—but that's overkill for most users.
When None of These Work
If the error still shows up after these steps, the problem is likely on the server side. Check if the NAS firmware is outdated—especially on older Synology DSM versions (pre-6.2) or QNAP QTS. Some cheap consumer NAS devices have buggy SMB implementations that don't handle oplock breaks cleanly. Disabling oplocks on the NAS itself (if that option exists) can be a permanent fix.
One last thing: if you're using a VPN or a flaky Wi-Fi connection, oplock breaks can time out. Hardwire your connection or try disabling IPv6 on the adapter. That's rare, but I've seen it once with a Ubiquiti setup.
Good luck—and don't let this error get under your skin. It's just a negotiation breakdown, not a hardware failure.