The problem
I have a Windows 10 laptop with 2 accounts, an administrator and a non-adminitrator. This has worked perfectly for almost a year now. Recently I created a 3rd account, as non-administrator. This account is logged off as soon as the password is confirmed, so I never see the desktop.
Windows event log
To see what Windows event log can tell about this, I did the following test: At 09:44:23 I tried to login on the new account, which failed. At 09:44:27 I logged in on an existing account, which worked.
From System log
09:44:23 Winlogon - event 7001, info (bad login)
09:44:24 Service Control Manager - event 7023, error
09:44:24 DistributedCOM - event 10016, error
09:44:24 DistributedCOM - event 10016, error
09:44:27 Winlogin - event 7002, info (good login)From Program log
09:44:23 User Profile Service - event 1542, error "Windows cannot read registration database for classes. File not found" (my Translation) -- this error 3 times.
09:44:24 Winlogon - event 6000, info (also present on good login)
09:44:24 igfxCUIService2.0.0.0 - event 0, info (also present on good login)
09:44:24 Winlogin - event 4006, warning "unable to spawn program C:\Windows\System32\userinit.exe" – Peer Sommerlund 20 hours ago My attempts at solving it
If I change the user type to administrator, I can log in, but the desktop looks strange.
I have tried deleting the account and creating it again, but the problem persists on any new account I create.
My question
What could I have changed to the system to bring it to this state?
How can I fix the new account so it will work as non-administrator?
Similar solutions found on the net
I found this link, which describes a similar issue. My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit key holds C:\Windows\system32\userinit.exe, which works ok for the 2 first accounts (the trailing comma does not appear to cause an issue) so this is not a solution.
13 Answers
Explanation:
What's the problem?
Your problem is caused by a corrupted NTUSER.DAT file.
Windows creates one user profile folder in C:\Users\ for each user account, excluding special accounts like SYSTEM, and each one of these folders contains a NTUSER.DAT file, which is used to store settings and such things.
Why are only new accounts affected?
Well that's because there's one profile folder called Default which is not associated with any profile instead it gets copied each time a new profile folder is needed to fill that new profile with all necessary files.So every modification/damage of the Default profile will be copied into all new profile folders.
So finally your problem is a corrupted NTUSER.DAT file inside the Default profile folder.
How to fix it?
The only way I know is replacing NTUSER.DAT in the Default profile folder with a fresh one of a new Windows 10 installation or replacing it with a backup.
For the first option you will lose some system-wide shortcuts for a program in a new account on the desktop, some system-wide user-specific settings, etc., but it won't affect existing profiles.
Maybe somebody has a better idea.
I had a similar issue with a Dell laptop that came preloaded with an HP Image... weird I know (A whole batch too!). Anyway, we researched this over and over and came to the conclusion that it was likely to do with the NTUSER.dat, however in the final stages of research found another issue that is possible;
If you have uninstalled software, in our case it was HP Security Manager, it may not have properly removed the UserInit entry created for it. The below change should hopefully help other users with the same issue searching in the future;
If you can somehow get logged in in safe mode or under an administrator account, check out the registry.
HKLM/Software/Microsoft/Windows NT/CurrentVersion/Winlogon - Look at theUserInit key.
Make sure it doesn't have anything extra in it. It should only contain C:Windows\system3\userinit.exe
In my case it had the following;
C:\Windows\system32\userinit.exe,c:\Program Files (x86)\Hewlett-Packard\HP ProtectTools Security Manager\Bin\DPAgent.exe
I changed to the following (via an admin account) and it would login to all users normally;
C:\Windows\system32\userinit.exe
Source: ( Scroll down to the response by 'Normal user name225' )
Have got 'similar' problem recently on my wife’s notebook. She was not able to log into own profile after … surprise … silent automatic upgrade of the windows to version 20H2.
Shortly: I was not able to fix this issue completely – finally just deleted and re-created user with the same name and password. Of course, all user configuration needs to be re-created after that. Not sure how encrypted folders would work after that, did not have such on that notebook. ...
In more details: ...
I guess root cause of the problem is that ‘problemous’ user profile was initially migrated from another computer a year ago (not sure about exact recipe used) and windows self-update procedure did not understand that hack and scrambled that profile. Other 2 ‘native’ profiles are OK after upgrade.
The reason why user failed to log in my case – no permission to read own registry. That happened because access permissions where granted to user’s ID which is not known after upgrade. Shortly there are 2 user IDs:
- ID=…1003 – for UserXXX
- ID=…1004 – for UserXXX
Two different IDs for the same user name. All permissions are granted to ‘1003’, but current login for UserXXX is bound to ID=…1004. So if I load user’s hive into registry, access permissions say “they are granted to unknown user with SID=…1003”
You may try following ways to fix such problem:
If PC does not have another profile to log in, you can log into problemous profile while running windows in “safe mode”: on login screen press shift while clicking ‘restart’ -> then during boot select: Troubleshoot -> Advanced Options -> Startup settings -> … after one more reboot select 4) “Enable Safe Mode” – you may create another admin user and normally log into that profile, then re-create initial user.
Rewrite access permissions in registry
- Start regedit
- Select “HKEY_LOCAL_MACHINE” then in menu “Load Hive” -> select “C:\Users[UserName]\NTUSER.DAT”, give some dummy name like “xxxx” to load hive into registry
- Right click on “xxxx” -> Permissions -> Grant access to wanted user Note: some explicit restrictive permissions can be assigned on deeper registry node, in my case it was “HKEY_CURRENT_USER\Control Panel\International” After these changes I was able to log in, but … other sporadic problems occurred in other places. Normal work was not possible and I decided that re-creating a user would be the easier way to solve all-at-once, than trying to fix issues one-by-one.
More inputs to try investigating/fixing such problem:
List of known profiles and their SIDs are here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileListList of locations of registry hives:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelistI used while investigating the problem. Run it from working profile as “shift + right click” -> “different user” ->”problemous user”, then try logging into problemous profile, then switch back to working user to view the log. Filtering by “process name = explorer.exe” and “Result = ACCESS DENIED” will show what is causing problems.
