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.

[Dougcuk]

I have now isolated the step that causes the problem - Restore from within Tweaking Registry Backup

As my findings reveal a specific issue with the Restore process I will start a new thread to report this issue
You can find this thread here: http://www.tweaking.com/forums/index.php/topic,3865.0.html

The summary of the Restore issue are posted below   

When Restoring the registry from within the Tweaking Registry Backup program:
The restored files ONLY show <not inherited> Security Permissions
- they have not obtained the expected Inherited permissions of the parent folder
- they do not have an explicitly named "current user - Full Control" permissions entry
 
When Restoring the registry using "dos_restore.cmd" from the Windows Recovery Console:
The restored files ONLY show inherited Security Permissions obtained from the new parent folder
- this is what is expected for files that have been Copied to a new folder
- the restored files have the correct Security Permissions - including "current user - Full Control"

Microsoft state that Copying a file causes the destination file to be allocated a new set of Security Permissions which it inherits from the new parent folder - whereas if you Move a file (within the same volume) it retains its original Security Permissions. Therefore using a Copy command to restore registry files should reinstate the original (and correct) Inherited Security Permissions to the copied files automatically - regardless of any (incorrect)  permissions visible on the backup versions.

However when restoring registry files from within Tweaking Registry Backup the restored files do not exhibit the Security Permissions of a file that has been copied. That appears to be the area that requires investigation -  as the altered permissions  could cause other issues in the future if not corrected.

[Shane]

Great research 

Ok, so when you use the bat file to restore this uses the simple copy command. When doing a restore from the program it uses the move file at boot api. While restoring the main registry files uses the regload api. One thing is for sure, the API that is used can have different effects.

So there are a few ways we can go about this for a possible fix.

1. Update the program to export out the permissions of the registry hive files and save them with the backups (I can do this with my ManageACl program I use in the Windows Repair), then when restoring the registry it then restores the permissions of the files when they where backed up.

2. Keep things as they are but update the program to add back certain permissions.

Personally I am thinking backing up the permissions is the best way to go, that way any custom permissions on the files a user might do will get backed up as well.

Thoughts?

Shane

[Dougcuk]

First just a few points to note:
So far the ONLY confirmed Security Permissions problem is with UsrClass.dat on Win7
There is one other thread reporting UsrClass permissions problems on Win10 - which maybe totally unrelated
The altered Security Permissions appear on all restored files - but do not appear to be a problem elsewhere.
However a generic fix is likely the best option - to avoid upsetting any other badly written MS code.

The "Move file at boot" api is most likely involved in creating the UsrClass permissions issue
However as I proved above even when the backup version of UsrClass.dat has the correct (inherited only) permissions
the current restore process zeros these - and ends up with ONLY generic non-inherited permissions.

The restore can't involve a simple Move directly from the backup location folder
- or you would loose the files from the backup folder after a restore
- and it would transfer correct permissions if those existed on the backups (which it doesn't)
If the "Move at boot" is really a "Move" (which also "moves" permissions) where are the files moved from?
Is there no equivalent "Copy at boot" that might trigger the automatic restoration of Inherited permissions? 

Somehow ERUNT restores registry files (including UsrClass) with ONLY automatic Inherited permissions
- and it initiates this from within Windows and completes using a reboot (just like your program)
I am not sure how it achieves this but my test show that:
- it doesn't just replicate the permissions of the backup files
- it doesn't involve setting any fixed (non-inherited) permissions   
- it doesn't involve a backup of the original permissions
It appears to make use of the automatic Windows default to apply Inherited Permissions on copied files.
So it must be possible for "restore files at boot" to behave as if the registry files have been Copied back.

So I am not entirely sure the fix REQUIRES any extra data - i.e. backing up existing permissions

The simplest solution would be to cause Windows to apply the default Inherited permissions of the destination folder.
This is what the current restore from Recovery console does and also what ERUNT appears to do.
Both are well tested and do not appear to cause issues.

I suppose in very rare cases someone might have set custom permissions on User registry files
- in which case the only way to preserve those would be to backup and restore permissions 
- but I rather think if someone had done this they could reset them if required.

I think I would go with the simplest solution - least chance of future problems

As far as programming options go - I am not sure what exists 
- but obviously something simple must exist or ERUNT couldn't do what it does.

[Shane]

The hard part is restoring files that are currently in use.

So for the main registry files MS gave this api command - RegOpenKeyEx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724897%28v=vs.85%29.aspx

But it doesnt work on the user profiles, I made this years ago and I cant remember why, but I had to find a way to replace the user profile registry before it was loaded. So I use the MoveFileEX function, since it will move the registry files before they get loaded. I only use this API to restore the user profile registry

Here is the API and I use the "MOVEFILE_DELAY_UNTIL_REBOOT"
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240%28v=vs.85%29.aspx

Reading down the page I found this

If a file is moved across volumes, MoveFileEx does not move the security descriptor with the file. The file is assigned the default security descriptor in the destination directory.

Thing is, it isnt being moved across volumes, the backup is on the same drive.

The reason the program copies the backup to the windows temp folder first is in case the backup is on a different drive because the regopenkey api will fail and not allow registry files from a network or another drive.

So it is also possible that the file copy api I use to copy the files to the temp folder may not carry over the security as well.

If that is the case it does seem the easiest route to take is to backup the permissions with the files, that way if the permissions ever get changed to anything in the backup the proper permissions can still be restored.

Shane

[Dougcuk]

There doesn't appear to be a CopyFile_Delay_Until_Reboot command - so let us analyse what we do have.

OK so the User registry files are copied to the main Windows TEMP folder first
This COPY operation will reset all permissions on the files - because new files are being created
- the files will be allocated the generic inherited permissions from that TEMP folder
- this means they will have no "Current User" entry for the User Profile they really belong to

Assuming the "MOVEFILE_DELAY_UNTIL_REBOOT" obeys the permissions rules for a "File Move"
- that is the permissions are carried with the file (because it has not been created just moved)
- then this is the step that carries the generic permissions from the Windows\Temp folder to the User folder
- so the User registry files  are restored without a "Current User" entry - which is the problem. 

When copying the User registry files is it possible to use a different TEMP folder?
- one inside the C:\Users folder tree
- the most obvious one would be C:\Users\All Users\TEMP

I believe this should create a flag for inherited permissions which includes the "Current User" entry
A basic test moving files between User folders shows that the inherited "Current User" entry
gets translated to the correct named user for the User Profile folder you move the file to - which is what we require.

The critical step is always the last MOVE command it must be moving files from a location where they have
the correct inherited permissions flag which includes a "Current User" entry
- the main Windows TEMP folder doesn't fulfil this need - a Users TEMP folder appears to provide this.

I think it would be worth testing this idea before going to the trouble of coding the backup/restore of permissions
- and if it works you will be replicating what restore from Recovery Console and ERUNT already do - both tried and tested solutions.
A number of things need to be true for this solution to work:
- you would need to be able to specify which TEMP folder is to be used - sounds likely
- and the C:\Users\All Users\TEMP folder would need to be available to the system early in the boot sequence
- and my theory about the translation of the "Current User" flag needs to be correct

Anyway have a think - this might be the quickest and neatest solution - without inventing extra work.
Live Long and Prosper - Doug

[Shane]

CopyFileex API is used
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363852%28v=vs.85%29.aspx

Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP:  Security resource attributes (ATTRIBUTE_SECURITY_INFORMATION) for the existing file are not copied to the new file until Windows 8 and Windows Server 2012.

The security resource properties (ATTRIBUTE_SECURITY_INFORMATION) for the existing file are copied to the new file.

The program doesnt set the ATTRIBUTE_SECURITY_INFORMATION flag, didnt even realize it  had that flag lol.

So I will set that flag on it, but I still think the best option is to start backing up the permissions with it (To a separate file with the permission info) and then when it is restored the program will set the permissions back using my ManageAcl tool.

The reason I like this is because if the backup folder ever had its permissions changed then it would change the backup files as well and so restoring would still have the same problem or worse if the permissions where copied with it, then got changed by something and then restored with those permissions and they where set to deny or something.

So to keep something like that from happening I can backup the permissions info to a text file and restore them. So far that is my plan, that way the permissions stay proper on the files AND it covers if the permissions ever get changed by another program or user in the backup itself.

Shane

[Dougcuk]

Well it's your choice - re backing up the permissions - just seems to be solving a problem that doesn't really exist
- but your solution will obviously work.

The ONLY problem step we have is MOVING the files from a non-user TEMP folder which transfers the wrong permissions.
And as I pointed out the restore from the Recovery Console and ERUNT both work perfectly
- both making use of the default inherited permissions behaviour of Windows.

With my solution any "messed up" permissions on the backup versions wouldn't be an issue 
- as these would get reset when the files are Copied to the Users TEMP folder

With your solution my only worry would be that if someone messed up file permissions
and then did a backup then these incorrect permissions would be perpetuated
as the permissions would never be reset to the correct defaults.

Neither solution can protect from all possible "self inflicted " permissions screwups.

Just a couple of closing notes:
The COPY command was designed NOT to set attributes - that has always been its default behaviour.
The copied files collected their inherited permissions from the destination folder.

Re the documentation for the CopyFileEx ATTRIBUTE_SECURITY_INFORMATION flag
- it appears to say that this flag is not available in Win7 only for later Windows versions   
- so you would need workarounds for XP, Vista and Win7 if you started to rely on that.

[Shane]

No matter on what i decide to do on the update for it all i know is I havent looked at the restore code since I first made it, so I think it will be time to relook over all of it and see if I can find any better way of doing things.

This might explain why erunt defaulted to backing up the registry to the Windows folder.

The big problem is how the APIs in Windows can be a pain in the butt. One APi may do the job but it doesnt doing something that is needed, or you find another APi to do it but it is only supported in newer versions. Then there is the APIs that work fine but where removed in newer versions of Windows.

Big pain in the butt. But when I made the restore it was before Windows 8 and was aimed XP and 7. So time to see what new APIs I can use and just have to put in code to use the different APIs for the different version of Windows. That and also backing up the permissions. I think I may end up going with a combo type of fix lol

Shane

[Dougcuk]

Well it seems you have your heart set on backing-up the permissions data
- I will view it as another extra feature over and above what ERUNT can do.

But I was curious as to how ERUNT manages to restore the User registry files successfully
- with all the correct permissions, and independent of the backup folder location
- initiated from within Windows, without any extra data.

I know ERUNT can do this trick with the User registry files up to and including Win8
- and it only uses the API's that were available in Windows XP (2005)

Tests show that ERUNT copies the User registry files in one step BEFORE the reboot
- it doesn't make use of any TEMP folder when restoring the User registry files
- the existing "live" files are copied to .bak versions alongside the originals
- the selected backup versions are Copied over the existing "live" files
- all while the current user is still logged on to that user account
- you MUST then reboot (which is prompted) or the User Account can be damaged.

ERUNT must restore the User files using elevated privileges of some kind (SYSTEM?)
- to allow it to copy the two User registry files with that User account still open
- plus maybe some other trick to stop Windows overwriting the restored files at shutdown 
 
FYI - my guide to configuring ERUNT for Win7 has been online for many years now
-  posted on my server here: http://www.stargateuk.info/upload/ERUNT_Tweaks_Win7.txt

Note: The only reason ERUNT originally defaulted to backing up inside the Windows folder
was that this was the only folder location guaranteed to be accessible from the XP Repair console
In early versions of XP you had to set a registry key to unlock other folder trees during Repair.

[Shane]

Erunt may be using different APIs to get the job done, I should grab the last version that was done of it and see if I can sniff out the APIs it is using and i can at least research them.

Shane