Windows 10: User hive is loaded by another process (Registry Lock), Event ID 1552

​

When going through the Event Viewer, we noticed Event ID 1552, which says the User hive is loaded by another process (Registry Lock). This event is triggered when the Windows User Profile Service (ProfSvc) fails to load a user’s registry hive (typically ntuser.dat) during login because another process has locked the file. Due to this, you may […]

This article User hive is loaded by another process (Registry Lock), Event ID 1552 first appeared on TheWindowsClub.com.

read more...

 

User profile cannot be loaded with Fast Startup

I've just bought a laptop with Windows 11 on it and I'm facing a problem since day 1.

Every time I boot up my laptop, I get a "User profile cannot be loaded" error. When this happens, I reboot my laptop and Windows creates a temporal profile for me. Once it starts creating this temporal profile (I don't even need the process to finish), I log out from it and I can log in to my usual user normally.

I discovered I only get the error if I have the Fast Startup option enabled.

In the event viewer I get this error right before shutting down my PC:

Error: User Profile Service [id: 1512] -> Windows cannot unload your registry file. The memory used by the registry has not been freed. This problem is often caused by services running as a user account. Try configuring services to run in either the LocalService or NetworkService account. DETAIL - Access denied.

When I boot up the PC, the following errors appear in the event viewer (several times):
Error: User Profile Service [id:1552] -> User hive is loaded by another process (Registry Lock) Process name: C:\Windows\System32\SecurityHealthService.exe, PID: 15040, ProfSvc PID: 2532.

Error: User Profile Service [id:1552] -> User hive is loaded by another process (Registry Lock) Process name: C:\Windows\System32\svchost.exe, PID: 1752, ProfSvc PID: 2532.

Error: User Profile Service [id:1552] -> User hive is loaded by another process (Registry Lock) Process name: C:\Windows\SysWOW64\wbem\WmiPrvSE.exe, PID: 10836, ProfSvc PID: 2532.

Error: User Profile Service [id:1552] -> User hive is loaded by another process (Registry Lock) Process name: C:\Windows\System32\csrss.exe, PID: 1540, ProfSvc PID: 2532.
Error: User Profile Service [id:1542] -> Windows cannot load classes registry file. DETAIL: Access denied.

Is there anything I can do?

 

Windows 10 Application Log Event ID 1542 No start button/Windows cannot load classes registry file

I think that you did far more there than was needed to recover the situation (and if you changed permissions across the whole registry, then you may have made things worse).

My basic assertion remains valid, that a fake tree of registry keys is veing created at HKCU\SOFTWARE\Classes preventing the linking of the user classes hive there.

The broad strokes of the repair are:

• Confirm that you have error 1542 from "User Profile Service" stating "Windows cannot load classes registry file. DETAIL - Access is denied."
  
  in your Application log, occuring on each logon of the affected user. Do not proceed further if you do not have this event.
  
• Create a temporary admin account.
• Logged on as affected user, give the temp admin account full permission to the "Appdata\Roaming" folder within the affected users profile. (don't worry about issues propagating those permissions too deep into the folder tree - allow those ops to fail).
  You will probably need to set some permissions to the affected users home folder in order to allow the temp admin account to navigate to the roaming folder in a later step.
  
• Log off affected user
• Log on as temp admin
• navigate to appdata\roaming within the affected users home folder \ profile
• copy all ntuser* files to a safe place as a registry backup (handle the complete set of them as a single unit)
• use regedit to load the ntuser.dat from the (live) user profile under HKEY_USERS as key called "oldreg" (or anything else you want).
• Drill down in HKU\oldreg and check that a key HKU\oldreg\software\classes exists. If it does not, these instructions are not for you - go to unload hive below...
• If HKU\oldreg\software\classes exists, IT is the problem - delete it - in order to do that you will need to mess with permisisons on some of the subkeys of HKU\oldreg\software\classes to get them to go. Do not change any permissions outside of HKU\oldreg\software\classes.
• Once HKU\oldreg\software\classes is gone, click on HKU\oldreg to highlight it and select Unload hive (if you don't do this then the registry file wil be locked when the affected user tries to log on, which will then complicate matters with a temporary profile.
  
• once the hive is unloaded, log out of the temp admin and log on as the user - he should be back to normal (for the time being anyway). We have repaired the damage, but not stopped it happening again sometime in the future.

I'm still looking to debug deeper to find the root cause that gets the false HKCU\software\classes started in the wrong registry hive. I have discounted dropbox as a contributory factor.



NOTE: THE ABOVE INSTRUCTIONS ARE DANGEROUS TO FOLLOW IF YOU ARE NOT ALREADY COMPETENT IN VERY ADVANCED PERMISSIONS AND REGISTRY WORK. INCORRECT APPLICATION OF THE METHOD ABOVE WILL BREAK YOUR SYSTEM FURTHER...

Edited to correct some typos an to clarify/refine the third step, and to add check that event 1542 exists as first step.

 

Windows 10 Application Log Event ID 1542 No start button/Windows cannot load classes registry file

I do not believe that this issue is related to Norton - I've been hit twice by it in the past three days and I run kaspersky (I have seen the issue with kaspersky removed as well).

I am posting the following information to help other
advanced users work around the issue, and to apprise the Microsoft Staff around here of a partial explanation of what I have found (and suspect) is happening. Inexpert use of this information could
seriously damage your system - you have been warned.

First, a little background.... As part of user initialistion the users registry hive ("ntuser.dat" which forms HKEY_CURRENT USER) is loaded, and into that, the user classes registry hive ("UsrClass.dat") is mounted at 'HKCU\Software\Classes'. (HKCU\Software\Classes
does not exist until the User Classes hive is monted at that location).

What I found, was that in an affected user account, ntuser.dat contained Sofware\Classes key in its own right. When the user initialisation went to mount the user classes hive, it could not as the key already existed. Hence the "Access denied" error.

Using a separate administrator account, I loaded the user registry hive for the affected account. I was able to navigate to 'Software' within it. and there found a sparsely populated 'Classes' key within. Removing that key freed up the Classes key name.
I unloaded the affected users registry hive, logged out of the separate admin account and back in as the affected user. The affected user account then operated correctly.

I suspect that what is happening, is that on a login, before the user classes registry hive properly loaded, some software attempting to access a value from the user classes hive accidentally created a key under HKCU\Software\Classes without the real hive
being there to receive it. That falsely created key then blocked the real user classes hive from loading.

x64

I say again - removing the key that I indicated above, from the wrong part of the registry, or from the right part, but under the wrong circumstances could damage your system beyond sensible repair. Only use the information above if you fully understand
it. I have deliberately NOT posted a step by step guide.