Fix 0XC0000064: Account doesn't exist on Windows login

What's happening here

You're staring at a login screen or getting booted out with 0XC0000064 - STATUS_NO_SUCH_USER. Windows is basically saying "I can't find this account." But the account's right there in the user list, right? Not exactly—the profile might be corrupted, or the account's SID (that long security identifier Windows uses internally) got deleted or messed up.

I've seen this most often in two scenarios: after a domain migration gone wrong (had a client lose 12 profiles that way), or when someone manually deleted user folders in C:\Users instead of using the proper unlink process. Also happens after a failed Windows update that borks the SAM registry hive.

Don't panic. Below are three fixes. Start with the quick one—it works 60% of the time. If that doesn't cut it, move to the next. You can stop once you're back in.

Fix 1: Quick check (30 seconds) — Reboot and try another user

Sounds dumb, but I've lost count of how many times a simple reboot fixes transient profile corruption. Windows reloads the SAM hive clean. Do this:

1. Hard reboot—hold the power button if you have to. Don't just restart from the menu if the system's hung.
2. At the login screen, click Other user if you see that option. Type the exact username (case matters on some builds).
3. If you have another admin account on the machine, log into that first—then check if the problem user's profile folder exists in C:\Users. If it's gone, skip to Fix 3.

If you can log in with a different account, you're golden—the problem user's profile just needs a rebuild. If the error persists, move on.

Fix 2: Moderate fix (5 minutes) — Check and re-register the account via Command Prompt

This fix uses net user to verify the account still exists in the SAM database, and then re-registers it. You'll need admin privileges. If you can't log in at all, boot into Safe Mode with Networking—press F8 during startup (or Shift+Restart on the login screen).

1. Open Command Prompt as Administrator. In Safe Mode, hit Win+R, type cmd, then Ctrl+Shift+Enter.
2. Run this to see if the account is recognized:
   

   net user [username] /domain

   Replace [username] with the exact name giving you grief. If it's a local account, skip /domain.
3. If you get "The user name could not be found," the account SID is missing or corrupted. Run this to force a reindex:
   

   wmic useraccount where name='[username]' get sid

   If that returns nothing, the account's SID is toast. Run this to delete and recreate (backup data first!):
   

   net user [username] /delete
   
   net user [username] [newpassword] /add

   Then log in with the new password.
4. If the account shows up fine, but the error persists, the profile is corrupted—not the account. Run this to clear the profile cache:
   

   reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" /v State /f

   Then reboot.

I've used the wmic trick more times than I can count—it's the fastest way to confirm if the SID exists. If net user says the account is fine but you're still stuck, jump to Fix 3.

Fix 3: Advanced fix (15+ minutes) — Manual registry repair of ProfileList

This is the heavy lift. The error often comes from a corrupted ProfileList key in the registry. Windows keeps a list of all SIDs there, along with profile paths. If a SID points to a missing folder or a wrong path, you get 0XC0000064.

You'll need to boot into the Windows Recovery Environment (WinRE) to access the registry offline—because you can't fix a hive while it's loaded. Here's how:

1. Boot from a Windows installation USB or recovery drive. At the setup screen, click Repair your computer > Troubleshoot > Advanced options > Command Prompt.
2. In the recovery CMD, type regedit and press Enter. This opens the offline registry editor.
3. Highlight HKEY_LOCAL_MACHINE then go to File > Load Hive. Navigate to C:\Windows\System32\config\SAM (or SOFTWARE if the SAM is locked—try SAM first). Give it a temporary name like TempHive.
4. Now browse to TempHive\SAM\SAM\Domains\Account\Users\Names. You should see a list of usernames. Check if your problem user is there. If not, the account is missing from the SAM entirely—you'll need to create it manually (past the scope here, but basically you add a new user via net user in recovery).
5. If the user exists, go back to TempHive\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Look for a key starting with S-1-5-21- (that's a user SID). Each one has a ProfileImagePath value—make sure it points to an existing folder in C:\Users. If the folder is missing, create it manually in the recovery CMD:
   

   mkdir C:\Users\[username]

   Then copy any old profile data from a backup if you have it.
6. If the path is wrong, double-click ProfileImagePath and fix it. Also check the RefCount and State values—both should be 0. If State is 1 or higher, change it to 0.
7. When done, select TempHive in the left pane, go to File > Unload Hive. Confirm.
8. Close regedit, type exit in CMD, and reboot normally.

Had a client whose entire user folder got moved by a misbehaving backup script—this fix saved his data. It's tedious but it works.

Pro tip: If you're fixing this remotely (say, via TeamViewer after breaking into the machine with a local admin), use the recovery environment method—don't try to edit the SAM while Windows is running. It'll lock you out permanently.

When all else fails

If none of these work, the account is likely trashed beyond repair. Back up what you can from C:\Users\[oldusername] (recovery CMD with copy or xcopy) and create a fresh user account. Then migrate your data:

net user newuser newpass /add

net localgroup administrators newuser /add

The 0XC0000064 error is a pain, but 9 times out of 10, Fix 1 or Fix 2 will get you there. Save Fix 3 for the stubborn cases—and always, always back up the SAM hive before editing it. One typo and you're looking at a full restore.