When This Error Shows Up
You're running a Windows Server 2019 or 2022 file server with SMB shares. Suddenly it blue-screens with STOP: 0x0000012D — INVALID_OPLOCK_PROTOCOL. This happens most often when a client (usually Windows 10 21H2 or an older Linux client with Samba 4.13) is holding an oplock on a file, then responds to an oplock break request with a malformed or out-of-order acknowledgment. The server sees garbage and panics.
Common triggers: heavy file locking from database apps (SQL Server, Exchange), backup software (Veeam, Acronis) hammering files, or a client with a flaky network driver that corrupts SMB packets.
Root Cause in Plain English
An oplock (opportunistic lock) lets a client cache file data locally without constantly hitting the server. When another client wants the same file, the server sends an oplock break request telling the first client to flush its cache and release the lock. The client must respond with a clean acknowledgment within a timeout. If that response is garbled — wrong SMB command, bad packet checksum, or the client already closed the file — the server raises the 0x12D bugcheck. It’s a fatal protocol violation.
Three things cause it 90% of the time:
- Buggy network driver — Realtek, Broadcom, or Killer NICs on the client side that mangle SMB packets under load.
- SMB signing mismatch — server requires signing, client doesn’t send it, or vice versa.
- Oplock conflicts — the server’s oplock model clashes with an application’s locking behavior (Exchange, SQL).
Step-by-Step Fix
Skip the blame game. Start with the client side, then the server side.
1. Update the Problem Client’s Network Driver
This is the fastest fix. Find the machine that triggered the crash from the dump file (!analyze -v in WinDbg shows the client IP). On that client, update the NIC driver to the latest from the manufacturer (not Windows Update — go to Realtek/Broadcom/Intel’s site). If you can’t update, try disabling hardware offloads:
- Open Device Manager, find the NIC, right-click Properties.
- Go to Advanced tab.
- Disable Large Send Offload (LSO), TCP Checksum Offload, and Receive Side Scaling (RSS).
- Reboot the client and test the workload again.
2. Force SMB 2.0 or Disable Oplocks on the Server Share
If updating the driver doesn’t help, disable oplocks on the offending share. This kills performance but stops the crash:
Set-SmbShare -Name "ShareName" -Oplocks $falseFor SMB 3.0+, you can also force the protocol version on the server:
Set-SmbServerConfig -ForceSMB1 $false -ForceSMB2 $trueThis is a sledgehammer. Only use it if you’re sure the client can’t handle SMB 3.0 properly.
3. Check SMB Signing Consistency
Signing mismatch can corrupt the oplock response. Run this on the server:
Get-SmbServerConfiguration | Select EnableSecuritySignature, RequireSecuritySignatureIf RequireSecuritySignature is True, make sure all clients either have signing enabled or the server allows unsigned traffic. On stubborn clients, disable signing on the server side temporarily to isolate the issue:
Set-SmbServerConfiguration -RequireSecuritySignature $false— then restart the LanmanServer service.
4. Registry Tweak for Oplock Timeout
If the server crashes because a client takes too long to respond, increase the oplock break timeout. On the server, in HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters, create or set:
OplockBreakWait = dword: 0000003cDefault is 35 seconds (decimal 35). 60 (hex 0x3C) gives more breathing room. Reboot the server after changing this.
What to Check If It Still Fails
If you’ve done all the above and the crash comes back, you’ve got a deeper problem. Grab a network trace from both sides during the crash (netsh trace start capture=yes on the server, Wireshark on the client). Look for SMB packets with STATUS_INVALID_OPLOCK_PROTOCOL (SMB2 error 0x12D). That points straight at the client IP. Also check for third-party filter drivers (antivirus, backup agents) that hook into the SMB stack — Symantec Endpoint Protection and Trend Micro have known issues with oplock handling. Disable the AV’s file scan on the share as a test.
Lastly, make sure both sides have the latest SMB hotfixes from Microsoft. Windows Server 2022 had a known bug in KB5026361 that caused this error on certain file patterns — install the latest cumulative update.