Restoring a Backup of the COMPONENTS Hive - What are the issues?

[DougCuk]

I have been attempting to find ANY basic documentation about the "new" registry file COMPONENTS in Win7
- specifically what problems can/will occur when restoring an older copy of the COMPONENTS hive.

I originally asked this question in the Win7 Tutorials section - on a thread about manually restoring the registry
- but after 11 days it got no responses - so am starting my own thread.

I have a basic understanding of the original four registry files SYSTEM, SOFTWARE, SECURITY, and SAM
But I have been unable to find any real technical info about how the COMPONENTS registry file is used
- and how it relates to other parts of the Windows system.

Is there already a guide you can point me to - somewhere on this website - or elsewhere?
I did a search but could not find anything.

I regularly use a registry backup program - either ERUNT or Tweaking.com's Registry Backup
- most of my registry restores have been on XP - which doesn't have a COMPONENTS hive.
- the only restores I have done on Win7 left the COMPONENTS hive alone - restoring the other 4 hives.

The first two obvious questions are:
1. What is the connection between the COMPONENTS registry file and the WinSxS Component Store?
2. When manually restoring the registry from a backup the original 4 files are well documented
- but what issues need to be understood when considering a restore of the COMPONENTS registry file.

And once I understand that one then I believe Win 8 introduces a number of additional files - including DRIVERS ????

DougCuk - Tech Support Engineer - London UK

 

[niemiro]

Hello, and welcome to Sysnative!

I'm very sorry about our late reply. Not that you knew it at the time, but this is really a question aimed at Windows Update specialists, and since this wasn't in the Windows Update forum because you didn't know that that was relevant, it went under our radar. I'm sorry for that.

Anyway, as I've hinted at above, the COMPONENTS hive - first introduced in Windows Vista, but tweaked several times over various Windows versions and service packs since then, holds a large amount of data associated with Windows Update configuration & status.


It's not considered a boot critical hive - and your computer will usually appear to function correctly even if it's corrupt/damaged/wrong/whatever (although if you do some very specific messing around with the reboot flags & update installs pended over reboot you'll probably be able to stop your computer booting into anything other than Safe Mode, but usually we consider it a non-boot critical hive. The trouble is that altering it in any way can severely mess up your Windows Update configuration, and you'll likely not be able to install or uninstall updates or Windows Features, and perhaps even some Windows Installer based programs if you're really unlucky.

For this reason, I strongly advise against using backups where at all possible. If you haven't install any updates (or had any installed silently alongside other programs etc.) since the backup, you'll probably be fine. If, however, you try to restore an old hive from before the last patch Tuesday, or worse, from another machine (which you should never, ever do - different program configurations which bundled different versions of different updates, different hardware --> different driver updates, whether or not the machines installed IE10 over the top of IE8, or over the top of IE8 and IE9 - all subtleties which make a massive difference), who really knows what will happen. Usually you'll just get an error if you try to use Windows Update, but it's worse if it tries to install updates it shouldn't do on your machine & puts your Windows folder out of kilter, or fails to offer you necessary security updates because it thinks they're already installed.

You could argue I'm scaremongering here - and in a way I am, because I'm highlighting the worst case scenarios. The trouble is that I've worked Windows Update issues for very many years, and I've seen many times where people try to be clever and copy a COMPONENTS hive from another computer, and it fixes they're Windows Update problem! Great! But somewhere deep down things are out of sync, and then everything goes belly up next patch Tuesday. Or the one after that.

Basically, the COMPONENTS hive needs care because incorrectly altering it often, in the best case scenarios, leads to no immediately apparent problems. But you've just set a time bomb for some particular update Microsoft will eventually release to touch an out of sync component & mess everything up.

Does this sort of help? Any more questions? I'd be very happy to answer them to the best of my ability :)

Richard

 

[DougCuk]

Thank you for your answer.
I knew there were people here who understood the function of the components reg file
- I've seen it discussed and repairs made often enough on the various forums sections here.

My original un-answered posting of the question was in a Tutorial thread about manual registry restores
- Link: https://www.sysnative.com/forums/wi...indows-windows-7-windows-vista.html#post84686
Which seemed like a good place to ask the question about restoring a registry hive.
It might be good to repeat any advice on that thread - once we finish here.

There is no way I would even consider restoring a registry file from a different computer - so that is one senario we can ignore.
I've fixed a few weird things in my time including a Windows installation where someone had moved the Program Files folder to the D: drive
- leaving the Windows folder on C: drive - now that was creative to say the least.

A few points (numbered to make any responses easier) that I would like some feedback on
- just to make sure I understand the basics.

To clarify a few things about the COMPONENTS reg file:
1. I assume the WinSxS folder and the COMPONENTS hive/reg file are interlocked and need to match each other?
2. Is the COMPONENTS reg file connected to any other parts of Windows Update - like Software Distribution?
3. Does Windows System Restore successfully restore both WinSxS and COMPONENTS as a matched pair?

And on the topic of manual registry restores - are you happy with these statements:
4. Do not include the COMPONENTS hive when restoring the registry - without serious analysis of any sources of OS updates.
5. If the COMPONENTS reg file is damaged then attempt to get it repaired rather than restore an old copy.
- as asked in 3 above - can System Restore help with this type of repair or not?

And finally:
6. Are there any remaining issues to be considered if you manually restore the other main registry files and keep the existing COMPONENTS reg file?

I think that should do for now - many thanks for your time.

DougCuk - Tech Support Engineer - London UK

 

[niemiro]

There is no way I would even consider restoring a registry file from a different computer - so that is one scenario we can ignore.

Excellent! Having worked on forums for very many years, I've seen an awful lot of things - so I tend not to take anything for granted any more. Please forgive me for that. Specifically, I've seen a lot of people who find out that their son/daughter's Windows Vista COMPONENTS file (hive) is corrupt, so go next door to the Windows 8 study computer & copy it across. Or who grab it from a backup from years ago. Or who grab one off the internet. The error code at this point has changed, so they admit defeat & come online for help. Or they run the System Update Readiness Tool & it attempts repairs on 5000 errors. And then they seek help.

Here, we're really careful about this. We supply all of our fixes with strong warnings, we often take down fixes or supply COMPONENTS hives privately, and we always rebut or delete advice to replace COMPONENTS hives from *wherever*. But we can't control the whole internet, and often these people get these recommendations off other websites

[For what it's worth, curiously enough, this fix is performed by a very disproportionately high number of system administrators. It's rare for us to find a home user who has done enough digging to come up with this, then has enough knowledge to trash the permissions & ownership designed for system protection on that file, and then replace it. Usually home users are very easy to work with because they just follow our instructions. It's the system admins who insist on jumping ahead at every little step of the way who are the most difficult to work with. They tend to be the ones who, seeing us working on the COMPONENTS hive, go and replace it from an old backup/initial disk image, damaging permissions & ownership in the process. Then they run the System Update Readiness Tool (which then propagates the inconsistencies everywhere), followed by a whole bunch of Windows Update troubleshooters (which often end up deleting lots of temp file evidence), followed up by CCleaner for good measure - which deletes the logfiles too. We always do our best to collect, catalog and store this information in the first post whilst working a thread so the data isn't lost if a user deletes it, but these threads are the hardest (and often impossible) to solve. Plus they often just go and reimage the system half way through the fix. Sysadmins ]

Anyway, it's really refreshing to find a Tech Support Engineer who is both knowledgeable, cautions, and stops & applies common sense before diving in headfirst. :)


As another aside, we also get the odd user here who wants to move the Program Files folder. It's mostly when that user has a small SSD as C:\, a large HDD as D:\, wants programs on D:\, but doesn't want to have to keep changing installers to point to D:\, and instead leave them at C:\ with the files ending up on D:\. I can definitely see the attraction, having a small SSD as C:\ myself. Microsoft have always been very clear that moving Program Files by changing just the environment variable is not going to end well - not just with 3rd party apps, but also with a couple of core Windows components having technical limitations which force them to remain in Program Files, and on C:\. Others try using an NTFS junction. This is a better bet, but there are still issues. All in all, it's not something I either recommend or use, although there can be partial success if junctions are used. But it's risky.

Anyway, let's (hmmm. "let us" is probably unfair here. "let me" is surely better!) actually get back on topic now.

---

1. Yes. Really, absolutely everything everywhere is interlocked. What I'm about to show you is an extreme oversimplification, but perhaps it will give you a better idea of what you're facing:

COMPONENTS\DerivedData\Component\ keynames match winsxs directory names. Well, some of them. There are some extra keys in here which don't have winsxs directories. Really though, it's more accurate to say that they match winsxs\Manifest files names. Then the S256H value data is the SHA256 hash of the manifest. The f! key value data lists files under each winsxs directory (those keys which have no f marks - no files - have no winsxs directory - otherwise it would be an empty folder). The c! values link through to COMPONENTS\Catalogs\, which contains thumbprints which link into Windows\servicing\packages folder.

All of these then link into SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ and SOFTWARE\Microsoft\Windows\CurrentVersion\SidebySide keys.


Manifest file contents then link into everywhere else - they document system files, registry keys, services, etc. everywhere. The .cat and .mum (and occasionally .ses) files then help to ensure that there isn't tampering by being external digital signature containers & related metadata containers.

winsxs directory then has projected hardlinks - files in System32 & elsewhere are really (usually) just links into winsxs.

And that's only just scratching the surface of how the system files interlink. It doesn't even begin to consider all of the hundreds - quite literally - of exceptions & oddities we have investigated and documented over the years. Little hacks here and there to make this particular device work on these particular systems which already have update x for device z installed which would otherwise cause conflicts.

But these are still only the system links - it doesn't even cover how Windows Update knows what's out of date, or how it performs replacements over reboot, or anything like that (that's where SoftwareDistribution comes in - it's part of the backend of Windows Update, not the backend of the system).


Now you might have a better idea of why attempting to replace a COMPONENTS hive, and then letting an automated repair tool like the System Update Readiness Tool run unfettered is a very bad idea.

I actually have to go out now though. I'll be back in a couple of hours to finish off.

Richard

 

[DougCuk]

Very interesting so far - looking forward to the continuation.

Just as some background I started in computers as a job in 1987 - with MS-DOS v3.2
For the first 20 years I worked in the business sector first with accounting and then dental systems.
If you screwed up it could cause havoc for the customers business - and I would be the first one for the chop if I was seen to be at fault.

So I always took the attitude that caution, analysis and backups were the most important first steps.
Luckily (or because of my caution) I never had any serious screw-ups.

 

[niemiro]

3. Does Windows System Restore successfully restore both WinSxS and COMPONENTS as a matched pair?

Yes, it does :)

System Restore is a good, safe, way of recovering from even Windows Update based issues. Restoring a complete system image is fine too, but System Restore is safe if not always reliable (I'm sure you've experienced the issue where System Restore fails to make the restoration - it does sometimes fail if it can't make the revert, but when it succeeds it will (almost) always [never and always are very strong words] leave the system in a perfectly healthy state.

4. Do not include the COMPONENTS hive when restoring the registry - without serious analysis of any sources of OS updates.

It's difficult to answer this because there's no ideal solution other than to restore absolutely everything as a matched pair (e.g. by system image or System Restore). But, from a Windows Update perspective, it's much more important for the COMPONENTS hive to be in sync with winsxs than it is for the SOFTWARE hive to be in sync with winsxs. But it's also important for the SOFTWARE hive to be in sync with everything else.

Basically, what I would say here is to choose the COMPONENTS hive that matches most closely with winsxs, not the one which matches mostly closely with the SOFTWARE hive.


One way to assess whether any harm has been done is to run the System Update Readiness Tool (SURT) after performing a backup restore: https://support.microsoft.com/kb/947821 [SURT is known as DISM on Windows 8+].
If you see any errors or warnings at all in C:\Windows\Logs\CBS\CheckSUR.log, you're in a potential tight spot when it comes to future updates even if Windows Update works fine now.

SURT is perfectly safe to run even if the hives & winsxs are a bit inconsistent - it's designed specifically for that. Just don't run it whilst you've got a hive from an entirely different Windows version in place of your normal one, and don't try to force SURT to run on Windows 8 [it won't let you by default, but if you extract the file contents & work some magic it is possible to force it to run. Don't do this - just use DISM :) (P.S. I know DISM's not nearly as nice to use as the SURT in some regards. That's why I wanted to see what happened in you run SURT on Windows 8. Not pretty).]

5. If the COMPONENTS reg file is damaged then attempt to get it repaired rather than restore an old copy.
- as asked in 3 above - can System Restore help with this type of repair or not?

Yes - repair is your best bet. There's a trick we sometimes use though if the file is completely beyond repair - and In Place Upgrade/Repair Install on the OS. The trouble is, if the COMPONENTS hive is really messed up, sometimes even the Repair Install fails. If this happens, backup your current COMPONENTS hive & replace it with the standard hive from your Windows version, architecture and Service pack (e.g. Windows 7 SP1 amd64). Then the Repair Install usually does work.

And yes, System Restore is another excellent avenue to try.

6. Are there any remaining issues to be considered if you manually restore the other main registry files and keep the existing COMPONENTS reg file?

Not really. All I would say is have backups (full disk image), so if things don't take nicely at least you can revert the changes. Ideal solution is a repair or reinstall, but I do understand the desire to try a registry backup. Just make sure you have a contingency plan if it all goes pear-shaped and give it a whirl.

Any more questions? Anything you want me to explain further?

Richard

 

[DougCuk]

Thanks for all that - sorry for the delay in responding - real world issues got in the way.

I think you have explained the issues very well.
Obviously one of the main reasons for taking and using registry backups is for when System Restore refuses to work
- which as you say it tends to do just when you need it most.

In many cases the System Restore fails after security software removed an infected file from one of the archived restore points.
Why Microsoft designed a backup system that refuses to work at all when just one insignificant file is altered has always baffled me.
At least with XP you could extract the registry files from the restore point and restore them manually - but that is no longer possible.

I have used ERUNT Registry Backup with Windows XP and it has recovered many a system that would no longer boot.
I refined a solution for installing ERUNT under Vista and Win7 (and even Win8) which works ok
However ERUNT will only backup the registry files that are loaded at the time the backup is run
- and most of the time that doesn't include COMPONENTS.

Registry Backup by Tweaking.com includes all the registry files - even those not currently loaded.
But so far I have not seen any discussion re COMPONENTS about what happens if you attempt a registry restore.
I will check/post on their forum to see if they understand the dangers of restoring COMPONENTS reg file.

DougCuk - Tech Support Engineer - London UK

 

[niemiro]

I'm on my phone right now so can't include links, but actually you can access the filed from System Restore in Vista+, just in a more complex way. Microsoft have moved to a new single technology solution called the Volume Shadow Copy Service which implements both System Restore and Restore Previous Versions. It's also linked in with a much broader technology which allows you to create snapshots on demand & therefore gain access to locked in use files. Because the whole situation is now that much more complicated, so the underlying file formats are too (that basically summarises Longhorn+ - much more complicated but better in ways most users never appreciate). Anyway, the APIs are all publicly accessible, so a number of third party tools are now available. IMO the best is Shadow Explorer. That's how you get access to SR cache.

 

[DougCuk]

I had briefly tried Shadow Explorer but never had any success finding shadow copies of registry files
- when you couldn't boot the copy of windows that created them
- and were accessing the hard drive using another working system.
Should this work?

Having a regular automatic registry backup or a working system restore point is obviously much better anyway.

 

[taney]

This thread is so cool! Are you guys still alive? I read everything and caught up but looking for more insight! Thank you!

 

[Sysnative Windows Update]

Yup, alive and kicking, what do you want to know?

 

[matetoes]

I had briefly tried Shadow Explorer but never had any success finding shadow copies of registry files
- when you couldn't boot the copy of windows that created them
- and were accessing the hard drive using another working system.
Should this work?

Having a regular automatic registry backup or a working system restore point is obviously much better anyway.

I am also wondering how to read files from System Restore Points from a Windows 10 Bootable USB. I have tried ShadowExplorer and System Restore Explorer, but nothing happens when I start them from the command line (and the respective processes don't appear on tasklist)

(I am running Windows 10 build 1803, but I figured it'd be better not to make a separate thread in the right topic just to add a reply)

 

[malletKATman]

As another aside, we also get the odd user here who wants to move the Program Files folder. It's mostly when that user has a small SSD as C:\, a large HDD as D:\, wants programs on D:\, but doesn't want to have to keep changing installers to point to D:\, and instead leave them at C:\ with the files ending up on D:\. I can definitely see the attraction, having a small SSD as C:\ myself. Microsoft have always been very clear that moving Program Files by changing just the environment variable is not going to end well - not just with 3rd party apps, but also with a couple of core Windows components having technical limitations which force them to remain in Program Files, and on C:\. Others try using an NTFS junction. This is a better bet, but there are still issues. All in all, it's not something I either recommend or use, although there can be partial success if junctions are used. But it's risky.

(This quote is from the front of this thread.)

I have an absolute “split disk” system where all the user profiles are on a non-booted HDD and a C: SSD contains only the OpSys and app-installation executables (C:\Program Files and C:\Program files (x86), etc.). There is a simple Registry patch to make all subsequently defined users have their entire profile (libraries, AppData, etc.) defined on a non-C: drive designation. Thus a more reliable migration solution (which I employed) would be after applying the patch to define new users and, laboriously of course, copy their entire spaces from the old drive to the new. It would be more efficient to have all executables on an SSD drive, including the Program Files folders’ contents. All code pages (which are read-only) are paged directly into memory from their folder locations and are not copied to C:\pagefile.sys; thus that architecture runs much faster than having executables on an HDD, unless you have so much extra RAM that you almost never page at all. There should be enough space on even a 100GB SSD for all the app executables, and 500GB and 1TB SSDs are quite cheap these days.

I know from personal experience how handy it is to have all your user data files on a separate drive from the system. If you use Windows 7 Backup and Restore and make a C: drive System Image on each backup, you can restore the entire C: drive from it. Or you could just specify C:\Program Files and C:\Program Files (x86) to be backed up specifically and restore them along with a system Restore Point when needed.

However, I realize that niemiro's quote addresses the situation where a user wants to have executables off the C: drive. I'm just suggesting that the architecture I described is a more efficient way to operate and still have a different drive for all user data, except for actual private executable code.

 

[Rafi2025]

Yes, it does :)

System Restore is a good, safe, way of recovering from even Windows Update based issues. Restoring a complete system image is fine too, but System Restore is safe if not always reliable (I'm sure you've experienced the issue where System Restore fails to make the restoration - it does sometimes fail if it can't make the revert, but when it succeeds it will (almost) always [never and always are very strong words] leave the system in a perfectly healthy state.




It's difficult to answer this because there's no ideal solution other than to restore absolutely everything as a matched pair (e.g. by system image or System Restore). But, from a Windows Update perspective, it's much more important for the COMPONENTS hive to be in sync with winsxs than it is for the SOFTWARE hive to be in sync with winsxs. But it's also important for the SOFTWARE hive to be in sync with everything else.

Basically, what I would say here is to choose the COMPONENTS hive that matches most closely with winsxs, not the one which matches mostly closely with the SOFTWARE hive.


One way to assess whether any harm has been done is to run the System Update Readiness Tool (SURT) after performing a backup restore: https://support.microsoft.com/kb/947821 [SURT is known as DISM on Windows 8+].
If you see any errors or warnings at all in C:\Windows\Logs\CBS\CheckSUR.log, you're in a potential tight spot when it comes to future updates even if Windows Update works fine now.

SURT is perfectly safe to run even if the hives & winsxs are a bit inconsistent - it's designed specifically for that. Just don't run it whilst you've got a hive from an entirely different Windows version in place of your normal one, and don't try to force SURT to run on Windows 8 [it won't let you by default, but if you extract the file contents & work some magic it is possible to force it to run. Don't do this - just use DISM :) (P.S. I know DISM's not nearly as nice to use as the SURT in some regards. That's why I wanted to see what happened in you run SURT on Windows 8. Not pretty).]



Yes - repair is your best bet. There's a trick we sometimes use though if the file is completely beyond repair - and In Place Upgrade/Repair Install on the OS. The trouble is, if the COMPONENTS hive is really messed up, sometimes even the Repair Install fails. If this happens, backup your current COMPONENTS hive & replace it with the standard hive from your Windows version, architecture and Service pack (e.g. Windows 7 SP1 amd64). Then the Repair Install usually does work.

And yes, System Restore is another excellent avenue to try.



Not really. All I would say is have backups (full disk image), so if things don't take nicely at least you can revert the changes. Ideal solution is a repair or reinstall, but I do understand the desire to try a registry backup. Just make sure you have a contingency plan if it all goes pear-shaped and give it a whirl.

Any more questions? Anything you want me to explain further?

Richard

Hi man, very informative post. Can u tell me more about it?
Im not interested in updating things. Trying to make tool to remove things from windows 11 iso, but i want to do it without errors (sfc /scannow).
Problem im facing is hardlinks
Can u tell me how to deal with those?