0XC000035C: Network session expired on SMB share access

When you'll see this error

You're working on Windows 11 Pro (or Server 2022) with a mapped drive to a network share—say \fileserver\share. Things work fine for hours, then you try to open a file or run a script that touches that share, and boom: STATUS_NETWORK_SESSION_EXPIRED (0XC000035C). The mapped drive still shows in File Explorer, but you can't browse it. Clicking on it might prompt you for credentials again, or it just sits there with a red X.

What's actually happening here is that Windows cached an SMB session token (your Kerberos ticket or NTLM credentials) and that token hit its expiration window. The system tried to re-use the stale session instead of re-authenticating, and the file server shut it down. This is not a network drop—your connection is fine. It's a security expiry that the OS didn't handle gracefully.

Root cause: silent credential cache invalidation

The SMB client in Windows 10/11 uses a credential manager cache to avoid re-prompting you for every operation. That cache has a lifetime—by default, Kerberos tickets last about 10 hours, but domain policy can shorten it to 8 hours or less. When that ticket expires, the SMB redirector doesn't automatically re-up it for idle sessions. The next I/O call triggers the error instead of a silent re-auth.

The exact trigger is often one of these:

• You left a mapped drive open overnight and the Kerberos TGT expired.
• You switched network connections (e.g., from Wi-Fi to VPN) without disconnecting the drive.
• Your IT pushed a GPO that changed Kerberos ticket lifetime mid-session.

Windows does have a built-in reconnection mechanism, but it's lazy. It retries the old session first. When that fails, it attempts a new logon—unless the credential cache is empty or the server refuses the cached creds. In that case, you get 0XC000035C.

Fix it: force a fresh SMB session

The real fix is to tear down the old session and start a new one. Here's the only reliable way I've found across Windows 10 22H2 and 11 23H2.

1. Open Command Prompt as admin. Not PowerShell for this first step—net use behaves differently in PS.
2. List current connections: net use. Look for the drive letter or UNC path that's failing.
3. Delete the session: net use X: /delete (replace X with your drive letter). If it says "The network connection could not be found," the mapping is stale. Run net use * /delete to nuke all.
4. Clear the credential cache: cmdkey /list shows stored credentials. Look for MicrosoftAccount:user@domain or TERMSRV/ entries tied to the file server. Delete them: cmdkey /delete:TargetName.
5. Re-map the drive: net use X: \fileserver\share /persistent:yes. Use /user:DOMAIN\username if you need a specific account.
6. Verify: dir X:\ should work immediately. If not, check event log (see below).

Why deleting the connection before clearing the cache matters

If you clear cmdkey entries first, Windows may still hold the SMB session in the redirector's state table. Deleting with net use /delete forces the redirector to invalidate that session object. Then credential cleanup ensures no stale tickets survive. The reason step 3 works after step 5 is because you've killed both the session and the cached auth artifact.

If it still fails: check these three things

1. Kerberos ticket lifetimes

Open PowerShell as admin and run klist tickets. Look for the file server's SPN (e.g., cifs/fileserver.domain.com). If the ticket shows End Time in the past, that's your smoking gun. To force a new ticket: klist purge then klist get cifs/fileserver.domain.com.

2. SMB signing mismatch

Some file servers require SMB signing all the time, and Windows might negotiate a session without it, then the server drops it mid-session. Check you haven't disabled signing via GPO or registry. On the client, Get-SmbClientConfiguration—RequireSecuritySignature should match the server's policy.

3. Event log clues

Open Event Viewer > Windows Logs > Security. Filter for Event ID 4625 (logon failure). Look at the Sub Status field. Common values:

If you see 0xC000019C alongside 0xC000035C, it's definitely a Kerberos ticket expiry issue. A klist purge and reconnect will fix it every time.

One more thing: avoid the reboot trap

Rebooting clears everything, sure. But it's overkill. The steps above take 30 seconds and don't kill your open apps. If your IT tells you to reboot, ask them to extend the Kerberos ticket lifetime in GPO instead. Default 10 hours is fine for most—unless you're on a VPN that reconnects daily.