You're on Windows 10 or Server 2019+ and trying to map a drive to a network share. The first attempt fails with ERROR_CLIENT_SERVER_PARAMETERS_INVALID (0X00000255) — but here's the kicker: it usually works after you retry, or it only fails from certain apps. The exact trigger is often after the server reboots, or when you wake the machine from sleep and reconnect to the share.
What's actually happening here is the client and server negotiate a shared memory window to speed up SMB transfers. That window is set up by the mrxsmb.sys driver. If the parameters used to initialize that window don't match what the server expects — say, because the server restarted and the client still holds an old session — the kernel throws 0x255. It's a handshake mismatch, not a permissions problem.
Root cause in plain English
The client allocates a chunk of shared memory and tells the server where it is. The server validates the structure's size, offsets, and flags. If any of those are off — usually because the client's cached session info is stale — the server rejects it with 0x255. The most common reason for staleness is a server that went down and came back with a different SMB configuration, or a client that hibernated and lost the shared memory mapping.
So the real fix is to force the client to drop all existing SMB sessions and rebuild them from scratch. That clears the bad parameters and lets the handshake succeed.
Fix: clear SMB sessions and reset the redirector
Run the following in an elevated PowerShell or Command Prompt. Do them in order — each step builds on the previous one.
- Close all open handles to the share. This includes Explorer windows, mapped drives, and any app that's holding a file open. Use
net useto list and delete mappings:
net use
net use * /delete /y
- Kill the SMB client sessions. This is the part that actually clears the stale shared memory parameters:
Get-SmbSession | Close-SmbSession -Force
If you're on an older build without Close-SmbSession, use net session /delete instead.
- Reset the redirector. This reinitializes the entire SMB client stack, including the shared memory allocation:
net stop mrxsmb10
net stop mrxsmb20
net stop mrxsmb
net start mrxsmb
net start mrxsmb20
net start mrxsmb10
The reason step 3 works is that mrxsmb.sys is the driver that creates the shared memory window. Stopping it forces the kernel to tear down all existing sessions and re-create them on the next access.
- Reconnect to the share. Now map the drive fresh. Don't use
persistentunless you've checked the box to reconnect at logon:
net use Z: \\server\share /persistent:yes
If it still fails
If 0x255 still pops up, you're likely dealing with a corrupted SMB client cache that survives a driver restart. The nuclear option is to clear the SMB client autodisconnect and idle timeout, but that's not the cause here. What actually helps is checking if the server is running SMB 1.0 — yes, it's ancient, but some NAS boxes still enable it. If the server uses SMB 1.0 and the client has it disabled (which is the default on modern Windows), you get this exact error.
To check, run this on the client:
Get-SmbServerConfiguration | Select EnableSMB1Protocol
If it's False and the server only supports SMB 1.0, that's your problem. You'll need to enable SMB 1.0 on the client (I don't recommend it — it's insecure) or force the server to use SMB 2.0+. Alternatively, the server may have a firewall rule that blocks SMB negotiation on certain ports. Check the server's event log for SMB-related warnings at the time of the failure.
Another thing to verify: if you're running antivirus that intercepts SMB (like some endpoint protection suites), it can corrupt the shared memory structure. Disable the SMB scanning feature temporarily to test.
Finally, if this happens across multiple servers, it's not the clients — it's a network issue like a misconfigured MTU or a router that's dropping large SMB packets. Run ping -f -l 1472 <server> to check if the path supports a 1500-byte MTU. If it fails, lower the MTU on the client's NIC or fix the router.
In my experience, 90% of the time the session reset in steps 1-3 fixes it. The rest is usually a server-side SMB version mismatch. Don't waste time on registry tweaks — they don't touch the shared memory handshake.