Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Dougcuk

Pages: [1]
System Info Windows 7x64 - Tweaking Registry Backup v3.3.1

Microsoft issued a faulty security update (KB3097877) earlier this week
- which caused lockups when using certain applications
- primarily it affected Microsofts own product Outlook
- but a number of other software products were also affected

It would appear that Registry Backup (seen with v3.3.1) was affected
It is also posssible that other applications could also be hit

The symptom is that the program freezes when the mouse pointer approaches window control icons at the top right
- the new fancy rotating icons "_" and "X" for Minimize and Close the application window
I also observed a freeze when I opened the Edit Program Colours popup window
- in both cases the icons freeze mid-rotation and nothing responds   

Luckily I realised that it was very likely the faulty update
- as I had only installed it shortly before the program started to freeze

Microsoft have reissued a fixed version - with the same number
- just run Windows Update and collect your fixed version   
- it solved the problem on both my Win7 systems

Original report

Note about reissue

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

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 -,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

4 Support & Help / Registry Backup
« on: November 14, 2014, 07:08:46 am »
I have been checking out your Registry Backup utility and have a question regarding the restore operation.

I have used the ERUNT registry backup utility for many years and realized that (with Win7) it only rarely included the COMPONENTS registry file - as this hive is not normally loaded when the backup runs. I also understand that your utility includes ALL the registry files in the backup - as it uses the VSC service.

My question is does your program offer any protection or warnings about restoring the COMPONENTS registry file?
I ask this as my research suggests that in most cases restoring an older copy of the COMPONENTS registry will most likely break the Windows Update and WinSxS component store systems. The WinSxS folder and the COMPONENTS registry are inter-locked and have to be considered as an integrated pair.

You can view the discussion on this topic in this thread from the Sysnative forum

DougCuk - Tech Support Engineer - London UK

Pages: [1]