How to solve Components Scanner reporting thousands of missing registry keys

A later update had copes of some of the missing components. Here is the current list I have yet to resolve.

Code: 
amd64_microsoft-windows-msxml30_31bf3856ad364e35_10.0.14393.2485_none_fe123f2ff17bc8fe
amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.14393.4222_none_7f13461e21e4fea5
amd64_microsoft-windows-usermodensi_31bf3856ad364e35_10.0.14393.2457_none_e802f307221c6ea1
amd64_networking-mpssvc-svc_31bf3856ad364e35_10.0.14393.2457_none_0fb50ba022854b98

  • The .4222 versions on the failing server are shown under \Windows\servicing\Packages as being from KB4601392. The next KB is KB5001078. MS's info page lists .4222 as the version of the files within it, but its wrong. It actually has .4227 in it. The repair server VM's WinSxS, servicing/Packages, and catroot, all confirm that that KB only has .4227.
  • WinSxS has packages for servicing stacks all the way from .0 to .5771 which is KB5023788. The packages are being extracted, however, the installation is not completing. Other Windows Updates, such as Cumulative Updates are working. Just not any servicing stack updates.
  • But the issue reported by ComponentsScanner is the missing .4222 package, and the issue reported by the CBS log after SFC /ScanNow failing at 41% is "(P) Corrupt" entries referring to servicing stack .3744.
  • Looking at servicing/Packages for .3744 shows that was from KB4562561. Attempting to reapply that KB to the failing server fails with an already installed msg.
  • DISM reports that it's using .4169 which, according to MS, comes from KB4598243. That is an expired KB that also isn't available anymore. But there is no indication that that KB number is installed on the failing server at all. wmic qfe list and Get-HotFix don't show it was ever installed. And there are no files in \Windows\* folder tree that have that KB number in their name. At this point, I don't know if I can trust that MS has the right info for the KBs in question.
I wish I knew someone with a WSUS installation that could extract those KBs.
 
I'm reading through this to resolve the CBS (p) issues. I also found this in which philc43 had posted an original download link to the expired KB4601318 update (which is apparently for .4225). I'm searching for an original download link to KB4601392 to resolve the .4222 package, and original links to the other expired updates.
 
I found a direct link to the x86 version of KB4601392 http://www.download.windowsupdate.com/c/msdownload/update/software/secu/2021/02/windows10.0-kb4601392-x86_1017dde1a1da74316863aa23f6b5e2dd05eb24b3.msu. Simply replacing x86 with x64 doesn't work. Is there a way to find out what the code should be after http://www.download.windowsupdate.com/c/msdownload/update/software/secu/2021/02/windows10.0-kb4601392-x64_*.msu?
 
x BlueRobot said:
You can use SFCFixScript builder to do that for you if you have a valid key on another machine. If you include the value name as part of your key path then it will only build that missing value and not the entire key. You would use the --components option and then your key path would be like: <key path>\<value name>.

10.0.14393.2339 = KB4284833 (Unavailable)
10.0.14393.2457 = KB4343884 (Unavailable)
10.0.14393.2485 = KB4457131
10.0.14393.2791 = KB4487026


It should be part of the .4227 cumulative update, most of the servicing stack updates are packaged as part of a cumulative update. You can remove the servicing stack updates despite Microsoft insisting that you can't but you need the newer one installed to do so.
Click to expand...

KB4457131 is a delta update and doesn't install on my repair server. Here is an except from my most recent run of my KB install scripts.
Code: 
20230714_053115.4800: INFO: July 30, 2018 - KB4346877 (OS Build 14393.2396)
20230714_053115.4800: INFO: - 2018-07 Cumulative Update for Windows 10 Version 1607 for x86-based Systems (KB4346877)
20230714_053115.4800: INFO: - 2018-07 Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4346877)
20230714_053115.4800: INFO: - 2018-07 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4346877)
20230714_053122.4076: INFO: - Installing: 'windows10.0-kb4346877-x64_374c04ab4fce5134b8c95faab72be4e527c86824.msu'
20230714_055417.7821: INFO: - SUCCESS (0x00000bc2) Error_Success_Reboot_Required
20230714_055417.7821: INFO: August 14, 2018 - KB4343887 (OS Build 14393.2430)
20230714_055417.7821: INFO: - 2018-08 Delta Update for Windows 10 Version 1607 for x86-based Systems (KB4343887)
20230714_055417.7821: INFO: - 2018-08 Delta Update for Windows 10 Version 1607 for x64-based Systems (KB4343887)
20230714_055417.7821: INFO: - 2018-08 Delta Update for Windows 10 Version 1607 for x64-based Systems (KB4343887)
20230714_055424.7172: INFO: - Installing: 'windows10.0-kb4343887-x64_delta_c96979dbdc9382de1f305cf5a436b4543bfec14e.msu'
20230714_055506.2540: ERROR: - FAILED (0x80240017) WU_E_NOT_APPLICABLE: Operation was not performed because there are no applicable updates.
20230714_055506.2540: INFO: August 30, 2018 - KB4343884 (OS Build 14393.2457)
20230714_055506.2540: INFO: - Not available from Windows Update Catalog
20230714_055506.2540: INFO: September 11, 2018 - KB4457131 (OS Build 14393.2485)
20230714_055506.2540: INFO: - 2018-09 Delta Update for Windows 10 Version 1607 for x86-based Systems (KB4457131)
20230714_055506.2540: INFO: - 2018-09 Delta Update for Windows 10 Version 1607 for x64-based Systems (KB4457131)
20230714_055506.2540: INFO: - 2018-09 Delta Update for Windows Server 2016 for x64-based Systems (KB4457131)
20230714_055506.2696: INFO: - Installing: 'windows10.0-kb4457131-x64_delta_8eeb63023ac2cc3cdfe5c130d13edd26c2c540ea.msu'
20230714_055551.8172: ERROR: - FAILED (0x80240017) WU_E_NOT_APPLICABLE: Operation was not performed because there are no applicable updates.
20230714_055551.8172: INFO: September 20, 2018 - KB4457127 (OS Build 14393.2515)
20230714_055551.8172: INFO: - Not available from Windows Update Catalog
I'm going to look through the KB info pages to track which KBs each one replaces and try to construct a KB install list that will result in this delta update actually being able to be installed.

But first, I found the direct download links to windowsupdate.com for KB4601318 and KB4601392. They were on a foreign language site that had an archive of the links to use for manual update of Windows 10. It makes sense that it's still actually available even though it's officially unsupported and unpublished, because DISM normally has to be able to use online resources to repair a system. It turns out the package I needed to resolve the .4222 issue was indeed in KB4601392. I'm applyng the SFCFixScript tonight and rebooting. And since this is resolution of part of the servicing stacks I will then run DISM /Online /Cleanup-Image /RestoreHealth and then SF /ScanNow. I anticipate that the (P) issues will remain in CBS.log and that DISM and SFC will be unable to repair those simply because of a missing SSU package. But I'll post my results.
 
Are you just looking for the payload files? Just remove the update associated with 10.0.14393.2457 (KB4343884), the update is from 2018 and will have been superseded by now. You can either do this through WUSA or by using FRST but you will need to do a FRST registry search first.
 

Attachments

mjmeans said:
Is there a way to find out what the code should be after http://www.download.windowsupdate.com/c/msdownload/update/software/secu/2021/02/windows10.0-kb4601392-x64_*.msu?
Click to expand...
No, we've been asking ourselves that question for a long time and unfortunately we've never been able to work out how it's calculated. We try and keep an archive of direct download links as we come across them but usually that is through archives on GitHub etc.
 
After applying the SFCFixScript that had ONLY the registry entries to fix .4222 and trying to reboot, the server reported gave me the options of "apply updates and reboot" or "apply updates and shutdown". This resulted in an unbootable server. So I had to restore last weekend's backup. 3 steps forward ... Gonna try: 1) create a snapshot, 2) use sconfig to turn off automatic updates, and reboot again 3) re-run componentsscanner, extract missing components and re-run sfcfixscript to prepare to apply all at once including the .4222, 4) create another snapshot, 5) apply the fixes and reboot.

If that also results in an unbootable server, I'll revert and remove the .4222 fix and try again. That should tell me whether the broken .4222 registry entry and a broken servicing stack history is somehow necessary to keep the server running.

I'll post the results.
 
Some bad (and strange) news in this case. After restoring the backup from 7/7 the server boots and ran for several hours before I had time to work on fixes again. But after that I got a BSOD. So I reverted again and this time after the restore, initial boot, and allowing all the startup processes to run and the CPU to stabilize back down to normal, I rebooted again. Without making any changes. No changes that were originally applied since 7/7. Just letting it completely boot, then shutting down and rebooting. BSOD. Sigh.

So now I'm side-tracked into resolving a BSOD upon reboot. Trying a clean boot (MSCONFIG and turning off all non-MS services).

Not sure how this is going to proceed at this point. What's strange is that before the latest attempt at applying only the .4222 fixes, the server had already had several fixes since 7/7 applied and the server had rebooted several times just fine.
 
Does DISM run to completion without any issues now? You mentioned in your previous posts that you were missing some payload files. I've never seen missing payload or registry entries in the COMPONENTS hive cause any BSOD issues. That .4222 version isn't even your active servicing stack so it shouldn't be causing any crashes; in fact, if that were the case, then Windows Update wouldn't work at all, including using DISM.

I'm honestly confused at this point as to what is left to fix? Did you run my SFCFix? Did you successfully extract and replace the missing *.4222 file? What happened with the missing/corrupt *.2457 files?
 
DISM did complete without issues. But SFC did not. And yes, I had applied the fixes in your previous SFCFix (not the one from Friday though).

So now the system has bene reverted to the state it was at on 7/7. The backup was created using the host's wbadmin.exe to do a full VM backup. The restored VM boots! But will not reboot. The error BSOD is 0xc000021a I believe. A non-authoritative web page (whose main focus is promoting their own backup software) says this can happen because of a default video driver that, for whatever reason, activates upon restoring a Hyper-V VM. It also says that in safe mode it can be uninstalled or disabled to recover the VM. Considering the source, it was a low chance of success. And it did not resolve the reboot problem.

My plan at this point is to 1) Run DISM to see the current state of the restored VM. 2) re-run the two SFCFix.txt from you from 7/7 and 7/14. 3) Run DISM again to see the state changes. 4) Run ComponentsScanner, extract missing_components and run SFCFixScriptBuilder using the repair server as the source hive. 5) Run DISM a third time. 6) Copy the DISM and CBS logs off the server. 7) Make a new snapshot and reboot.

I'm also considering a nuclear option.... copy all SSU files and packages and registry settings from the repair server to the failing server.

A difficulty I have is that this server is using spinning disks, so everything takes a long time to run.
 
Last edited:
One thing I notice that is different about the initial post on that thread is that it's discussing what happens when is says "Once the user has entered their credentials for the corresponding credential provider (for example, using a pin or password), a logon session is created, and the credentials are validated by the LSASS process." In my case it's a BSOD before any presentation of a logon UI, or maybe while trying to present a logon UI. If it's not right at the logon UI, my thought is that it may be a consequence of the desktop essentials experience roll; but I will keep reading.
 
Concerning the "cannot repair member file" issues in CBS.log I also did a search on this form and I only find one reference referring to Windows Server 2016 here. However in my case it's not hash issues. The files are just missing. Am I correct that all I need to do to resolve them is to copy the WinSxS packages from the repair server, if they exist?

Oh, here is the latest info-pack. Since there were multiple steps that I performed here the results of each step are numbered. Different copies of the logs taken at different times in the sequences. I didn't edit them to remove duplicated log entries from the previous log, but I did make it a "solid archive" which would give better compression with multiple files potentially having large parts of the same content. I'm sure you already know that's what it does, I'm just documenting it here so other people understand what was done.

As a reminder, the history of the server prior to these changes is: Multiple fixes were applied and worked fine, including reboots, up until 7/16. The VM backs up its system state and primary data drive to its own dedicated VHDX drive which assigned to it in early June when problems were first discovered. This is done once a week. The Hyper-V host also performs a Hyper-V backup of the VM once a week. On 7/16, after applying the .4222 fix, the failing server failed to reboot. Attempts to restore to the last known good configuration failed, as well as an attempt to restore to the VM's internal backup on 7/7. Restoring the the VM using the hosts restore function returned the failing server to a bootable state, reverting the fixes between 7/7 and 7/16. Multiple attempts to re-apply the fixes fail causing a system that will not reboot. Even just restoring the backup and booting once, then rebooting (without applying any fixes) fails to reboot.

This suggests to me that at the time the host backup was made, which was before the VM's internal backup was made, the failing server had some pending operation that hadn't finished yet, and that pending operation is what is causing subsequent reboots to fail with 0xc000001a. I don't (yet) know how to determine if this is in fact the case or whether that changes the priority of what needs to be fixed next.

Anyway, after fixes and steps below were done (logs in the attachment) I'm going to reboot the server (later tonight) and hope for the best. If it fails, I'll have to revert again to the 7/7 backup.

1. dism and sfc performed
2. components scanner and extraction of missing components
3. sfcfixscript using a repair server that has already been updated to the current SSU and LCUs up through the versions specified for the missing components
4. sfcfix to apply the fixes
5. sfcfixscript again using v0.0.7 instead to avoid having to use regrecover
6. sfcfix to apply the fixes
7. unneeded log file because I'm running these from a powershell sdcript (sorry about that)
8. sfc performed
9. dism and sfc perfomed again since sfc fails at 41%
a. dism and sfc perfomed again, but using \\repairserver\C$\windows as the dism source

As for the several CBS message in the form of "[SR] Cannot repair member file [l:7]'ddp.mof' of Microsoft-Windows-Dedup-Common, version 10.0.14393.0, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, file is missing" should I just copy them from the repair server, or is it more complicated than that?
 

Attachments

You can use the files from the repair server and it should replace them with no issues, if you're using SFCFix but using DISM with a repair source should be okay.
 
Since my ComponentsScanner.txt file shows many CanonicalData\Catalogs missing keys, I'm wondering if it's appropriate to use SFCFixScriptBuilder --catalogs. There are still a few DerivedData/Components issues and many f! Mark Count Mismatches (some too high and some too low).

The repair server only has folders under winsxs that start with amd64, x86, msil, or wow64. It doesn't have any folders that are named with only a long hexadecmial valaue.
 
Still fighting with this server. Many of the versions of missing component packages were from KBs that are no longer listed on MS catalog. It took a long time to find direct links to those, and also to result some that can only be installed through a delta install chain that begins with a no longer published LCU. Sigh. I'm down to just a few things left that come from vc80 redist versions that are also no longer available. Running SFCFix.exe without parameters now crashes before it completes.
 
Any old updates which are long deprecated you can always just remove them using WUSA or FRST. And SFCFix shouldn't be run without any scripts since AutoAnalysis:: no longer works and hasn't for a long time.
 
I just want to confirm before I take the next action. The current status after resolving the last remaining missing DerivedData entries is:
  • The current dism version is 10.14393.4169.
  • "dism /online /Cleanup-Image /ScanHealth" completes without error.
  • "dism /online /Cleanup-Image /CheckHealth" completes without error.
  • "dism /online /Cleanup-Image /RestoreHealth" completes without error.
  • "dism /online /Cleanup-Image /AnalyzeComponentStore" completes without error. Number of reclaimable packages is 1. Component store cleanup recomeneded was Yes.
  • "dism /online /Cleanup-Image /StartComponentCleanup" took over 12 hours, went to 100%, displayed the 100% bar a second time, and then reported error 2.
  • When run a second time, it made it to 29.3% and then reported error 2 (which refers to 0x80070002). DISM.log had a message about tick count.
  • So I checked to make sure COMPONENTS hive was unloaded first and ran it one last time. This time progress bar went to 20% and reported the operation completed successfully.
  • I decided to NOT use /ResetBase because I thought that if there are any errors of any kind that were left unresolved (which there are) that it has a huge risk of causing more problems than it could fix.
  • "sfc /scannow" goes to 41% and stops.
  • CBS.log has 23 entries in the form of "[SR] Cannot repair member file <file into> of <package info> in the store, file is missing".
  • There are also a few [DIRSD OWNER EWARNING] entries that refer to DFSR which is also one of packages that are missing. I assume I can ignore these for now but will eventually want to fix them if fixing the missing package member files doesn't automatically do resolve them.
  • ComponentsScanner.txt has 181,135 missing entries in the form of "CanonicalData\Catalogs\<code> (C:\Windows\winsxs\Catalogs\<code>.cat exists but no corresponding CanonicalData\Catalogs key found)
  • ComponentsScanner.txt has 2,351 entries for "f! Mark Count Mismatch" Most of the have 0 marks and expects more, but a few show 'x' marks and expect 'y' where x is larger than y. I don't see any where x is not 0 and x is smaller than y.
Is the correct way to resolve the missing member files reported in CBS.log [SR] entries to copy the winsxs package folders from the repairserver and apply them with an SFCFix.zip file using the "{ARCHIVE} %SystemRoot%\winsxs [DIR]" command?

How should I resolve the files reported for missing CanonicalData\Catalogs that all have long hexadecimal codes instead of package names?

Should I apply the winsxs fixes for the the [SR] entries in CBS.log before trying to resolve f! or Catalogs?
 
You must log in or register to reply here.
Back
Top