“You’ve been signed in with a temporary profile” is one of the more alarming messages Windows produces, because everything looks gone. It isn’t. The data is almost always still on disk. Windows has simply failed to load the profile and given you a blank one to work in.
The important thing is what you do next: work in the temporary profile and you’ll lose whatever you create there when you sign out.
Quick Facts
- Your data is still there. It’s in
C:\Users\username, untouched. - Don’t work in a temporary profile. Anything saved is discarded at sign-out.
- The usual cause is a
.baksuffix on the profile’s registry key. - Sometimes the fix is a registry rename, two minutes, no data movement.
- When it isn’t, create a fresh profile and copy data across selectively. Never copy
NTUSER.DAT.
Confirm what you’re dealing with
Sign in as a different administrator, not the broken account, and check the profile list:
Get-CimInstance Win32_UserProfile |
Select-Object LocalPath, SID, Special, Loaded |
Sort-Object LocalPath
Then look at the registry, which is where the actual fault usually is:
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"
You’re looking for a key ending in .bak. Windows renames the key when it can’t load a profile, then creates a fresh one alongside. Which is the temporary profile you got dumped into.
Fix 1. The registry rename
If you have one key ending .bak and a matching one without, this usually resolves it outright.
Quick Steps
- Sign in as another administrator. Open
regedit. - Go to
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. - Export the whole ProfileList key first as a backup.
- Find the SID with
.bak, and the identical SID without it. - Rename the one without
.bakto something like.old. - Rename the
.bakkey to remove the suffix. - In that key, set
Stateto0andRefCountto0. - Restart and sign in as the affected user.
If both values already read 0 and it still fails, the profile itself is damaged rather than just mis-registered. Move on to the second approach.
Fix 2. Fresh profile, copy the data
This always works, and is often quicker than fighting a corrupted profile. The rule that matters: copy your data, not the profile’s internal machinery.
Quick Steps
- Sign in as a different administrator.
- Create a new local or domain account for the user, sign into it once to build the profile, then sign out.
- Sign back in as the administrator.
- Copy Documents, Desktop, Pictures, Downloads, Videos and Music from the old profile to the new one.
- Copy application data selectively. See below.
- Do not copy
NTUSER.DAT,NTUSER.DAT.LOG*orUsrClass.dat. Those are the corruption. - Verify everything, then remove the old profile properly via System Properties, Advanced, User Profiles.
$old = 'C:\Users\jsmith'
$new = 'C:\Users\jsmith.new'
foreach ($folder in 'Documents','Desktop','Pictures','Downloads','Videos','Music') {
robocopy "$old\$folder" "$new\$folder" /E /COPY:DAT /R:1 /W:1
}
For application data, copy specific folders rather than the whole AppData tree. Browser profiles, Outlook signatures, Sticky Notes. Copying all of AppData frequently drags the original problem into the new profile.
Why it happened
- Improper shutdown while the profile was being written. The most common cause by far.
- Disk errors in the profile’s files. Run
chkdskand check SMART data. - Antivirus locking
NTUSER.DATduring sign-out. - A full disk. Windows can’t write the profile back if there’s no space.
- Roaming profile sync failures in a domain environment.
If it happens repeatedly to the same user or machine, treat it as a symptom rather than an incident. Check the drive’s health first.
Removing a profile properly
Deleting C:\Users\username in Explorer leaves the registry entry behind, which causes exactly the problem you’re trying to fix. Use the supported route:
Get-CimInstance Win32_UserProfile |
Where-Object { $_.LocalPath -like '*jsmith*' -and -not $_.Special } |
Remove-CimInstance
Glossary
| Term | What it means |
| Temporary profile | A blank profile Windows creates when it can’t load the real one. Discarded at sign-out. |
NTUSER.DAT | The user’s registry hive. Corruption here breaks the profile. |
| ProfileList | The registry key mapping SIDs to profile folders. |
.bak key | A profile key Windows renamed after failing to load it. |
| SID | Security Identifier. The unique ID for an account. |
UsrClass.dat | A per-user registry hive for file associations and shell settings. |
Frequently asked questions
Have I lost my files?
Almost certainly not. They’re still in C:\Users\username. What’s broken is Windows’ ability to load the profile, not the data inside it.
Why can’t I just copy the whole old profile over?
Because NTUSER.DAT and UsrClass.dat are usually the corrupted part. Copy them across and you copy the fault with them.
Will the registry fix always work?
No. It resolves cases where the profile is fine but mis-registered. If the hive itself is damaged, you need a fresh profile.
How do I stop it happening again?
Make sure machines shut down cleanly, check disk health, and confirm antivirus isn’t holding files open at sign-out. Repeated occurrences on one machine usually mean a failing drive.
Can I recover an encrypted profile this way?
With EFS-encrypted files you need the user’s certificate, so sign in as them if at all possible. BitLocker doesn’t affect this. It’s whole-disk, and the files decrypt normally once Windows is running.
Gear We Recommend
Recovering data from a machine that will not cooperate? Here’s the kit we use.
Browse our Storage & Backup picks on AmazonAs an Amazon Associate, TechyGeeksHome earns from qualifying purchases
Disclosure: this post may contain affiliate links. If you buy through one of them, we may earn a small commission at no extra cost to you. We only recommend products we’ve tested or genuinely rate.
Discover more from TechyGeeksHome
Subscribe to get the latest posts sent to your email.