Hello Dtere1, and welcome to Sysnative!
Under these circumstances I would normally just take your COMPONENTS hive and fix it up. However, I can see (and completely understand - I'm the same way!) why you want to see what I'm doing & learn from it.
There's a lot of complexity going on here. It is possible for another user to receive precisely the same error in SURT - down to the letter - and yet for the fix to be different. There are several reasons for this, but there's one in particular that might apply to your system. When fixing a Windows Update problem we always have a choice - to repair a component completely, or to remove it completely. Removal is only exceptionally rarely the correct fix - but just occasionally it is. If Windows Update attempts to uninstall an old version of a component, and leaves one little bit behind, the fix is to remove that one little bit, not build up every other part. Conversely, if one little bit of an almost complete component becomes corrupt, we repair it rather than deleting the entire thing. This should be reasonably easy to understand, but could you, if I asked, create a definitive rule a non-sentient computer program could follow to determine whether to repair or delete?
In other words, what's the common link? Well, the simplest rule that I can think of would be a one operation rule - if there's only one bit left, delete it, if there's only one bit which needs fixing, repair it. It's down to probability in a way - excluding hardware failure where there may be many hundreds of individual corruptions and some may lie within the same component, the fact that you've already made one repair, and now want me to make another, defeats the one operation rule. This is not a simple black and white problem, and it may be a case of
removal that is needed here.
However, there are about a billion and one exceptions. What if the installer/uninstaller crashed half way through and the rollback mechanism failed also? Then the component could be left in a half and half state, which also defeats the one operation rule.....
Basically what I'm trying to say is that whilst this error appears very simple to fix normally (navigate to HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments, and there's a mismatch between keyform (name of the registry key) and appid (data of the "appid" value) for key microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.4053_8a1a02152edb659b which needs fixing), on your particular system this may actually *not* be the fix, and I would strongly advise against trying it. This is one of the biggest weaknesses with the System Update Readiness Tool. It reports on the corruption it thinks is at fault, but quite often it chooses the wrong on. It may say that key name x is wrong over here, but it may actually be that the data in value y over there is telling it the wrong keyname. It's an amazingly useful tool because it shows me that there is a corruption, I just sometimes need to think carefully about which key actually needs fixing. Don't get me wrong, the SURT gets it right 99% of the time, it's just that final 1% where care is needed.
I personally would not hedge my bets on this little information on even my own system. What I need is more information so that I can come to a complete understanding of what's wrong with your system and what needs fixing. I'll explain my findings when I get them.
First I want you to tell me which key you had to recreate. The more I understand the issue, the better.
Second, I would like you to upload your entire COMPONENTS file for my viewing so that I can take a look at every key from this component. Although for this error it's not really possible for SURT to report the wrong key as corrupt, I want to look for clues as to whether to build up or down.
niemiro said:
Export COMPONENTS hive (temporary instructions)
Please download the Freeware RegBak from here:
Acelogix Software - Download products
Navigate to
C:\Windows\RegBak\{Date}\ and copy the
COMPONENTS file to your Desktop. If the
COMPONENTS file does not exist, please fetch it instead from
C:\Windows\System32\config\COMPONENTS.
Now
right click on it >
Send to >
Compressed (zipped) folder.
Then please upload it to your favourite file sharing website (it will be too big to upload here). If you have a Microsoft Account, OneDrive could be a good choice:
https://onedrive.live.com/, but any other will do just fine. Make sure to set the file as publicly accessible.
Then send me a link to the file in your new thread (outlined below)
Third, I would like you to upload your entire CBS folder:
niemiro said:
Export CBS folder
- Click the Start button
then click Computer.
- Double-click on the C: drive, under the Hard Disk Drives category, and then scroll down to, and double click on the Windows folder.
- Find and double click on the Logs folder.
- Right-click on the CBS folder, and select Copy.
- Go back to your Desktop, right-click on it, and select Paste. You should now see a copy of the CBS folder appear on your Desktop called CBS.
- Right-click on this new folder, and navigate through Send to, and select Compressed (zipped) folder.
- A new file, also called CBS (CBS.zip), but this time with a different icon, will be created. Please upload it here.
Why the whole thing? First I want to see the error that SURT initially reported (CheckSUR.persist.log). I also want to look over your CBS.log for further clues as to what operation it was forming which first caused the problem. And I might need the persisted logfiles if it happened a long time ago. Therefore whole folder.
I know that this isn't really what you asked for, but I can't yet give specific instructions as if I'm completely honest, I don't yet know quite what's wrong. But I hope I have explained a little of my thinking, and that my collection of more data is not just out of desperation because I have no clue what to do. There's quite a bit more to Windows Update than people first realise, I think! It takes about nine months for me to train up the analysts here, then even longer for them to become experienced enough to deal with the trickier cases.
Richard
