Messages

1

Tweaking.com Support & Help / Re: Registry Backup via RB v3.4.1 from within WR AIO v3.8.5 - what is sddl.txt ?

« on: April 29, 2016, 05:48:01 am »

Registry Backup v3.4 implemented a new feature - to backup (and restore) the security permissions of the registry files.
These permissions are (as you stated) saved in the SDDL.txt file - and re-applied during restoration of the registry files.

This new feature was introduced to prevent issues where Windows baulked at accessing the restored registry files due to "incorrect" security permissions. I reported a minor issue (with the user registry) under Win7 and various reports have been made about odd behaviour under Win10 - after restoration of the bare registry files. See http://www.tweaking.com/forums/index.php/topic,3865.msg27838.html#msg27838

Normally the "correct" security permissions of the registry files are inherited from the folder where they reside. These inherited permissions were not being applied to restored user registry files (system registry files were ok) - and in some cases the non-standard permissions were causing access problems for some Windows functions.

Problems only occurred when restoring from within the Registry Backup program (normal Windows start-up)   
- restoring from the Recovery Console (using the F8 Repair option) always worked correctly.
- the two restore methods use different commands to place the backup files in the correct folder locations
- the Recovery Console method triggers the default Windows behaviour to assign security permissions based on those of the parent folder.   

2

Everything Else / Re: Microsoft to Discontinue Old Internet Explorer Versions in January

« on: November 29, 2015, 07:26:47 am »

As always the devil is in the detail
I had not seen the Google notice re XP and Vista support

3

Everything Else / Re: Advice Please on W8.1

« on: November 29, 2015, 07:24:58 am »

The changes from Win8 to Win8.1 mostly affected the "New Style" (aka Metro) interface and Metro Apps
- so it is almost certain that if a classic application or utility works on Win8 it will be ok with Win8.1

Some manufacturers play safe and say Win8 (and/or Win7) is not supported for older versions of their software
- this can just be a ploy to make you purchase an upgrade or it can mean there are actually issues
- even Microsoft are guilty of this compatibility misinformation for there own applications (such as Office 2003)
- the only way to be certain is for someone to try it out
- either check yourself or look for reports by others on support forums

There is a potential risk is that malware will exploit a flaw in an older application to attack your system.
Another risk with older "unsupported" applications is that a future Windows update may break something
- not a high probability but if it happens you are then on your own as it is unlikely to be fixed

The only major change in compatibility is if you are changing from 32bit to 64bit Windows
- support for 16bit executable formats was dropped (both COM and 16bit EXE no longer function)

4

Everything Else / Re: Microsoft to Discontinue Old Internet Explorer Versions in January

« on: November 27, 2015, 01:06:11 pm »

I really doubt that Google Chrome is to be discontinued - its a flagship product and forms the base for Chrome OS.
Not sure where you would have got that information - nothing I can find and it makes no sense.
Google Chrome is dropping support for Java and NPAPI browser plugins

5

Everything Else / Re: Advice Please on W8.1

« on: November 27, 2015, 12:42:59 pm »

Been away for a few days - hence the delay in responding.

In terms of advantages of Win8.1 there are a few obvious areas:
- Support for the new full screen Apps and the Windows Apps Store
- Faster Startup (up to twice as fast) and Shutdown (up to 25% faster)
- Slightly faster performance overall (around 10%)
- Browser performance much improved (50%+) using hardware acceleration 
- Improved Battery life on laptops due to better energy saving methods 
- Upgraded Security features - more resistant to malware attacks     

I had not heard of Pokki before and having looked it wouldn't be my choice
- it may be that if its design appeals then Win8.1 would be better for you
Classic Shell replicates the traditional StartMenu interface which is my choice
- but does allow you to access the Win8 Start page at any time

The main things that annoy me about Win8.1 (once Classic Shell is installed)
- The half baked GUI, parts are "Metro" style while others are Classic style
- The random replacement of system controls with dumbed down "Metro" style panels 
- The new ribbon menus of Windows Explorer, I find it slower to access features 
- The dumbed down menu system for Internet Explorer (plus the two versions Desktop & Metro)
- Loss of some classic controls such as Manage Wifi Networks

Once you have started an application there is really little difference between Win7 & Win8
- until you trigger an external service like printing
- and a few older applications are more compatible with Win7, but most will run on either

As I said before if I had Win8.1 already installed I would likely stick with it
- but if installing from scratch my choice would be to go with Win7
- but this is really just personal preference for Classic Windows interface (stuck in my ways at 58)

GWX Control panel has been updated several times recently and is currently at v1.6.0.1
- and has just aquired an installer version in addition to the standalone exe version
- latest info here: http://blog.ultimateoutsider.com/2015/11/the-gwx-control-panel-faq-frequently.html

6

Everything Else / Re: Advice Please on W8.1

« on: November 23, 2015, 04:38:54 pm »

You say you might choose to install Windows 7 - to replace the supplied Win8.1
- but you don't explain your reasons behind that suggestion
- and it is difficult to advise without knowing your requirements and expertise.

It does take a fair amount of preparation (downloading all the correct drivers and utils) and setup time to do that conversion
- and you can run into some install problems depending on how much experience you have.

While it can be satisfying to know exactly what drivers and software you have installed the process can take
most of a day to get everything installed and updated and that is just the basic install.
Then you have all your security and application software to install and configure.

If it is just the need to be back on a familiar GUI (Desktop and StartMenu) then my advice
would be to install the Classic Shell menu replacement. http://www.classicshell.net/
For most day to day operations you can believe you are running Windows 7
- and it is only when you dig a little deeper you can tell the difference.

Windows 7 is supported until January 2020 for security updates
Windows 8 is supported until January 2023
See here: http://windows.microsoft.com/en-gb/windows/lifecycle   

I have been installing Microsoft OS's since MSDOS v3.2 in 1986 and used Windows v2 (with 286 and 386 CPU's)
I myself will be sticking with Windows 7 for as long as I can, as I did with WinXP
- but have used the Win8.1 + Classic Shell combination for many of my customers
who wanted a classic Windows system on new  hardware.

The GWX Control Panel is a must have if you want to take control of the Win10 upgrade process

7

Tweaking.com Support & Help / Re: uninstall

« on: November 20, 2015, 10:05:43 am »

You could try reinstalling the same version of Windows Repair to the same (default?) folder
- this should fix the corrupted Uninstall entry.
Then try running Uninstall on the new version,  that usually works if the Uninstall is corrupted.

8

Tweaking.com Support & Help / Re: Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: November 20, 2015, 10:01:40 am »

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.

9

Tweaking.com Support & Help / Re: Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: November 19, 2015, 09:47:54 am »

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.

10

Tweaking.com Support & Help / Re: Restore from within Registry Backup - Security Permissions problem - Win7

« on: November 16, 2015, 04:52:01 am »

I will update this thread with a solution once we have one.
Meanwhile you can follow the discussion here: http://www.tweaking.com/forums/index.php/topic,3830.0.html

11

Tweaking.com Support & Help / Re: Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: November 16, 2015, 04:48:46 am »

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

12

Tweaking.com Support & Help / Re: Programs Crashing

« on: November 16, 2015, 03:31:20 am »

Unfortunately Microsoft (as far as I can find) have not released any technical details on their analysis of the problem or what they did to fix it. But at least for Registry Backup the re-issued KB has fixed the problem.

The crashes with Outlook related to displaying complex emails containing specific HTML and image data - and the other main problem was the blocking of Windows login for those connected to domain networks.

KB3097877 was intended to patch flaws that allow attacks to be remotely executed on code by exploiting the way Windows handles display fonts. The KB appears to have updated two main files Win32k.sys and Gdiplus.dll

13

Tweaking.com Support & Help / Re: Programs Crashing

« on: November 13, 2015, 06:52:33 pm »

I posted the warning about KB3097877 as I encountered problems with Registry Backup
I suspected that whatever code libraries Shane uses were probably common to many of his creations
- and so other applications could also be affected

While Registry Backup appears fine with the re-issued KB installed
- it is possible it doesn't fix all the problems for other Tweaking.com applications

It can be difficult to tell whether you have the new version of KB3097877
One way is to open Windows Update and select "View update history"
KB3097877 should appear twice the second one being dated 12-Nov-2015 or later

or you can try doing a search in the Windows folder for KB3097877*.cab

On my system I find two files both named:  windows6.1-kb3097877-x64-express.cab
- the file name will vary depending on whether you have 32/64 bit version of Windows
- but you should see two different "Date Modified" dates
The first shows Modified date         21-Oct-2015  - original release
The second shows Modified date   12-Nov-2015  - re-issued release

14

Tweaking.com Support & Help / Faulty MS Update KB3097877 - Causes Tweaking.com program freeze - Win7

« on: November 12, 2015, 09:57:40 am »

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 Tweaking.com Registry Backup (seen with v3.3.1) was affected
It is also posssible that other Tweaking.com 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
http://www.infoworld.com/article/3004519/microsoft-windows/kb-3097877crashes-outlook-causes-network-sign-in-black-screens.html

Note about reissue
http://www.infoworld.com/article/3004441/microsoft-windows/microsoft-surreptitiously-reissues-botched-patch-kb-3097877-for-windows-7.html

15

Tweaking.com Support & Help / Re: Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: November 11, 2015, 05:26:44 am »

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.

16

Tweaking.com Support & Help / Restore from within Registry Backup - Security Permissions problem - Win7

« on: November 09, 2015, 11:59:46 am »

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:
http://www.tweaking.com/forums/index.php/topic,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:  http://www.tweaking.com/forums/index.php/topic,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.

UPDATE:
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

17

Tweaking.com Support & Help / Re: Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: November 09, 2015, 11:04:09 am »

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.

18

Tweaking.com Support & Help / Re: Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: November 07, 2015, 07:06:22 pm »

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.

19

Tweaking.com Support & Help / Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: November 06, 2015, 01:29:09 pm »

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.

20

Tweaking.com Support & Help / Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: November 06, 2015, 12:19:30 pm »

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

21

Tweaking.com Support & Help / Event ID 1542 - Customize Notification Area Icons fault - Win7

« on: October 31, 2015, 05:33:25 am »

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

22

Tweaking.com Support & Help / Re: Registry Backup

« on: November 14, 2014, 08:00:12 am »

I don't pretend to understand all the possible issues when restoring the COMPONENTS hive - but from the answers in the thread I linked it would appear that any updates to the Windows system files could be a potential problem.

The most likely problem situation would be a patch Tuesday update having occurred since the backup was taken.
The other possibility might be a Visual C++ or Net Framework update installed as part of  another application.
All of these will install new files and data into WinSxS and update the COMPONENTS registry. 
I suspect that both could result in problems that might be difficult to fix - but I am no expert on this topic. 

A corrupted COMPONENTS registry file will not normally stop windows from booting or running.
You will only know you have a problem when installing an application or running Windows Update fails.

The safest option when restoring the registry might be to default to keeping the existing COMPONENTS registry file
- as it potentially matches the WinSxS folder and gives the best chance for a functioning system
- and offer the restore of COMPONENTS as a user selected option with warnings.

The staff over at Sysnative.com specialise in analyzing and fixing Windows Update and Component Store corruptions
- so it might be good to ask them for some guidance. My existing thread might be a good starting point
- if you want to clarify the best way to proceed. 


 

23

Tweaking.com 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 
http://www.sysnative.com/forums/windows-7-%7C-windows-vista/11691-restoring-a-backup-of-the-components-hive-what-are-the-issues.html#post85579

DougCuk - Tech Support Engineer - London UK