Author Topic: Restore from within Registry Backup - Security Permissions problem - Win7  (Read 2269 times)

0 Members and 1 Guest are viewing this topic.

Offline Dougcuk

  • Newbie
  • *
  • Join Date: Nov 2014
  • Posts: 29
  • Location: London UK
  • Karma: 2
    • View Profile
System details: Windows7-SP1x64 + Tweaking Registry Backup v3.3.1

This thread is the end result of a complex and confusing investigation documented in this thread:,3830.0.html

To simplify things I am starting this new thread containing just the new issue I have identified 
I have posted a note on the old thread pointing to this thread - I trust that is not breaking the Forum rules

I am reporting a problem that results from the difference in the behaviour between:
Running a registry restore from within the Registry Backup program
Running a registry restore from the Recovery Console 

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 the permissions visible on the backup versions.

However when restoring registry files with Tweaking Registry Backup something odd is happening. 

When Restoring the registry from within the Tweaking Registry Backup program:
The restored registry files have slightly different Security Permissions than the originals
These 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" permissions entry

This difference in Security Permissions on the restored files appears to cause no problems - except for the one situation I encountered (there may of course be others). I discovered that Win7 refuses to load the UsrClass.dat (at account logon) when the Security Permissions do not include the "current user - Full Control" permissions entry. Full analysis of this problem is documented in my original thread:,3830.0.html

This failure to load UsrClass.dat is not immediately apparent to the user - but appears in the Application Event Log (Event ID 1542 with a Red Error Flag). However several GUI customizations are lost due to this failure to load - most notably the Customize Notification Area Icons no longer preserves changes over a reboot - and this is only rectified once the "current user - Full Control" permissions entry is reinstated on the UsrClass.dat file.

It is unclear why Win7 refuses to load UsrClass.dat as the Effective Permissions check shows Full Control for the current user, SYSTEM and the Administrators group - there  appears to be a "bug" in the Win7 account login code. However the odd behaviour of the Restore from within the Registry Backup program might cause other issues in the future if not corrected.

Copied files should automatically gain Inherited permissions from the destination parent folder
- odd things can happen when files do not have the expected permissions for the folder where they reside.

If the Restore (from within the program) is being processed in two stages this could explain the difference in permissions.
Where a file is initially Copied to a temporary folder and then Moved to its final location it will retain the permissions of the temporary folder.

Doug Collins - Computer Support Engineer - London UK
« Last Edit: November 16, 2015, 08:10:48 AM by Dougcuk »
Doug Collins - Computer Support Engineer - London UK

Offline Shane

  • Top Geek, err uh Dog.
  • Administrator
  • Hero Member
  • *****
  • Join Date: Sep 2011
  • Posts: 9279
  • Location: USA
  • Karma: 137
  • "Knowledge should be shared not hidden."
    • View Profile
I replied to your other thread about a possible idea for a fix. basically updating my program to backup the permissions as well and then restoring them.

Let me know what you think.


(My weekends belong to my wife and kids, I will try my best to answer all posts daily during the work week)

(About Shane)
Site Owner, Top Admin, Lead Programmer, Wife & 5 kids, Needs a lot more coffee.

When people ask "Why fix what isn't broken?" I reply "To make it better."
"Only a life lived for others is a life worthwhile"
Honor & Respect is all that matters.

Owner & Programmer of: &

Offline Dougcuk

  • Newbie
  • *
  • Join Date: Nov 2014
  • Posts: 29
  • Location: London UK
  • Karma: 2
    • View Profile
I will update this thread with a solution once we have one.
Meanwhile you can follow the discussion here:,3830.0.html
Doug Collins - Computer Support Engineer - London UK