0X00000315

Fix ERROR_LOST_WRITEBEHIND_DATA_NETWORK_SERVER_ERROR (0x315)

Your PC told a network drive to hold data, then couldn't confirm it saved. This fix targets the real cause: lost SMB connections or cached write conflicts.

Quick answer

Disable write caching on the network drive's properties (Device Manager > Disk Drives > Properties > Policies > 'Quick removal') and increase SMB idle timeout on the server via net config server /autodisconnect:-1.

What's actually happening here

Windows uses a write-behind cache for network drives — it tells your app the file is saved before the data actually hits the server's disk. This speeds things up normally, but when the network connection drops or the server disconnects the session (default SMB idle timeout is 15 minutes), Windows can't flush that cache. The result: error 0x315, often accompanied by a notification that 'data was lost for the file' on your mapped drive. I see this most often with mapped drives to NAS boxes or older Windows Server 2008/2012 boxes where TCP keepalives aren't configured. You're usually opening or saving a file from a network share, the app hangs for 10–20 seconds, then the error pops.

Fix steps

  1. Disable write caching on the client
    Open Device Manager, expand 'Disk drives', right-click the network drive (it shows as a local disk but has a network path), go Properties > Policies. Select 'Quick removal' (disables write caching). This forces all writes to be synchronous, so every save waits for server confirmation. Slower but reliable. You'll lose a bit of write speed, but the error disappears.
  2. Increase SMB idle timeout on the server
    On the server hosting the share, open Command Prompt as admin and run:
    net config server /autodisconnect:-1
    This disables the auto-disconnect feature that drops idle sessions after 15 minutes. If you can't access the server, ask the admin or use group policy: Computer Configuration > Administrative Templates > Network > Lanman Workstation > 'Disconnect idle sessions' — set to 'Never'.
  3. Set TCP keepalive on client
    Open regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Create or set KeepAliveTime (DWORD) to 30000 (30 seconds) and KeepAliveInterval (DWORD) to 1000 (1 second). This forces Windows to detect dead connections faster rather than waiting for the default 2 hours. Reboot.
  4. Enable SMB signing or disable it
    If the server requires SMB signing and the client has it disabled (or vice versa), negotiation failures cause silent disconnects. On client: run gpedit.msc > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > 'Microsoft network client: Digitally sign communications (always)' — set to Enabled. Or if you don't need signing, set it to Disabled on both sides.

Alternative fixes

If the above doesn't help (rare, but possible with flaky Wi-Fi), try these:

  • Remap the drive with persistent flag
    Delete the mapped drive and remap using net use Z: \\server\share /persistent:yes. The /persistent:yes flag makes Windows re-establish the connection automatically on reconnection, reducing orphaned sessions.
  • Increase IRPStackSize
    Registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\IRPStackSize — set to 20 (decimal). This gives more buffer for I/O request packets on busy networks. Default is 15. Reboot.
  • Use IP address instead of hostname
    Sometimes DNS or NetBIOS resolution causes delays that trigger the disconnect. Map the drive using \\192.168.1.100\share instead of the server name.

Prevention tip

The root cause is almost always a dropped session. Configure your NAS or Windows server to never disconnect idle sessions, and on the client, reduce TCP keepalive to 30 seconds. If you're on a Wi-Fi network, set the adapter's power management to 'Maximum Performance' — even a brief power-saving pause can drop the SMB connection. For critical files, use a local copy first, then sync with robocopy. Write-behind caching is fine for local disks, but on a network, it's a gamble you don't need to take.

Related Errors in Network & Connectivity
VPN Client Stuck on 'Connecting' – Fix It Now Wi-Fi Drops When Bluetooth Devices Connect – Fix for Windows 10/11 Network cable unplugged Network cable unplugged error in Windows 10/11 0XC0230017 Fix STATUS_NDIS_INVALID_OID (0XC0230017) on Windows 10/11

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.