[Solved] Unable to log in to Windows, redirected to "temporary user"

[Valantar]

I got a call from my parents just now, and my mom is having an issue with her laptop that baffles me. When trying to log in to Windows, she gets an error message saying something like "unable to log in to your account", and she's then given access to a temporary account instead. I had no idea that even existed. It literally shows up as /users/temp. Rebooting and trying again causes the same thing to happen, with a new temp account being created (as of now, there are three of them). Her regular account is there, and all files seem intact, but that's not much help if she can't log in. Has anyone heard of anything like this before? I certainly haven't.

I can't remember what laptop it is, but I think it was upgraded to W10 (as in: didn't ship with it).

Could this be some sort of really weird malware?

 

[corkyg]

Does indeed sound like malware.

 

[daveybrat]

Sometimes it's just corruption in the user profile caused by an incomplete Windows update or just corruption in general. I'll fixed it most times just by using system restore and going back in time a day or two.

P.S. It can also be caused by a failing hard drive. Bad sectors can cause damage to the account and forces Windows to create a Temp account.

 

[mikeymikec]

I've come across this problem on quite a few occasions. I'd back up the user profile to begin with, just in case, but normally the solution is quite simple:

Create another user and give it admin privs:
Admin command prompt:
NET USER TESTADMIN /ADD
NET LOCALGROUP ADMINISTRATORS TESTADMIN /ADD

Sign out of the problematic user

Log in as testadmin
Fire up regedit
Browse to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

There'll be a few subkeys with long CLSID type names, but one of them will have ".bak" on the end. If you want to back up 'ProfileList' to a registry file as a precaution, feel free. Rename the subkey with ".bak" on the end to not have the ".bak" on the end. If there's already a duplicate subkey of the same name (ie. without ".bak") then rename that to have .somethingelse on the end.

I'd probably reboot to be on the safe side, then normally I can just sign in to the original account. Feel free to delete the testadmin account afterwards.

I have no idea why it happens. I've never had a machine have this problem twice.

 

[Valantar]

Thanks for the input! Sounds like this is fixable, though I probably will have to take a trip to visit them to fix it - unless I can convince my dad to do it. He's somewhat computer-literate, although I think this is above his level. We'll see. Thanks anyway!

 

[Valantar]

I've come across this problem on quite a few occasions. I'd back up the user profile to begin with, just in case, but normally the solution is quite simple:

Create another user and give it admin privs:
Admin command prompt:
NET USER TESTADMIN /ADD
NET LOCALGROUP ADMINISTRATORS TESTADMIN /ADD

Sign out of the problematic user

Log in as testadmin
Fire up regedit
Browse to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

There'll be a few subkeys with long CLSID type names, but one of them will have ".bak" on the end. If you want to back up 'ProfileList' to a registry file as a precaution, feel free. Rename the subkey with ".bak" on the end to not have the ".bak" on the end. If there's already a duplicate subkey of the same name (ie. without ".bak") then rename that to have .somethingelse on the end.

I'd probably reboot to be on the safe side, then normally I can just sign in to the original account. Feel free to delete the testadmin account afterwards.

I have no idea why it happens. I've never had a machine have this problem twice.

Just to clarify, when you say "back up the user profile", do you mean anything more than copying the /users/[username] folder to another location?

Also, will there always be a registry key with the .bak suffix? Does this require some sort of System Restore to be active? Or does this happen automatically? Can I get into an admin command prompt from a temporary user (I'm guessing this would give some sort of permissions pop-up, but as I haven't seen it myself I prefer to ask)?

 

[mikeymikec]

Just to clarify, when you say "back up the user profile", do you mean anything more than copying the /users/[username] folder to another location?

That's all that I do. My personal interest in backing up the profile is to ensure that necessary files are kept with which a new profile could be reconstructed without the loss of anything terribly important. There is a 'copy profile' function in System properties, but IIRC it does something stupid like entirely skip the 'AppData\Local' folder structure. I normally use the robocopy comand. If I wanted to try and save the profile entirely, I would try using a combination of the 'copy profile' function and use the copied folder structure from my manual folder copy to fill in the blanks before attempting to restart the resurrected profile. But I've never bothered to try this.

Also, will there always be a registry key with the .bak suffix?

Depends on a load of factors, though in my experience the problem you described leaves behind that registry key. I assume the problem I'm aware of occurs when Windows tries to load a user profile and craps out. However, as others have said, this could be a hardware issue, in which case all of Windows's failsafes may not be properly triggered or implemented.

Does this require some sort of System Restore to be active? Or does this happen automatically? Can I get into an admin command prompt from a temporary user (I'm guessing this would give some sort of permissions pop-up, but as I haven't seen it myself I prefer to ask)?

AFAIK, when Windows can't load a user profile, it renames that subkey and creates a new one pointing to the temporary profile. System Restore has nothing to do with that AFAIK, I don't see why it would.

If you're wondering whether system restore might fix this problem, it is possible. However, as system restore is a destructive operation by its very nature, I would still back stuff up beforehand. I treat SR as the bluntest tool in the box; sometimes it works for more complex problems when all else fails, mostly not in my experience.

 

[Valantar]

That's all that I do. My personal interest in backing up the profile is to ensure that necessary files are kept with which a new profile could be reconstructed without the loss of anything terribly important. There is a 'copy profile' function in System properties, but IIRC it does something stupid like entirely skip the 'AppData\Local' folder structure. I normally use the robocopy comand. If I wanted to try and save the profile entirely, I would try using a combination of the 'copy profile' function and use the copied folder structure from my manual folder copy to fill in the blanks before attempting to restart the resurrected profile. But I've never bothered to try this.



Depends on a load of factors, though in my experience the problem you described leaves behind that registry key. I assume the problem I'm aware of occurs when Windows tries to load a user profile and craps out. However, as others have said, this could be a hardware issue, in which case all of Windows's failsafes may not be properly triggered or implemented.



AFAIK, when Windows can't load a user profile, it renames that subkey and creates a new one pointing to the temporary profile. System Restore has nothing to do with that AFAIK, I don't see why it would.

If you're wondering whether system restore might fix this problem, it is possible. However, as system restore is a destructive operation by its very nature, I would still back stuff up beforehand. I treat SR as the bluntest tool in the box; sometimes it works for more complex problems when all else fails, mostly not in my experience.

Yeah, I tend to avoid any kind of System Restore unless I absolutely have to. I have no idea if it's even activated on that PC (i.e. if there are any images to revert to besides a complete reset). I was simply wondering if that might have some relation to the registry .bak thing. Thanks for the input, though.

So, the proposed procedure is:

• log in to temp user
• copy /users/[username] folder (including hidden folders) to a safe backup location to avoid data loss
• run an admin command prompt with the commands NET USER TESTADMIN /ADD and NET LOCALGROUP ADMINISTRATORS TESTADMIN /ADD
• log out, log in to "Testadmin" (I'm guessing this account will have no password?)
• In regedit, browse to Browse to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList, find the subkey with the .bak ending, remove the ending (and if necessary add .somethingorother to the end of the key it would otherwise replace)
• reboot, log in to regular user

And that should be it?

 

[mikeymikec]

Nope. Log in as original user (with temp profile), create testadmin, sign out of temp user, sign in as testadmin, back up original user folder, make the registry change, reboot, log in as original user.

 

[Valantar]

Okay, thanks. Is there any reason to do the backup from the testadmin user? Access privileges or some such?

 

[mikeymikec]

Okay, thanks. Is there any reason to do the backup from the testadmin user? Access privileges or some such?

If you're attempting to copy a profile of a user who is already signed in, you won't get a complete copy of all the files. As far as privs are concerned, you have to copy the files with admin privs, so I normally fire up a command prompt with admin privs and use robocopy.

 

[Valantar]

Just to update you guys (especially @mikeymikec) and anyone who might find this thread later, I ran through the steps above and it worked just as described. Everything went back to normal after removing the ".bak" ending on the relevant registry key, with no issues at all. Thanks for all your help!


Given how slow the PC was in general and that the HDD was noisier than I would like*, I recommended they swap it out for an SSD soon, but as of now they're happy it's up and running again. I'm not 100% convinced this wasn't caused by data corruption due to a bad sector or some such, but I couldn't actually tell anything was truly broken. At the very least everything is backed up, in case it goes off and dies on us in the next few weeks/months.

*I haven't used an HDD-based PC for quite a few years, so in all honesty I don't know how far from normal it was.

 

[mikeymikec]

Levels of HDD noise vary greatly. IMO if a drive works reliably, its SMART readings are OK and the event log isn't throwing up disk/ntfs errors, I'd probably class the drive as OK unless I knew for a fact that the drive sounded abnormal from experience with that particular drive.

 

[Valantar]

Levels of HDD noise vary greatly. IMO if a drive works reliably, its SMART readings are OK and the event log isn't throwing up disk/ntfs errors, I'd probably class the drive as OK unless I knew for a fact that the drive sounded abnormal from experience with that particular drive.

My main cause for concern was performance - backing up the \appdata\ folder took forever, with severe performance dips for smaller files (I'd estimate a mere handful of files per second for anything with truly small file sizes). Logging in to the original user after restoring it also went through 5-10 seconds with only a black screen and mouse cursor before loading the desktop and UI, which might have been because of the restoration stuff, but was still worrying. I didn't look at SMART data, but even if the drive is just dead slow without being broken, I'd argue that's sufficient reason for stuffing a cheap 240GB SSD in there. Better safe than sorry.

 

[John Connor]

The very fact the profile was damaged before tells me the HDD is going south. I would have that replaced ASAP.

 

[mikeymikec]

My main cause for concern was performance - backing up the \appdata\ folder took forever, with severe performance dips for smaller files (I'd estimate a mere handful of files per second for anything with truly small file sizes). Logging in to the original user after restoring it also went through 5-10 seconds with only a black screen and mouse cursor before loading the desktop and UI, which might have been because of the restoration stuff, but was still worrying. I didn't look at SMART data, but even if the drive is just dead slow without being broken, I'd argue that's sufficient reason for stuffing a cheap 240GB SSD in there. Better safe than sorry.

Tiny files always take ages in comparison; unless you're used to what to expect with the USB speed and particular storage device you're using as well as the platform you're copying from, YMMVG. When I back up user profiles, I have a list of about 20 folders that I have robocopy exclude simply because they take freaking ages to copy and their contents are of no value whatsoever (browser cache folders for example); and way longer if copying to a USB flash drive. There's one folder called 'CryptNetURLcache' for example that can take ages to copy in some circumstances.

An SSD upgrade is always nice though

The very fact the profile was damaged before tells me the HDD is going south. I would have that replaced ASAP.

I've employed the solution described in this thread probably 20 times in total (it is pretty rare, whereas I've probably replaced ten times as many faulty HDDs), and only two occasions I recall being called out for this was the problem likely to have been caused by a faulty hard drive. The first few times I encountered it I thoroughly checked the disks for problems because I thought as you do about it, but no problems then or shortly after.

The thing is, when a modern version of Windows (Vista and later) signs out a user profile, it makes entries in the event log if it had any trouble saving the user's registry data on exit (for example, if the security software had locked a particular registry value, or some systray app). Many machines will list this entries without any problems happening at any point soon. I can only theorise why the user profile sometimes get locked out, but I suspect it's because Windows basically said "enough is enough", perhaps because the user profile hadn't been fully signed out and user registry completely saved in any of say the last 10 signouts, and so Windows marks the profile as dirty and moves on. Perhaps there's a similar failsafe system to when Windows 'Automatic Repair' kicks in, because that certainly doesn't kick in every time Windows fails to boot, but obviously there must be some logic to dictate when it does, and it's not necessarily related to a dodgy disk.

Furthermore, if it was a dodgy disk often causing this problem, then it would surely result in the user profile still not loading after the registry entry has been changed; if Windows said "that profile is borked because I'm having I/O errors when trying to read it and I've had enough of this BS for one day!", that's not going to change simply by changing that registry value.