0X0000099D: NERR_NoSuchSession fix on Windows 10/11

1. Stale SMB Mappings — The Real Culprit

What's actually happening here is that Windows retains a reference to a network session that no longer exists. This happens when you map a drive to a network share, the remote server reboots or the share disappears, and the local machine still holds a session identifier for it. The error 0X0000099D means "NERR_NoSuchSession" — Windows can't find the session it thinks it should have.

You'll see this most often when:

• A mapped drive shows as disconnected but you can't remove it normally.
• You run a batch script that uses net use and it fails with this code.
• You try to access a network share and get the error in Event Viewer under source "MRxSmb" or "LanmanWorkstation".

The fix is straightforward — purge all cached SMB sessions from the command line. Open an administrative Command Prompt (not PowerShell for this — net use behaves differently there) and run:

net use * /delete /y

This deletes all current drive mappings. But that's not always enough. Sometimes Windows holds hidden sessions that net use can't see. In that case, stop and restart the workstation service:

net stop LanmanWorkstation /y
net start LanmanWorkstation

The reason this works is that stopping the workstation service kills all SMB sessions, both visible and invisible. When it restarts, it creates fresh session contexts. After doing this, remap your drives with:

net use Z: \\server\share /persistent:yes

I've seen people spend hours chasing DNS or firewall issues for this error. Don't do that. Nine times out of ten, it's a stale session. Start here.

2. Corrupted SMB Cache or Registry Key

If purging sessions didn't fix it, the problem runs deeper. What's happening is that the session identifier is stored in the registry under HKEY_CURRENT_USER\Network or in a cache file that SMB uses to reconnect persistent drives. These can get corrupted after an unclean shutdown, a network drop during a write, or a disk check that messed up the NTFS permissions.

Here's how to check and fix that.

First, open regedit.exe and navigate to:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Look for subkeys named after UNC paths (like ##ServerName#ShareName). If you see any with weird characters or that you don't recognize, delete them. Make a backup first — right-click the key, export, save it somewhere.

Second, clear the SMB connection cache files. Stop the workstation service (as above), then delete the contents of:

C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Windows\Caches

Don't delete the folder itself — just the files inside it. Restart the service. This forces Windows to rebuild the session cache from scratch.

A note on Windows 11 22H2 and later: Microsoft changed how the SMB cache persists across reboots in that update. The cache files are now in a different location for some builds. If the above path doesn't exist, check C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\Caches instead.

I had this exact issue on a Windows 11 Pro machine after a power outage — the cache had a stale file lock on a session that was never released. Deleting those cache files fixed it instantly.

3. LanmanWorkstation Service Stuck in a Bad State

Less common but worth knowing about — the Workstation service itself can get into a state where it won't release session handles properly. This usually happens when a previous session cleanup was interrupted. The service might show as "Running" but it's actually holding onto orphaned session objects.

To verify, open an admin Command Prompt and run:

sc queryex LanmanWorkstation

Look at the output. If you see STATE with a value like 4 RUNNING but PID is 0, that's a sign the service is in a degraded state. You can also check the Event Viewer log under Applications and Services Logs > Microsoft > Windows > SMBClient for error event IDs 310, 311, or 320 — those indicate session handle leaks.

The brute-force fix that works:

net stop LanmanWorkstation /y
sc queryex LanmanWorkstation

If it's still listed as running after the net stop, kill the process directly. Get the PID from sc queryex output (if it's non-zero), then:

taskkill /f /pid [PID]

Replace [PID] with the actual number. Then start the service again:

net start LanmanWorkstation

Why does this work when net stop alone doesn't? Because net stop sends a control signal asking the service to stop gracefully. If the service is hung waiting on an I/O operation — say, trying to resolve a DNS name for a dead server — it ignores the stop signal. taskkill /f bypasses that and terminates the process immediately.

After this, test your network drive access. If the error is gone, you're set. If not, you might have a deeper issue with the mrxsmb.sys driver or a network adapter problem, but that's outside the scope of this article.

Quick-Reference Summary