A profile that loads as a temporary desktop is a broken registry entry, not lost data. Fix the ProfileList key, build a clean profile and copy the data across.
Confirm the machine is loading a **temporary profile**, repair the **ProfileList** registry key for that SID, and copy the data into a fresh profile with **robocopy** while leaving **NTUSER.DAT** behind.
Windows names the session when the real profile cannot load. A folder under **C:\Users\TEMP** or a TEMP-prefixed profile in the list is the proof, not a slow sign-in.
Get-CimInstance Win32_UserProfile | Select-Object LocalPath,SID,Special,Loaded,LastUseTime
dir C:\UsersThe hive must be unloaded before you touch it. Sign out, and confirm that no process still holds NTUSER.DAT before you rename anything.
query user
Get-Process | Where-Object { $_.Path -like 'C:\Users\ana\*' } | Select-Object Id,NameWindows keeps one key per SID. **State** with bit 0x8000 set or a **.bak** suffix marks the broken entry that has to be repaired.
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList' |
ForEach-Object {
$p = Get-ItemProperty $_.PSPath
[pscustomobject]@{ SID = $_.PSChildName; Path = $p.ProfileImagePath; State = $p.State; RefCount = $p.RefCount }
} | Format-Table -AutoSizeIf a **.bak** key exists next to the real one, delete the broken key and drop the suffix from the backup. If not, set **State** and **RefCount** to 0 so Windows tries the original path again.
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-0000000000-0000000000-0000000000-1001" /v State
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-0000000000-0000000000-0000000000-1001" /v State /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-0000000000-0000000000-0000000000-1001" /v RefCount /t REG_DWORD /d 0 /fSign in with the account and let Windows build the profile. Copy documents, pictures and project folders from the old directory, excluding the registry hive and the caches that would carry the corruption over.
robocopy C:\Users\ana.old C:\Users\ana /E /COPY:DAT /R:1 /W:1 /XD AppData "Application Data" Cookies "Local Settings" NetHood PrintHood Recent SendTo Templates /XF NTUSER.DAT* ntuser.iniSign out and in twice. The path must stay the same, the TEMP entry must be gone from the ProfileList, and no temporary-profile banner may appear.
[Environment]::GetFolderPath('UserProfile')
Get-CimInstance Win32_UserProfile | Where-Object { $_.LocalPath -like '*TEMP*' } | Select-Object LocalPath,SIDDelete the TEMP entry for that SID, keep only the real path, and sign in again. The temporary entry is what makes Windows reuse the temp folder.
The hive itself is damaged. Rename C:\Users\<user> to <user>.old, let Windows create a fresh profile, and copy the data in.
Take ownership first with takeown /f C:\Users\ana.old /r /a and then grant yourself access, or copy from an elevated session.
Read the SID from the account, not from memory: Get-LocalUser and the ProfileList entry have to name the same value.
No. The profile failed to load; the files under C:\Users are still there. Only the registry hive is broken, and that holds settings, not documents.
Only after the new one worked for a week. Deleting it removes the folder too, and that is your fallback copy.
Rename the new profile folder, restore the exported ProfileList key with reg import, and restore the old folder name. Sign in once to confirm the original path loads again.
Free · no account needed · tracks your progress