How to solve Components Scanner reporting thousands of missing registry keys

mjmeans said:
Is it safe to proceed with running SFCFix with the new SFCFixScript? i.e. it's not going to truncate these identity keys.... Or should I edit the SFCFixScript to remove all the identity lines before proceeding?
Click to expand...
I would remove all the identity and S256H values from SFCFixScript since you do not need to update these and then run the script with SFCFix. It should hopefully replace all the missing c! and f! marks for you.
 
So in my work onrecovering all the Missing Components in the damaged server, I'm discovering that Windows Cumulative Updates do not necessarily include all prior versions of all updated assemblies. One of my first passes on resolving missing components was to stand up a new repair server and get it fully updated using Windows Update. It of course installed only the latest versions of every Cumulative Update for Windows and .Net Framework. It did not, however, result in a repair server source with a history of every updated version of every assembly from RTM to present. So, I've had to download from Windows Update Catalog each of the Cumulative Updates and apply them in the proper order in order to get all these assemblies installed on the repair server. Then running components scanner, et al, after each update, just in case a later cumulative update happens to remove a component.
 
They do include all the previous patches but not the individual files or registry keys themselves. The RTM version gets hydrated with the latest changes from each subsequent release. That's why the cumulative update .msu files only contain f and r folders for the components.

We often have to create VMs from scratch using the same method you're doing. It can be a painful process sometimes.
 
Thanks for letting me know that I'm on the right track with my assessment and process. BTW, I've written some ps1 scripts to make this a little more automated and to keep time stamp named copies of the various tools' output files. Maybe I'll post them on Github.

I tried to find a way to automate downloading updates or even downloading and installing updates from Windows Update Catalog, but failed. Ended up manually downloading them. Would have been nice to have a script that could be run in the VM to get the next one (whichever one it was) and install it and reboot.
 
It's difficult to determine what naming convention they use with their download URLs, we've looked at this in the past and there doesn't appear to be any pattern. You can search the update catalog using the update Id but you need to know that information beforehand and you're still reliant on scraping their page for the download link.

Just an aside, they don't actually always remove an update from their server, when an update has been pulled from the catalog, if you have the direct download link, then it should work for a very long time.
 
Yeah, I was hoping to be able to run a PS script and provide it with a list of KBs to install. My idea was to write a script that could be given a queue to process on the command line (or piped to it). It would download the first KB on the list from the catalog and call wusa with the noreboot switch. Then check to see if reboot is pending. If no reboot pending, then do the next one. When there is a pending reboot pending, then either add a run-once or a scheduled task to call the script again with the list of remaining updates. And if there was an error reported by one KB stop and ask whether to continue.

I was going to base it on the old Get-KBUpdate module. But that no longer works. It's 9 years old now, so I suppose that's expected with the changes that windows catalog has made to their site. I tried to do it myself but I don't know enough about scripting web page downloads and processing to find the appropriate link, so I stopped.

I since found another module that might work which has been updated within the last few months, so it's likely to work as a way to automate downloading KBs. But the project includes precompiled DLLs. And I'm not that inclined to trust something where the DLLs would be running under administrative privileges when the source of the DLLs isn't known. I don't want to mention the name of that project here because I am not recommending anyone use it and also because I'm not trying to throw shade on what might actually be an innocent project.
 
New problem in the latest round of installing a cumulative updates on the repair server and using it as the hive for sfcfixscriptbuilder for missing_components.txt.... SFCFixScriptBuilder is reporting "Object reference not set to an instance of an object." This happened once before when the remote server wasn't available over the network, but that doesn't seem to be the problem this time. I was going to run it in debug in VS2022 to see what is happening. Then it occurred to me to check if the COMPONENTS hive was in use on the repair server and it was. Tiworker was doing 'something' and had it open. So, I had to wait until that finished. Might want to add some details to the error message to tell users that it is related to loading the COMPONENTS hive form the repair source and to check to make sure it's available and that it's not 'busy' when this happens.
 
After getting enough cumulative updates and servicing stack updates fixed using sfcfixscript and replacing one package's files, dism /online /cleanup-image /restorehealth now succeeds. SFC /scannow now also runs, but fails at 38%. SFCFix however crashes! I selected to upload a crash report about a minute ago.

I'm going to reboot and try sfc again and see what happens.
 
mjmeans said:
So, I had to wait until that finished. Might want to add some details to the error message to tell users that it is related to loading the COMPONENTS hive form the repair source and to check to make sure it's available and that it's not 'busy' when this happens.
Click to expand...
It should just return and then continue but it seems that the issue is that the hive name is being set to SOURCE still when it should be using COMPONENTS instead.

Code: 
private static void LoadComponentsHive(string path, string name, ref RegistryScriptBuilder builder)
    {
        //Attempt to load the hive, if COMPONENTS hive has already been loaded then this will return an error
        int result = LoadHive(path, name);

        if (result != 0) 
        {
            //Assume that COMPONENTS hive must have already been loaded
            return;
        }

        builder.SetComponentsHiveName(name); <-- Issue appears to be due to this line
    }

I'll need to look into this properly and also find out what the HResult is when a hive is in fact in use.

mjmeans said:
SFC /scannow now also runs, but fails at 38%. SFCFix however crashes! I selected to upload a crash report about a minute ago.
Click to expand...
That is possibly because of some missing files and did SFCFix crash on AutoAnalysis::? SFCFix was primarily written for Windows 7/Windows 8 systems and some of the directives don't work correctly on Windows 10/11 builds. The main fix directives of PowerCopy:: and RegistryScript:: still work okay though.
 
x BlueRobot said:
and did SFCFix crash on AutoAnalysis::?
Click to expand...
I don't remember seeing any specific output specifying where it crashed when it asked for permission to send the crash report. After it sent the crash report it just ended to the command prompt.
 
I'm stuck. DISM restore health works. Windows update to the latest cumulative update worked. Windows update to the latest servicing stack fails. SFC /scannow fails.

In CBS log I see several "changelist shadowed missing its manifest" lines all reporting the various "Microsoft-Windows-ServicingStack-*10.0.14393.4650*".

When I get a directory of the *servicingstack*4650* files in Windows\WinSxs\Manifests directory of both the failing server and the repair source server I see the same list of files with the same length.

Should I attempt to uninstall and reinstall the 4650 servicing stack?
 
Hmm uninstall is not an option for servicing stack updates in Control Panel > Programs > Programs and Features > Installed Updates.
 
This is going to be another registry related error which will be quite tricky to fix without knowing how the Winners subkey and the COMPONENTS hive are linked, therefore could you please provide me with the CBS logs, along with the COMPONENTS hive and the Winners subkey exported as a .hiv file? I'll provide instructions below:

Retrieve Components Hive
1. Navigate to C:\Windows\System32\Config and locate the COMPONENTS file.
2. Please copy this file to your desktop.
Note: If you receive an error that this file is in-use, simply reboot your computer and try again.
3. Right-click on this file on your desktop and select Send To...Compressed (zipped) folder. This will create a file named COMPONENTS.ZIP on your desktop.
4. The file will likely be too large to upload here so please upload to a file sharing service. Examples of services to upload to are Dropbox or OneDrive or WeTransfer and then just provide the link in your reply.

Export SideBySide
  1. Click on the Start button and in the search box, type regedit
  2. When you see regedit on the list, right-click on it and select Run as administrator
  3. When regedit opens, using the left pane, navigate to the following registry key and select it by clicking on it once.

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
  4. Once selected, click File > Export....
  5. Change the Save as type: to Registry Hive Files (.)
  6. Name this file SxS (with no file extension) and save it to your Desktop.


Once done please upload this file via Dropbox or OneDrive or SendSpace.
 
Sure attached below...

But one other thing to note...

There is still one missing servicingstack component (derived) on the failing server. "amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.14393.4222_none_7f13461e21e4fea5".

To try to find it, I loaded an earlier checkpoint of the repairserver VM (clean and before any windows updates) and installed the servicing stack updates one by one (oldest first) through the servicing stack updates on Microsoft Catalog and checking the WinSxS folder after each update for "amd64_microsoft-windows-servicingstack_*" for each version number to find which one has 10.0.14393.4222. There isn't one. The KBs in order are KB4485447 through KB4576750 go from 10.0.14393.2781 to 10.0.14393.3926. The very next one is KB5001078 which installs 10.0.14393.4227! Skipping .4222! There doesn't seem to be a way to resolve the servicing stack version .4222.

On the failing server the list of servicing stack versions in the WinSxS folder are .0, .4222, .4227, .4349, etc. So there are much newer servicing stack versions in place. And since DISM works, I wonder if any references to .4222 are actually still needed and whether I should try DISM /StartComponentCleanup or disk cleanup to see if the references to .4222 will be removed.

The files would have been small enough to upload here, but here is the onedrive location: sysnative
 
Last edited:
I had also examined this thread, because I too see the STATUS_SXS_TRANSACTION_CLOSURE_INCOMPLETE in CBS.log relating to ServicingStack 10.0.14393.4650. However, I didn't find any mismatches in version numbers in the registry, so that solution doesn't appear to be what I'm looking for.
 
New information. When searching for .4222 in the registry I found under HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect\amd64_microsoft_windows-s..cingstack.resources_31bf3856ad364e35_0.0.0.0_en-us_0cb24bf2954ad3c5 and key for Package_104_for_KB4601392~31bf385 blah-blah and others that have the value of 10.0.14393.4222@2.

I didn't have a copy of that KB from the Windows Update Catalog. Well, it doesn't exist in the catalog. What I did find was this article that says Microsoft pulled that update.
 
Searching for any files on the damaged server with file names that have ".4222" I do see numerous *.cat, *.mum and *.manifest files in various folders under Windows servicing\packages, catroot, WinSxS, WinSxS\Manifests. None of the files with this version are available on the repair server, or the host. So apparently the host never got the problematic KB.
 
I'm posting the CBS log lines here for reference:

Code: 
2023-06-26 17:44:40, Info                  CSI    0000007f Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Ds-Core, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000080 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Admin-Core, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000081 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-BuildBranch, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000082 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Termsrv-Extra, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000083 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-OneCore-Extra, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000084 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Boot, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000085 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-onecoreadmin-Core, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000086 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Base, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000087 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Windows-Extra, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000088 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Installers-OneCore-Extra, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000089 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Base-Extra, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000008a Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Admin-Core, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000008b Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Admin, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000008c Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Boot, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000008d Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Ds, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000008e Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-onecoreadmin-Core, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000008f Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Full, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000090 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-OneCore, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000091 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Shell-Core, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000092 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Windows-Core, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000093 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Windows-Extra, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000094 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Inetsrv, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000095 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Net, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000096 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Mof-onecoreadmin, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000097 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Admin, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000098 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-OnecoreDs, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    00000099 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Ds, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000009a Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-OneCore, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000009b Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Installers-OneCore, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000009c Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Boot-Onecore, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000009d Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Shell-Extra, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000009e Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Installers-OneCore-Extra, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    0000009f Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Net, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a0 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Ds-Core, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a1 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-BuildBranch, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a2 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-CmiTrust, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a3 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-OneCore-Extra, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a4 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Inetsrv-Extra, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a5 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Shell-Core, version 10.0.14393.4650, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a6 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-OnecoreBase, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a7 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Core, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a8 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Full, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000a9 Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Transformers-Windows-Core, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Info                  CSI    000000aa Changelist shadowed missing its manifest - Microsoft-Windows-ServicingStack-Base, version 10.0.14393.4650, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}
2023-06-26 17:44:40, Error                 CSI    000000ab@2023/6/27:00:44:40.137 (F) onecore\base\wcp\componentstore\csd_winners.cpp(1273): Error STATUS_SXS_TRANSACTION_CLOSURE_INCOMPLETE originated in function OriginateManifestsMissingError expression: (null)

It looks like the Components subkey is missing for those particular versions. Do you have a machine which has those? Please note that some of the component names will be truncated if it is greater than 40 characters in length. This PowerShell snippet will get the truncated value for you:

Code: 
$string = "Microsoft-Windows-ServicingStack-Transformers-Windows-Core"
$string.substring(0, 19) + ".." + $string.substring($string.length-19, 19)

You can use $string.length to work out the length. In the above example, the component name is actually Microsoft-Windows-S..ormers-Windows-Core.

mjmeans said:
On the failing server the list of servicing stack versions in the WinSxS folder are .0, .4222, .4227, .4349, etc. So there are much newer servicing stack versions in place. And since DISM works, I wonder if any references to .4222 are actually still needed and whether I should try DISM /StartComponentCleanup or disk cleanup to see if the references to .4222 will be removed.
Click to expand...
I wouldn't worry about that version since it doesn't appear to be actively used by your servicing stack. You should be on *.4650 but the Component subkeys are missing which is why you're getting those errors in your CBS log.

Could you please confirm your servicing stack version with the following command:

Code: 
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Version"
 
Yes. The servicing stack version is .4650.

I wrote this little script to search the registry and export all subkeys (and properties) that match a pattern in order export only the *.4650* keys to be able to more easily compare the values with the failing server. It's designed to mimic the *.reg file format. Though I don't know if I've implemented the *.reg format completely.
Code: 
# Written by: mjmeans
param (
    $file = "searchresults.reg",
    $regkey = 'HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing',
    $like = '*.4650*',
    $server = 'repairserver'
)

$out = Invoke-Command -ComputerName $server -ArgumentList $file,$regkey,$like -ScriptBlock {
    param ($file,$regkey,$like)
    Get-ChildItem $regkey -Recurse | Where-Object {($_.Name -like $like)} |
        foreach {
            Write-Output "`r`n[$_]"
            foreach ($p in $_.Property) {
                $v=$_.GetValue($p); $t=$_.GetValueKind($p)
                if ($t -eq 'String') {$tv="""$($v -replace('\\','\\') -replace('\"','\"'))"""}
                elseif ($t -eq 'Dword') {$tv="dword:$("{0:x8}" -f $v)"}
                else {throw "unexpected registry value type: `n`r Key: $_`r`n Property: $p`r`n Type: $t`r`n Value: $v"}
                Write-Output """$p""=$tv"
            }
        }
    }
Write-Output "Windows Registry Editor Version 5.00" | Out-File $file
Write-Output $out | Out-File $file -Append

I've put the two export reg files on my onedrive share. The localresults.reg is the failing server.
 
Why are you searching under the CBS subkey? The issue is the "winning" components are missing and will need to be sourced from a known good machine. You'll want to look under:

Code: 
HKLM\COMPONENTS\DerivedData\Components
 
You must log in or register to reply here.
Back
Top