Main Forum > Tweaking.com Support & Help
Event ID 1542 - Customize Notification Area Icons fault - Win7
Dougcuk:
System details: Windows7-SP1x64 + Tweaking Registry Backup v3.3.1
When Tweaking Registry Backup creates the backups of the registry files it uses a slightly different set of Security Permissions from the originals. When the files are restored these new permissions appear to be replicated back to the live files. Mostly this appears to have no side effects.
However under Win7 it appears that changes to the UsrClass.dat security permissions do have one problem
The Customize Notification Area Icons feature no longer saves changes to survive a reboot
Any changes you make persist for the current session but are wiped back to defaults after a reboot
In the Application Event log you get the following User Profile Service error:
Event ID 1542 - Windows cannot load classes registry file. DETAIL - Unspecified error
Note: no other symptoms - no problems with login to account - no warning messages - just the Notification Area issue
I am seeing this issue on two different new build Win7 x64 (Home Premium) computers
The altered security permissions on the UsrClass.dat file appear to be the cause.
The Current user is no longer explicitly named in the permissions list
The list now has SYSTEM, Administrators(group), Users(group)
The Users(group) with limited Read/Execute has been added (others are all Full Control)
Even though the current user is a member of the Administrators group which has Full Control this doesn't appear to be sufficient for the Customize Notification Area system to be able to permanently save any changes.
Restoring the current username to the permissions list with Full Control (Inherited) solves the issue
I also removed the Users(group) entry to revert back to original settings.
The same change are also present on the NTUser.dat file
I also reverted that back in the same way just in case of other as yet undetected issues.
The problem with the Customize Notification Area may be due to a bug in the Microsoft code for that routine
However I doubt Microsoft will fix this problem unless it also affects later Windows versions
This same odd behaviour may also be present in Win8 - reports do exist online - cause unknown
Other programs that save to UsrClass.dat or NTUser.dat could also be affected by the changed security permissions.
UPDATE: A similar problem was reported back in August 2015 with Win10
ACLs on UsrClass.dat messed up after restore - http://www.tweaking.com/forums/index.php/topic,3504.0.html
Issue is the same for both backup method - Fallback and VSS
Checked ERUNT registry backup and that preserves the Current User (profile owner) in the permissions list
Shane:
This is what makes this odd with Windows 10. My program uses the regload api so restore the registry files.
So it is windows restoring the registry files. Yet this problem isnt happening to the other system registry files, just the user registry. This also doesn't seem to happen in earlier versions of Windows.
One thing I did double check on is that if the regload api isnt able to load the current user registry file then the program calls the move files at boot registry key to move the registry file over for the user. This call isnt done on the system registry files, so I am wondering if there is a bug in Windows 10 when using the move file at boot.
I havent changed the restore code since the start of the program because it hasnt been needed, but looks like 10 and its mountain of bugs is forcing me to look into a better way to restore the registry :-)
Looks like the move file at boot will need to be pulled. Now if I can just remember why I had to do that in the first place lol
But just to be clear, my program isnt writing the registry keys or anything, it is only moving the hiv file itself. Thats why it is odd the permissions are being changed by Windows.
Shane
Dougcuk:
Just to clarify my report related to a specific issue on Win7 - so I think the issues with Win10 are most likely a different problem
I only cited the earlier report re Win10 just in case it sparked any memories
- regarding issues caused by ACL permissions on the UsrClass.dat file.
The problem I observed on Win7 after a registry restore:
The taskbar feature "Customize Notification Area icons" had a problem
All customizations worked as expected with no error messages
- they even survive a logoff/logon (The User hives are not unloaded immediately I assume)
- but the customizations do NOT survive a reboot
- the icon setup reverts to global defaults after the reboot
Checking the Event Log you find a User Profile Service error 1542 - in the Application log
Event ID 1542 - Windows cannot load classes registry file. DETAIL - Unspecified error
Note: This event occurs during LOGON - not at the time you alter the Notification Area icons
Note: There are no warning messages shown during User Logon or Logoff to indicate a problem
When I then checked the UsrClass.dat file I discovered that the Security Permissions were different from the "vanilla" settings
- as seen on an identical Win7 computer (I built the two in parallel only two months ago).
The Security Permissions on the UsrClass.dat file no longer included the explicit name of the current user (in my case Doug)
- but appeared to be relying on the two group accounts (Users and Administrators) plus SYSTEM to cover all possible options.
This SHOULD NOT cause a problem (at least in my case) as "Doug" is a member of the Administrators group and thus
shows "Effective Permissions" of Full Control when this is checked via the Advanced button of the Security Permissions tab.
However with Win7 during the user Logon a Red Application Error is generated [I have not tested Win8 or 10]:
Event ID 1542 - Windows cannot load classes registry file. DETAIL - Unspecified error
The Users Classes file doesn't load and you revert to the defaults from the global Classes registry
This means that settings that were stored in UsrClass.dat are not available after a reboot
As you would expect - User specific Folder View customizations (set in Windows Explorer) are also lost
No errors are generated when attempting to write to UsrClass.dat
- and I suspect that customized settings are in fact saved to the file
- but Win7 just refuses to load the file at the next startup (due to the non-standard Permissions).
This appears to be a "bug" in the way Win7 handles the loading of the UsrClass.dat registry file
- which is triggered by the "different" Security Permissions created by the registry restore.
All a bit annoying - but NOT something I expect you to worry about too much
- just file for reference and maybe add a FAQ note
I have also now worked out how to manually fix the problem - detailed in the following post
Dougcuk:
The quick fix is to reinstate (Add) the current user to the Security Permissions list with Full Control
You still have to redo the icon customizations - the original settings having been zeroed
- so it appears Windows happily writes settings back to UsrClass.dat at shutdown
- it just will not load the file at Logon without the Current User having Full Control
The more extensive fix is to re-instate the Inherited Security Permissions for the UsrClass.dat file
- all Permissions are shown as <not inherited> after the registry restore
You do this via the Advanced option button on the Security Permissions tab
- tick the box for "Include inheritable permissions from object's parent" and then Apply
- all the original Security Permissions including the current user then magically reappear
- you can then safely remove all <not inherited> versions, leaving only the original inherited ones
---------------------------------------------------------
NOTE: The "non-standard" Security Permissions are not specific to just the UsrClass.dat file.
All the registry files show the same changes - the explicit "current user" with Full Control is lost during the backup step
and the Users group account (with restricted Read & Execute permissions) is added.
This is obviously not a problem in general or your program wouldn't work as well as it does.
I assume the changes just happens to unmask a bug in the Microsoft code for this specific Logon event.
Some other tests I have done:
The same Security Permission changes are present regardless of the backup method - VSS or Fallback
It makes no difference if you run the backup using the System account rather than the Current User account
Altering the Security Permissions on the backup file before restore doesn't work - changes are lost on restore
Tests show that ERUNT Registry Backup utility retains the original Security Permissions of the files
- both the back versions and the restored versions retain the original User list and Security Permissions
- both versions of the files also show ONLY inherited Security Permissions, none are listed as <not inherited>
I can provide details or screen grabs of the full Security Permissions listing
before and after the restore if it would clarify the situation.
Again I would stress that I do not consider this a serious issue
But I thought it best to document the error in case the "non-standard" Security Permissions
cause any similar issues at some point in the future - additional "bugs" in Microsoft code might well exist.
Dougcuk:
I have just discovered how to resolve 50% of the problem with altered Security Permissions
I had been using the "Backup Location" as set by the Tweaking Registry Backup installer
- this was set as %WindowsDrive%\RegBackup\
- for me, as for most users, this equates to C:\RegBackup\
I had already found that ERUNT preserved the correct Security Permissions during both Backup and Restore
However for ERUNT my backup folder is located inside my Users Folder - C:\Users\Doug\ERUNT\
So as a test I changed the Backup Location (for Tweaking) to parallel the setting I use for ERUNT
- so I set it to %CurrentProfile%\RegBackup\
- which equates to C:\Users\Doug\RegBackup\
And magically this caused the backup files to retain the correct Security Permissions as per ERUNT
Thus changing the Backup Location - from C:\RegBackup\ to C:\Users\Doug\RegBackup\
solves half of the problem - the backup files now retain the original "Doug Full Control" Security Permission entry
The Security Permissions seen when using C:\Users\Doug\RegBackup\ were as follows:
SYSTEM Full Control Inherited from C:\Users\Doug\
Administrators (Group Account) Full Control Inherited from C:\Users\Doug\
Doug (Current User) Full Control Inherited from C:\Users\Doug\
The Security Permissions seen when using C:\RegBackup\ were as follows:
SYSTEM Full Control Inherited from C:\
Administrators (group account) Full Control Inherited from C:\
Users (group account) Read & Execute Inherited from C:\
So I had high hopes that when I ran a restore that the restored registry files would retain
the now correct (Inherited) Security Permissions - but sadly no.
We again end up with the incorrect "Not Inherited" versions - just as before
We end up with the following Security Permissions on the restored files:
SYSTEM Full Control Not Inherited
Administrators (group account) Full Control Not Inherited
Users (group account) Read & Execute Not Inherited
Just as before we have no Inherited Permissions and also lose the critical "Doug - Full Control" entry
- and the "Users (group account) - Read & Execute" entry is recreated
So the new question is:
Why does the Restore process fail to preserve the "correct" Security Permissions now showing on the backup files?
I'm not sure of the ramifications of moving the Backup Location folder out of the root
- it suits my situation as I only use one primary user account
- but it could be complicated where you have multiple active users on the computer
- backups would no longer be in one central location but saved per user
- and as for backups scheduled at startup I'm not clear where it would attempt to save those
Any ideas about forcing the Inherited Security Permissions to be applied to the restored file?
I will leave you to ponder that one!
UPDATE:
Having done some research the following rules should apply:
The simple rule is that inheritable ACLs take effect only when a file is created, not when it is moved or renamed.
Copying creates a new file, which means that inheritable ACL properties of the destination folder do take effect.
However Moving a file within the same volume doesn't create a new file, therefore the ACLs remains unchanged.
Note: Moving a file to another volume does create a new file, as it requires a Copy and Delete operation.
When a file is copied, none of the attributes from the original file are kept on the copy and it also gets a new owner
All gets a bit confusing - see here: http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/
The implication of this "Update" is that the Security Permissions visible on the backup copies of the files are not important.
When the files are copied back (restored) they should automatically obtain the correct Inherited permissions.
Therefore the location of the backup folder is not causing a problem - despite the permission differences.
Navigation
[0] Message Index
[#] Next page
Go to full version