Fixing ERROR_NOT_LOGGED_ON (0X000004DD) on Windows
You get this when Windows tries to access a network resource without a valid network logon session. Usually a stale credential cache or offline files corruption.
1. Stale Credential Cache — The Usual Suspect
This error hits hard when you're mapping a drive, accessing a network share, or running a scheduled task that talks to a file server. The culprit here is almost always a credential cache that's holding onto a bad or expired password. Windows caches your network logon — NTLM or Kerberos — and when that cache goes stale, you get ERROR_NOT_LOGGED_ON. I've seen this on Windows 10 21H2 through Server 2022, especially after a password reset.
Fix: Clear Cached Credentials via Credential Manager
- Open Control Panel → Credential Manager → Windows Credentials.
- Look for entries under Windows Credentials that match the target server or share (e.g.,
TERMSRV/ServerNameorMicrosoftAccount:user@domain). - Remove them. Yes, all of them. Don't be shy.
- Reboot. Seriously. A reboot forces the cache to rebuild fresh.
If you're dealing with a remote server via RDP or PowerShell, run this command to kill the cached logon session immediately:
klist purge -li 0x3e7
That purges the kernel-mode session — the one used for network logons. Then try your connection again. I'd say 60% of the time this is all you need.
Why this works: The credential manager stores your logon tokens. When you change your password on the domain controller, the cached token doesn't update until you explicitly log off and back on. Clearing it forces a new authentication round trip.
2. Offline Files Corruption — The Sneaky One
Offline Files is a feature that syncs network shares locally. When it goes sideways, it can corrupt the logon state for the entire network provider. I've seen this on Windows 10 Pro and Enterprise machines connected to file servers via DFS namespaces. The error pops up when you double-click a mapped drive or try to enumerate a share.
Fix: Reset Offline Files Cache
- Open Control Panel → Sync Center → Manage offline files.
- Click Disable offline files.
- Reboot.
- After reboot, go back and enable it again. It rebuilds the cache from scratch.
If you're in a hurry, use the command line:
reg.exe add "HKLM\System\CurrentControlSet\Services\CscService" /v Start /t REG_DWORD /d 4 /f
shutdown /r /t 0
That sets the Offline Files service to disabled, reboots, and effectively nukes the cache. After reboot, set it back to 2 (automatic) and re-enable via Sync Center.
I've also seen cases where the CSC (Client Side Caching) database gets huge — gigabytes. That alone can cause the logon failure. Resetting the cache clears that bloat.
3. Service Account or Scheduled Task Running with Wrong Credentials
If this error shows up in event logs or during a scheduled task that accesses a network path, it's almost always a service account that's lost its network logon rights. The ERROR_NOT_LOGGED_ON code is the OS saying “I can't use this token — it's not attached to a network logon session.” Happens a lot with services running as NT AUTHORITY\LOCAL SERVICE or NETWORK SERVICE when they try to reach a resource that requires a domain account.
Fix: Reconfigure the Service or Task
- Open Services.msc and find the service that's failing.
- Right-click → Properties → Log On tab.
- Change from
Local SystemorNetwork Serviceto a domain user account with proper permissions on the target share. - Enter the password twice. Click OK.
- Restart the service.
For scheduled tasks, open Task Scheduler, find the task, and under General → Security options, select Run whether user is logged on or not and specify the domain account.
Don't bother with the Run with highest privileges checkbox — that rarely helps. The real fix is giving the task a domain credential that has both network logon rights and permissions on the UNC path.
Quick-Reference Summary
| Cause | Fix | When It Helps |
|---|---|---|
| Stale credential cache | Clear via Credential Manager or klist purge | After password change or domain migration |
| Offline Files corruption | Disable/reenable offline files | Mapped drives fail after file sync issues |
| Wrong service/task account | Use domain account with network logon rights | Scheduled tasks or background services hitting shares |
If none of those get you there, check the event logs under Applications and Services Logs → Microsoft → Windows → NTLM or Kerberos. You'll usually see a KDC_ERR_C_PRINCIPAL_UNKNOWN or STATUS_LOGON_FAILURE that points to which account is breaking things. But honestly, the three fixes above cover 95% of the cases I've seen in the field.
Was this solution helpful?