ACLs on UsrClass.dat messed up after restore

[indrawn]

I updated to Win10 Pro x64 recently. Last night, I used Registry Backup 3.1.0 for a restore for the first time since updating to Win10.

After the restore and reboot, lots of stuff was messed up. I discovered that HKCU\SOFTWARE\Classes wasn't being loaded. After looking into it further, I noticed that the ACLs on the newly-restored UsrClass.dat file under my profile were incorrect. My own user account did not have access to UsrClass.dat, so that hive could not be loaded when I logged in with my account after the registry restore.

I corrected the immediate issue by logging in with another account and manually copying the UsrClass.dat file from the registry backup folder to "C:\Users\UserName\AppData\Local\Microsoft\Windows" (where "UserName" is the ID that had the problem). This resulted in proper ACL setup, and I didn't have any problems.

I tried the restore two more times, and the UsrClass.dat problem happened each time. No other users were affected by this; only mine, the one that ran the restore.

[Shane]

That is an odd one. The registry backup grabs the hive files themselves. If you do the fallback backup method then it calls the regsave api to have windows save the registry to the files in the backup.

Then the restore is the regload api to tell windows to load these reg files at next boot. So the restore doesn't touch anything in the backup files.

I am wondering if the reg_save api had trouble with saving it?

I also just released windows repair v3.4.2 where I have redone how the permissions are done, which should fix any permissions problems.

But I am curious to how the acl is messed up in those files.

Try this, open regedit and then click on hkey_local_machine now go to file and load hive. Load the hive from the backup folder C:\Users\UserName\AppData\Local\Microsoft\Windows
Give it a name and then it will be loaded in reg edit, once that is done you can go check the permissions of it there. Once done make sure to unload the hive file.

Let me know what it shows when you check the permissions.

Shane

[indrawn]

Sorry but I can't deal with this anymore ... The "this" is Windows 10. I'm washing my hands of it and restoring the Win8.1 image I THANKFULLY created before installing this crapfest. I am writing this issue up to "Yet Another Win10 Issue" along with a BSOD, a Start menu that doesn't work, weird sound/video issues, weird error messages, freezes, and a litany of other life-robbing frustrations.

Thanks and I'm sorry to have taken your time.

[Shane]

No problem at all. While 10 has promise, it was rushed, there is no doubt about that. So if 10 doesn't have a perfect environment, then it goes to crap town fast lol

Shane

[indrawn]

I went back to Win8.1 and then decided to give Win10 another try... Long story...

Anyway, I have a new install of Win10, just did my first restore with RB 3.2.0, and again I'm having the issue I mentioned in this post.

I followed the steps you mention. I did it for ntuser.dat (which as far as I know has no issue being restored), and UsrClass.dat (which is the one I'm having issues with). Here's what I see for the registry permissions on the respective hives:

ntuser.dat:

ALL APPLICATION PACKAGES: Read
RESTRICTED: Read
SYSTEM: Full Control
My user name: Full Control
Administrators: Full Control

UsrClass.dat:

ALL APPLICATION PACKAGES: Read
RESTRICTED: Read
SYSTEM: Full Control
My user name: Full Control
Administrators: Full Control

For the UsrClass.dat file itself (i.e. the NTFS permissions), the ACLs are:

SYSTEM: Full Control
My user name: Full Control
Administrators: Full Control

I don't see a problem here.

[Shane]

Thats the thing, registry backup gets the whole file and the restore is the seem, it calls the RegLoad api and tells windows to use this file, and thats it. nothing is written or changed in the registry file itself.

So that means that if the file itself is getting the wrong permissions and it isnt the registry keys, then you need to look at inheritance. Files that are put into a folder, either by being created or moved get the permissions of the parent folder.

Also in the registry you can look up the hive list location and see exactly where the classes hive is being pulled from, that way we can make sure it isnt simply trying to pull from the wrong place.

Shane

[indrawn]

But as I mentioned in the first post, when I manually copied the UsrClass.dat file, the permissions were fine:

I corrected the immediate issue by logging in with another account and manually copying the UsrClass.dat file from the registry backup folder to "C:\Users\UserName\AppData\Local\Microsoft\Windows" (where "UserName" is the ID that had the problem). This resulted in proper ACL setup, and I didn't have any problems.

I also created a test file in "C:\Users\UserName\AppData\Local\Microsoft\Windows", and its permissions match what I (and other users on my system) have for UsrClass.dat. The one difference is that on UsrClass.dat, the owner is "System" and on the test file, it was my own user ID.

[Shane]

The api I use to restore the registry is this one
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724913%28v=vs.85%29.aspx

I checked on a fresh install of Windows 7 with all updates in vmware. No backups or restores done, so this is a untouched install.

When i check the owner of "C:\Users\UserName\AppData\Local\Microsoft\Windows" it is the user account that is the owner, when I checked UsrClass.dat inside that folder "System" was the owner of the file. Then the only 3 accounts on it for permissions where "System" "Administrators" and the user account it self, all 3 where set with full permissions.

When you copy the file into that folder yourself it is getting the owner and permissions from the parent folder, which is why you are seeing the user account as the owner.

So now I am asking myself, "if System is the default owner of the file, then why isnt his system able to load it?"

Shane

[indrawn]

Yeah, I know what you mean. Sorry, I can only report what I see.

I checked in the backup location, and the owner of UsrClass.dat is System, and the other perms look fine.

I installed another registry backup utility, and I'm going to see if this issue happens with that one too. I think it will. I'll post back.

[Shane]

Let me know what you find.

Also if you havent yet, run a normal chkdsk on your drive

chkdsk c: /f

Part of the steps of check disk is to verify and repair the security descriptors, which is what the ACL is in. Lets make sure it simply isnt something goffy with it

Shane

[indrawn]

I ran chkdsk two times on C: (once with /sdcleanup and once without), and no problems were reported in the event log.

I just restored with the other utility (RegBak 1.5), and it seems to have worked fine. No classes issues at all. This is meant as info and not as a middle finger. I realize you owe me nothing.

Thanks for your time.

[Shane]

I don't take it as a middle finger at all

I am actually very very curious. I restore the registry with RB constantly on my test machines, from xp to 10 and never had any trouble with it loading, yet on your system we do.

So that means there is a unknown variable at play, we just need to find out what it is

So lets cover all the quick stuff first.

Answer these for me, if I already asked them before I am sorry, been up going on 72 hours trying to get caught up and if it wasn't for spell check this wouldnt be working lol

1. Where do you have the registry files being backed up to? What folder path? (Goal here is to see if a odd file path might be causing a unknown bug)

2. When you used the other reg program, did it restore from the registry files that RB took or did it back up its own and restore those? (Goal here is same as the first one and knowing if the program that had success had a different backup path)

3. If the other program used its own backup, what is the folder path they are stored at? (Goal is same as #2)

4. With RB have you tried restoring backups that where done with VSS and another with fallback? (Goal here is to find out if it is the way the registry file is being saved is the cause, of course you said you could restore the files manually with no problem)

5. What are the permissions problems exactly, is it that system is the owner and so when you boot it fails and setting it to you lets it work? (Goal here is I have seen bugs where the system account doesnt have admin privileges anymore because of a corruption somewhere, adding system to the administrators groups fixes it, my Windows Repair does that before starting the repairs)

Lets go with that info first and see what direction it points us

Shane

[indrawn]

1. My base backup folder was "D:\Backups\Registry Backup". This is a separate HDD, with Windows running on C:. Of course, the computer name was added to that path.

2. RegBak restored its own backups, which had the same base directory, except that it doesn't (as I have it configured) add the computer name; it adds a date directory (e.g. "2015-09-18") and under that a time directory (e.g. "10;14 AM").

3. Oops, already answered that one.

4. No. I only ever used VSS. Too paranoid to use fallback, ever.

5. Good question. I wish I had been more specific in my first post. I had to look at my own description of the problem, which was simply: "My own user account did not have access to UsrClass.dat." I should have listed the ACLs. [SIGH] Right now my system is in what I call a "State of grace" and I'm loathe to mess with it. But this never lasts long (Microsoft sees to that). So next time I have to mess around, I will look at exactly what the issue is. Sorry I can't be more specific on this one.

I did just try something, though. I backed up my ID's UsrClass.dat using RB and RegBak, as closely as possible in time. I thought the files backed up would be identical, but they're not. I see two bytes at the very beginning of the file that differ. I retried and the same was true again. No more detail as I assume this is just because of the file being updated normally by Windows.

But another difference was that RB had no attributes for UsrClass.dat turned on, other than the "c"ompression bit. RegBak saved UsrClass.dat with "a"rchive, "h"idden, and "c"ompression. Now that I've typed that, I can't see why it would matter.

The ACLs on both saved UsrClass.dat files are identical, though, including the owners (Administrators).

[Shane]

1. My base backup folder was "D:\Backups\Registry Backup". This is a separate HDD, with Windows running on C:. Of course, the computer name was added to that path.

Ok good, I ask because the Windows API is very picky about restoring the registry from another drive. So RB will copy the reg files to the windows temp folder first and have the API pull it from there.

2. RegBak restored its own backups, which had the same base directory, except that it doesn't (as I have it configured) add the computer name; it adds a date directory (e.g. "2015-09-18") and under that a time directory (e.g. "10;14 AM").

Should be ok since RB copies the files to the temp folder. One thing we will have to check is if anything is messing with RB when it is copying the files.

4. No. I only ever used VSS. Too paranoid to use fallback, ever.

All I use is fall back, a lot faster and never once had any trouble with it. In fact i find that things are better with it, mainly because the registry is a database. Just like any other database it gets overhead and slows down. Only way to clean that up is to write it out to a new file, just like any other database. The whole system will end up being faster because of it, if the registry overhead was causing a slow down.

Fallback option calls the Old School Windows API just like Erunt and the others to write the registry to new files. So you will notice they will always be smaller than the ones in the system32\config folder.
MS says they prefer to use VSS because of volatile registry keys. But that seems to be more server related as I havent ever found a workstation that had a program running that was using volatile registry keys. In fact I dont know of any programs that do lol

(Firefoxes spell check is a total joke, the words it misses is insane)

5. Good question. I wish I had been more specific in my first post. I had to look at my own description of the problem, which was simply: "My own user account did not have access to UsrClass.dat." I should have listed the ACLs. [SIGH] Right now my system is in what I call a "State of grace" and I'm loathe to mess with it. But this never lasts long (Microsoft sees to that). So next time I have to mess around, I will look at exactly what the issue is. Sorry I can't be more specific on this one.

I did just try something, though. I backed up my ID's UsrClass.dat using RB and RegBak, as closely as possible in time. I thought the files backed up would be identical, but they're not. I see two bytes at the very beginning of the file that differ. I retried and the same was true again. No more detail as I assume this is just because of the file being updated normally by Windows.

But another difference was that RB had no attributes for UsrClass.dat turned on, other than the "c"ompression bit. RegBak saved UsrClass.dat with "a"rchive, "h"idden, and "c"ompression. Now that I've typed that, I can't see why it would matter.

The ACLs on both saved UsrClass.dat files are identical, though, including the owners (Administrators).

The program calls VSS to make a shadow copy, then it maps that copy to a drive letter and then calls the FileCopy api in windows and tells it to copy the files to the backup folder. I dont make any calls to read or set the permissions on the file or the flags set just as compressed or hidden or anything. It lets the Windows API handle it.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363852%28v=vs.85%29.aspx

On that page you will see that it has a Flags options, the only flag my program calls is "COPY_FILE_RESTARTABLE"

Also relooking at the page I found this about the file security. But again this is for the security of the file itself and not the permissions of the actual registry keys

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.

So that means that when the file is copied it gets the permissions set by the parent folder.

In fact I find it odd that the file was marked as compressed, it shouldn't be, unless you compressed your whole drive. I wonder if that is the unknown variable I have been looking for.

I never compress my drives, slows everything down. If your drive isnt compressed then why is he registry file marked that way?

Shane

[indrawn]

Sorry, I meant to mention that I have the backup directory compressed. Not the whole drive, just the dir. This is a new thing though. When I started seeing this issue, I didn't have the dir compressed.

Obviously, then, the "c" flag is appropriate. Nothing wrong here. Can't see why the "a" flag would matter. Not sure why the difference in "h" flags, though.

Thanks. Please get some sleep!

[Shane]

Well until we cant test a few things out we wont be able to get to far.

So when you are feeling up to it let me know

First thing I would have you do is run a single repair from my windows repair program so that it adds system to the administrators group. Then I would make sure you have something you can boot off of that will allow you to easily copy the reg file back over if we have any trouble.

Sleep, sleep is nice. But with a wife, 5 kids and I am the only source of income and I have so much work to catch up on, I wont be going to sleep till tonight, if I make it. I have been doing these insane hours for almost 2 months straight, now I am finding my self staying up 2 days without trying. That cant be good lol

Shane