Main Forum > Tweaking.com Support & Help
Event ID 1542 - Customize Notification Area Icons fault - Win7
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 :cheesy:
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
--- Quote ---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.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version