0X000004DD

Fixing ERROR_NOT_LOGGED_ON (0X000004DD) on Windows

Network & Connectivity Intermediate 👁 0 views 📅 May 27, 2026

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

  1. Open Control Panel → Credential ManagerWindows Credentials.
  2. Look for entries under Windows Credentials that match the target server or share (e.g., TERMSRV/ServerName or MicrosoftAccount:user@domain).
  3. Remove them. Yes, all of them. Don't be shy.
  4. 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

  1. Open Control PanelSync CenterManage offline files.
  2. Click Disable offline files.
  3. Reboot.
  4. 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

  1. Open Services.msc and find the service that's failing.
  2. Right-click → PropertiesLog On tab.
  3. Change from Local System or Network Service to a domain user account with proper permissions on the target share.
  4. Enter the password twice. Click OK.
  5. Restart the service.

For scheduled tasks, open Task Scheduler, find the task, and under GeneralSecurity 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

CauseFixWhen It Helps
Stale credential cacheClear via Credential Manager or klist purgeAfter password change or domain migration
Offline Files corruptionDisable/reenable offline filesMapped drives fail after file sync issues
Wrong service/task accountUse domain account with network logon rightsScheduled 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?