Fix STATUS_RETRY (0XC000022D) SMB file copy error

This error shows up when Windows can't finish a file operation over the network, usually during a copy or move. The fix is to reset the SMB connection or tweak the timeout.

When you'll see this error

You're copying a big file—say a 2 GB ZIP archive or a database backup—over the network to a shared folder on a Windows Server 2019 or Windows 10 Pro machine. Everything's going fine, then boom: the copy stops with STATUS_RETRY (0XC000022D). Windows says "The request needs to be retried," but retrying just gets you the same error after another minute of waiting. This usually happens on SMB shares (the default Windows file sharing protocol), especially when the network is a little flaky or the server is under load. I had a client last month whose entire print queue died because of this—they were copying a printer driver installer across a slow VPN link and it kept failing.

Root cause in plain English

Under the hood, STATUS_RETRY means the SMB client sent a request to the server, but the server didn't respond in time, or the response got dropped. Windows SMB has a built-in retry mechanism, but sometimes the timeout is too short for large transfers over congested networks. The server might be busy with other tasks (like indexing or antivirus scans), or the network has packet loss that the SMB protocol doesn't handle well. The error code 0XC000022D specifically maps to STATUS_RETRY, which is a kernel-level code that tells the caller "try again later." But Windows Explorer doesn't always handle this gracefully—it just pops up the error and stops.

The fix: Reset the SMB connection

Open PowerShell as admin—right-click Start, choose "Windows PowerShell (Admin)" or "Terminal (Admin)" on newer builds.
Kill the SMB session by running:
```
Get-SmbSession | Where-Object {$_.ClientComputerName -eq ""} | Close-SmbSession -Force
```
Replace <target-server-name> with the actual server name (e.g., FILESERVER01). This forces Windows to drop the connection and renegotiate.
Clear the SMB open files if you want to be thorough:
```
Get-SmbOpenFile | Where-Object {$_.ClientComputerName -eq ""} | Close-SmbOpenFile -Force
```
This releases any file locks that might be stale.
Flush the DNS cache on your client:
```
ipconfig /flushdns
```
Try the copy again. If it fails immediately, move to the tweaks below.

If that doesn't work: Adjust SMB timeout

Sometimes the default SMB timeout (30 seconds) isn't enough. You can extend it via the registry, but only do this if you're sure the network isn't completely broken—otherwise you'll just wait longer for failure.

Open Regedit as admin.

Go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

Create a new DWORD (32-bit) named SessionTimeout if it doesn't exist.
Set its value to 60 (decimal). That's 60 seconds before the session times out.
Restart the Workstation service or reboot.

Another common culprit: Antivirus interference

Had a case where the client's McAfee endpoint security was scanning every file during SMB transfers, causing the server to take too long to respond. If you're using real-time scanning on the server, try temporarily disabling it just for the share path. On Windows Defender, exclude the network share folder from real-time scans:

Add-MpPreference -ExclusionPath "C:\SharedFolder"

What to check if it still fails

Network stability: Run a continuous ping to the server (ping -t <server-ip>) while copying. If you see packet loss or spikes above 5 ms, that's your problem. Check for bad cables, switch ports, or driver updates.
SMB version mismatch: If the server is old (like Windows 7 or Server 2008 R2) and the client uses SMB 3.0, try disabling SMB 3 on the client:
```
Set-SmbClientConfiguration -EnableSmb3 $false
```
Then try again. Re-enable with $true after testing.
File size limit: Some network shares have quota limits or file size restrictions. Copy a small test file (like a 10 KB text file) to rule this out.
Event Viewer logs: Check under Applications and Services Logs > Microsoft > Windows > SMBClient > Operational for detailed error codes. Event ID 30803 often points to a timeout.

If none of that helps, consider using robocopy with the /Z flag (restartable mode) for large file copies—it's more forgiving than Explorer. But honestly, in 90% of cases, resetting the SMB session and bumping the timeout to 60 seconds gets the job done.