DougCuk said:
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