Fixing 'The User Profile Service Failed the Logon' on Windows

“The User Profile Service failed the logon. User profile cannot be loaded” blocks you from logging in entirely — but the underlying cause is usually a corrupted registry entry for your specific user profile, fixable without losing your actual files.

Step 1: log in with a different administrator account, if one exists

You’ll need access to a working account (a separate administrator account, or Safe Mode with an account that still works) to fix the affected profile’s registry entries.

Step 2: boot into Safe Mode if no other account is available

Restart while holding Shift, then:
Troubleshoot → Advanced options → Startup Settings → Restart →
  press 4 or F4 for Safe Mode

Step 3: open the registry editor and locate the ProfileList key

regedit
Navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Step 4: identify your affected profile among the SID subkeys

Each subkey here is named after a Security Identifier (SID) corresponding to one user account. Look for a SID subkey, and check whether there’s also a matching subkey with .bak appended to it (e.g., both S-1-5-21-...-1001 and S-1-5-21-...-1001.bak) — this specific pattern, two related keys where one is a .bak variant, is the most common signature of this exact problem.

Click each SID subkey and check its State value:

A State value of 0 generally indicates a healthy profile.
A non-zero value (commonly 128 or similar) indicates the
profile Windows considers corrupted or incomplete.

Step 6: fix the key pair, if you found the `.bak` pattern from Step 4

1. Rename the (non-.bak) broken-looking key, e.g. append
   ".ba" temporarily
2. Rename the .bak key by removing ".bak" from its name
3. Rename the key from step 1 to append ".bak" instead
4. Set the RefCount and State values on the now-active
   (renamed) key to 0

This effectively swaps which of the two related registry entries Windows treats as the authoritative one for that profile — resolving the specific inconsistency that produces this error, without touching the actual user files on disk at all.

Step 7: restart and attempt to log in normally

shutdown /r /t 0

Step 8: if the registry fix doesn’t resolve it, create a new profile and migrate data manually

1. Create a new local user account
2. Log in as the new user once, to let Windows generate a
   fresh profile
3. Copy files from the old profile's folder (still present
   under C:\Users\) into the new profile's corresponding
   folders

This is a more manual fallback — your actual files under the old profile folder are still there and copyable even when the profile itself won’t load, since the files aren’t what’s corrupted; the registry pointer to the profile is.

Why this error is a registry-tracking problem, not a file-loss problem

The core of this error is Windows’ bookkeeping about which profile belongs to which user getting into an inconsistent state — not the actual user data being damaged or lost. Understanding that distinction is what makes the registry-level fix in Steps 4–6 the right first approach, rather than assuming the affected user’s files themselves need to be recovered from a backup.

How the .bak pattern actually gets created in the first place

This specific corruption pattern typically originates from an interrupted profile-loading sequence — a crash, a forced shutdown, or a specific kind of update installation occurring at exactly the moment Windows is in the middle of its own profile-registration bookkeeping. Windows’ profile system briefly creates a .bak-suffixed backup key as part of a normal, otherwise-invisible internal safety mechanism during certain profile operations, and if that operation is interrupted before it completes cleanly, the system can be left uncertain about which of the two related keys (the original or the .bak backup) should actually be treated as authoritative — exactly the ambiguity Steps 4 through 6 resolve manually by explicitly designating one as correct.

Why domain and Azure AD-joined accounts sometimes need a different first step

For a domain-joined or Azure AD-joined machine specifically, the SID-based profile matching covered above can additionally be complicated by a temporary loss of connectivity to the authenticating directory service at logon time — a domain controller or Azure AD unreachable at exactly the moment of login can produce a symptom that looks identical to local profile corruption but is actually a connectivity problem resolving itself once network access to the authenticating service is restored. Confirming basic network connectivity and, for domain-joined machines, connectivity specifically to a domain controller before assuming local registry corruption is the cause avoids misdiagnosing a transient connectivity problem as the more involved registry-level fix this guide otherwise walks through.

Preventing recurrence with regular profile backups

Because this specific failure mode can recur on a machine prone to unclean shutdowns (a laptop with an unreliable battery, a desktop on unstable power), maintaining a separate backup of critical user data outside the profile folder itself — rather than relying solely on the profile structure staying intact — reduces how consequential a future recurrence of this exact error actually is, even though the fix itself, when it does happen, doesn’t require data recovery from a backup in the first place.

Related:

Sources: