After performing a full manual reset of Windows Update on a Windows Server 2016 Essentials Hyper-V Guest following the installations here https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/additional-resources-for-windows-update, ComponentsScanner shows more than 133,000 missing registry keys under "== Missing Registry Keys ==". Is this something that can be ignored? And if not, is it something that can be fixed using built-in Windows tools?
How to solve Components Scanner reporting thousands of missing registry keys
- Thread starter mjmeans
- Start date
After performing a file by file binary comparison of the WinSxS folder tree of the damaged WSE2016 VM compared to the WinSxS fodler tree on a new test VM which was created from a copy of the original VHDX deployment file and then had the same Windows Updates installed in the same order as the damaged VM (while automatic Windows Update was disabled) I find that some DLLs between the two are identical size, but are different internally by exactly 2 bytes. For example the file C:\Windows\WinSxS\amd64_hyperv-gpup-vdev_31bf3856ad364e35_10.0.14393.2608_none_0aa7c7a14f98c04f\gpupvdev.dll is identical between the two except for the 2 bytes as position 0x191C
. On the damaged server they are 00 00 and on the new vm they are BB 7D. Only some DLLs in some packages have differences like this. And the location of the two-byte difference is different from one DLL pair to another. Is this normal?
. On the damaged server they are 00 00 and on the new vm they are BB 7D. Only some DLLs in some packages have differences like this. And the location of the two-byte difference is different from one DLL pair to another. Is this normal?After seeing that some INF and XML files also had these 2-byte differences. And that all of them begins with the three characters "DCS", I've concluded that these files are part of the way component cleanup compresses them and these two byte are probably a used by set during that compression and refer to the time stamp of the original file. And that it was a coincidence that the DLL's I randomly decided to check just happened to have a time portion of the datetime stamp of 00:00.
- May 7, 2013
- 10,396
I would check if you can recover them using RegistryExplorer otherwise you're either going to have to try and source them from another virtual machine, or do a complete clean install.
Why not just check the SHA256 hashes of the files?
Yes, they're compressed and it isn't necessarily because of /StartComponentCleanup. They're compressed to save disk space and will be uncompressed when required. There is a few other file headers which use a similar compression algorithm.
The missing registry keys are all in the form "CanonicalData\Catalogs\* (C:\Windows\WinSxS\Catalogs\*.cat exists but no CanonicalData\Catalogs key found)" and also ones for DerivedData stating the folder is found not no key found. Many refer to netfx. I loaded the COMPONENTS store to examine it and there are many entries, just not those entries (as ComponentsScanner indicates. There are no critical errors, corrupt key names, value names, value data type or value data. Repair log says no possible repairs.
When looking at C:\Windows\System32\config I see several COMPONENTS{*}*.regtrans-ms files from March 22/2022. Am I correct in assuming that these could be the origin of the corruption?
When looking at C:\Windows\System32\config I see several COMPONENTS{*}*.regtrans-ms files from March 22/2022. Am I correct in assuming that these could be the origin of the corruption?
- May 7, 2013
- 10,396
Could you please provide your COMPONENTS hive and ComponentsScanner log? The issue will because part of your hive has been deleted.
Hive collected while the VM was shut down. The server was originally deployed with the customized deployment method described here which instructs to use the method described here. If it helps, I have the original ISO it was built from as well as the customized OEMEssentialsHost.iso, the OEMEssentials.ISO (which is the guest specific ISO) embedded in OEMEssentialsHost.iso, and the OEMEssentials.vhdx which is embedded in the OEMEssentials.ISO. So I can stand up a completely new guest VM from the VHDX file, which I have done to experiment on. however I can't just install a new instance and move everything over because I've discovered is that some of the add-ons that are installed on the failing server and that it relies upon are no longer available to download as they are no longer supported. I found msi files for some of them in the \Windows\installer folder by changing the explorer list in details view to also include the column for Subject; then copying them out and changing their names so I can see which is which more easily. I am aware that these msi files will not be complete if they originally needed a exe type installer that performed other tasks prior to calling the msi.
- May 7, 2013
- 10,396
Okay, it looks like those missing keys aren't part of the hive anymore or part of the transaction logs. You're going to need to find those keys on another machine and then import them back if you want to repair the hive.
You can use SFCFixScriptBuilder to do this, it'll search another COMPONENTS hive using the list of keys provided to it and then build a fix script which you can use with SFCFix to import the keys it has found. I've attached a log file you can use.
Download: Release 0.0.6 · MOV-EDX/SFCFixScriptBuilder
You can use SFCFixScriptBuilder to do this, it'll search another COMPONENTS hive using the list of keys provided to it and then build a fix script which you can use with SFCFix to import the keys it has found. I've attached a log file you can use.
Code:
SFCFixScriptBuilder -hive <Path to hive> -log <Path to log> --components --fullDownload: Release 0.0.6 · MOV-EDX/SFCFixScriptBuilder
So I made a new server from the same VHDX that was used to create the failing server initially. I then disabled automatic updates and installed all the same KBs that the failing server has installed into the new server. SFCFixScriptbuilder reports the new server doesn't have all of the registry entries. Is it better to run SFCFix now even though at this point only some of the registry entries can be fixed? Then try SFC /SCANNOW and DISM commands to check everything before resorting to compoentsscanner again? or is it best to try to find all the references needed and install them on the source server to generate a SFCFix script that does everything at once?
From the 15,562 references in Missing_Components.txt, SFXFixScriptBuilder says it was unable to find 4,638 of them. I'm going to makea snapshot on the current SOURCE machine and try to find the other assemblies' installers somehow so I can revert that if that's not the right way to proceed.
- May 7, 2013
- 10,396
Okay, that's what I would recommended too, if you look up the version number associated with the component, then you should be able to find the associated cumulative update. The "Sourcing the Files" section of this tutorial should help you: Troubleshooting 0x800f081f / 0x800f0982 Error
Slowly working through these. ComponentsScanner reports it's down to 2303 corruptions found in DerivedData\Components. Finding sources is the most difficult part. I gave SFC and Windows Update a try, just to see if enough was fixed to be able to apply the latest cumulative update, but not fixed yet.
- May 7, 2013
- 10,396
At least you're making progress and it is usually the most difficult and time consuming part of Windows Update, especially when the Component subkey has been deleted.
ComponentsScanner is now reporting several things like this:
Is this expected at this point? How should I proceed on results like this?
[edit] I loaded the hive using Regedit into HKLM\temp and examined HKLM\temp\DerivedData\Components\ in hopes of verifying what was reported. I was unable to find the first few keys reported (which is when I stopped searching). I assume I'm looking in the wrong place.
Code:
Key: ROOT\DerivedData\Components\amd64_microsoft-windows-d..tp-server.resources_31bf3856ad364e35_10.0.14393.0_en-us_4a8b43d8a6389899
Value: identity
Type: RegBinary
Data: Microsoft-Windows-Deployment-Services-TFTP-Server.Resources, Culture=en-US, Version=10.0.14393.0, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=amd64, versi
Data (raw): 4D-69-63-72-6F-73-6F-66-74-2D-57-69-6E-64-6F-77-73-2D-44-65-70-6C-6F-79-6D-65-6E-74-2D-53-65-72-76-69-63-65-73-2D-54-46-54-50-2D-53-65-72-76-65-72-2E-52-65-73-6F-75-72-63-65-73-2C-20-43-75-6C-74-75-72-65-3D-65-6E-2D-55-53-2C-20-56-65-72-73-69-6F-6E-3D-31-30-2E-30-2E-31-34-33-39-33-2E-30-2C-20-50-75-62-6C-69-63-4B-65-79-54-6F-6B-65-6E-3D-33-31-62-66-33-38-35-36-61-64-33-36-34-65-33-35-2C-20-50-72-6F-63-65-73-73-6F-72-41-72-63-68-69-74-65-63-74-75-72-65-3D-61-6D-64-36-34-2C-20-76-65-72-73-69-06
Suggestion: Microsoft-Windows-Deployment-Services-TFTP-Server.Resources, Culture=en-US, Version=10.0.14393.0, PublicKeyToken=31bf3856ad364e35, ProcessorArchitecture=amd64, versionScope=NonSxS
4D-69-63-72-6F-73-6F-66-74-2D-57-69-6E-64-6F-77-73-2D-44-65-70-6C-6F-79-6D-65-6E-74-2D-53-65-72-76-69-63-65-73-2D-54-46-54-50-2D-53-65-72-76-65-72-2E-52-65-73-6F-75-72-63-65-73-2C-20-43-75-6C-74-75-72-65-3D-65-6E-2D-55-53-2C-20-56-65-72-73-69-6F-6E-3D-31-30-2E-30-2E-31-34-33-39-33-2E-30-2C-20-50-75-62-6C-69-63-4B-65-79-54-6F-6B-65-6E-3D-33-31-62-66-33-38-35-36-61-64-33-36-34-65-33-35-2C-20-50-72-6F-63-65-73-73-6F-72-41-72-63-68-69-74-65-63-74-75-72-65-3D-61-6D-64-36-34-2C-20-76-65-72-73-69-6F-6E-53-63-6F-70-65-3D-4E-6F-6E-53-78-53Is this expected at this point? How should I proceed on results like this?
[edit] I loaded the hive using Regedit into HKLM\temp and examined HKLM\temp\DerivedData\Components\ in hopes of verifying what was reported. I was unable to find the first few keys reported (which is when I stopped searching). I assume I'm looking in the wrong place.
Since there are also still some missing DerivedData then I suppose I can create a new Missing_Components.txt file using a command like this:
Code:
(for /F "tokens=1" %i in ('findstr /b "Derived" ComponentsScanner.txt') do @(for /F "tokens=3 delims=\" %j in ("%i%") do @echo %j)) > Missing_Components.txt- May 7, 2013
- 10,396
I've seen this issue happen a few times now, I do wonder if SFCFix actually causes this when it attempts to import thousands of keys at once? It's easy to sort out though but you'll need to do it programmatically. I usually just parse the ComponentsScanner.txt file and then look up the corresponding component in the hive, find the identity value and then replace the value data with the suggested data which is actually taken from the database which ComponentScanner uses.
The key should exist in the hive otherwise ComponentScanner wouldn't have been able to find it? We can leave those errors to the end and sort them out afterwards.
Yes, the produced .txt file should be okay to use.
After a reboot this morning, the keys that I mentioned above do show up in COMPONENTS. I'm wondering if they were in a pending transaction or something and regedit just didn't load the pending changes. It could also be that I was just too tired and not seeing it was user error.
Anyway, since you mentioned the possibility that SFCFix might be causing this I checked the previous MissingComponents.txt file and found that indeed the corrupted entries were in the original file. So at this point I'm assuming the correct way to proceed is to complete that original fix before moving on and to generate a new SFCFix.txt with only those keys that were corrupted.
So I'm creating a checkpoint and a new temp folder for this round of fixes (I don't like using desktop) and going to run the following commands to get a new SFCFixScript.txt to feed to SFCFix.
Anyway, since you mentioned the possibility that SFCFix might be causing this I checked the previous MissingComponents.txt file and found that indeed the corrupted entries were in the original file. So at this point I'm assuming the correct way to proceed is to complete that original fix before moving on and to generate a new SFCFix.txt with only those keys that were corrupted.
So I'm creating a checkpoint and a new temp folder for this round of fixes (I don't like using desktop) and going to run the following commands to get a new SFCFixScript.txt to feed to SFCFix.
Code:
(for /F "tokens=5 delims=:\" %i in ('findstr /b "Key" ComponentsScanner-202306112226.txt') do @(@echo %i)) > Missing_Components.txt
del /Q %USERPROFILE%\Desktop\SFCFixScript.txt
SFCFixScriptBuilder.exe -hive "\\repairserver\c$\Windows\System32\config\COMPONENTS" -log Missing_Components.txt --components --full > SFCFixScriptBuilder.log
move /Y %USERPROFILE%\Desktop\SFCFixScript.txt .\Is there a command line switch that will save the console output to a log file? i.e. save this info so it doesn't have to be copy/pasted to keep a log of the process?
Code:
Loading registry hive from C:\Windows\System32\config\COMPONENTS
Parsing loaded hive, please wait...
Hive parsed successfully - found 249,988 keys and 653,386 values
Starting corruption scan
Performing regedit load test
Scanning CanonicalData\Catalog for corruptions
Scanning CanonicalData\Deployments for corruptions
Scanning DerivedData\Components for corruptions
2303 corruptions found in DerivedData\Components
Scanning VersionedIndex\...\ComponentFamilies for corruptions
Analysing coruptions
Checking WinSxS catalogs against CanonicalData\Catalogs- May 7, 2013
- 10,396
They would have been loaded into the hive at the time.
Yes but you will need to make sure that your SFCFixScript follows the RegEdit format. Alternatively, you could write them to the hive using one of the .NET registry APIs. That's what I used to do with that particular issue.
Unfortunately, from what I remember, there isn't any command-line arguments you can provide to it. However, you may be better of asking @Tekno Venus that question since he is the developer for the ComponentScanner tool.