How to solve Components Scanner reporting thousands of missing registry keys

mjmeans said:
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
Click to expand...
Hi,

There will be a log file at %localappdata%\Sysnative\ComponentsScanner.log which will contain the same log messages printed to the console.
 
So I'm confused about what is happening here. Looking at a single key that SFCFix would be correcting and the data flow through its ultimate failure. THis is an excerpt of a single key out of about 2300 that aren't importing for some reason.

Code: 
==== ComponentsScanner.txt had
Key:        ROOT\DerivedData\Components\amd64_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_10.0.14393.0_none_763a99f4d581495c
Value:        identity
Type:        RegBinary
Data:        Microsoft-Windows-Application-Experience-Program-Compatibility-Assistant-UI, Culture=neutral, Version=10.0.14393.0, PublicKeyToken=31bf3856ad364e35, ProcessorArchite
Data (raw):    4D-69-63-72-6F-73-6F-66-74-2D-57-69-6E-64-6F-77-73-2D-41-70-70-6C-69-63-61-74-69-6F-6E-2D-45-78-70-65-72-69-65-6E-63-65-2D-50-72-6F-67-72-61-6D-2D-43-6F-6D-70-61-74-69-62-69-6C-69-74-79-2D-41-73-73-69-73-74-61-6E-74-2D-55-49-2C-20-43-75-6C-74-75-72-65-3D-6E-65-75-74-72-61-6C-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-06
Suggestion:    Microsoft-Windows-Application-Experience-Program-Compatibility-Assistant-UI, Culture=neutral, 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-41-70-70-6C-69-63-61-74-69-6F-6E-2D-45-78-70-65-72-69-65-6E-63-65-2D-50-72-6F-67-72-61-6D-2D-43-6F-6D-70-61-74-69-62-69-6C-69-74-79-2D-41-73-73-69-73-74-61-6E-74-2D-55-49-2C-20-43-75-6C-74-75-72-65-3D-6E-65-75-74-72-61-6C-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-53

==== Missingcomponents.txt had:
amd64_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_10.0.14393.0_none_763a99f4d581495c

==== SFCFixScript.txt had:
::
[HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\amd64_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_10.0.14393.0_none_763a99f4d581495c]
"S256H"=hex:39,b9,ba,74,62,35,0d,d2,ee,9f,c9,04,0d,2d,ac,dd,5c,79,ee,5d,01,e4,c8,0c,d1,a0,22,be,7e,20,9a,04
"identity"=hex:4d,69,63,72,6f,73,6f,66,74,2d,57,69,6e,64,6f,77,73,2d,41,70,70,6c,69,63,61,74,69,6f,6e,2d,45,78,70,65,72,69,65,6e,63,65,2d,50,72,6f,67,72,61,6d,2d,43,6f,6d,70,61,74,69,62,69,6c,69,74,79,2d,41,73,73,69,73,74,61,6e,74,2d,55,49,2c,20,43,75,6c,74,75,72,65,3d,6e,65,75,74,72,61,6c,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,53
"c!microsoft-w..-deployment_31bf3856ad364e35_10.0.14393.0_e2d0267a19b1e3a7"=hex:
"c!microsoft-w..-deployment_31bf3856ad364e35_10.0.14393.0_60269d1915f7c7d4"=hex:
"f!pcacli.dll"=dword:00000001
"f!pcaui.dll"=dword:00000001

==== SFCFix.log had:
Successfully took ownership and permissions for registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\amd64_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_10.0.14393.0_none_763a99f4d581495c.
Successfully imported registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\amd64_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_10.0.14393.0_none_763a99f4d581495c.
Successfully restored ownership and permissions for registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\amd64_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_10.0.14393.0_none_763a99f4d581495c.

After this was processed, the machine was restarted and ComponentsScanner was run again. It came up with the same reported issue with this key. I then examined COMPONENTS directly in RegEdit and verified that the corrupted key is still there (and still corrupted). What could be happening here and am I doing something wrong?

I originally thought maybe disk space, but no. This server's system drive is 127 GB with 29 GB free.
 
So to try to find out why SFCFix was saying it was successful, but in fact the key was still corrupted, I decided to edit the SFCFixScript.txt to have only that key fix block in it. I watched Resource Monitor while running SFCFix to see which processes were accessing COMPONENTS. SFCFix reported that it applied the fix and that it was successful. Resource monitor showed COMPONENTS was opened by SFCFix, MsMpEng and System. SFCFix remained running and having COMPONENTS opened for several minutes before I then thought that perhaps it wasn't releasing COMPONENTS because SFCFix was still running, and that could happen if SFCFix opened a shell to pop-up the log in notepad. Shortly after I closed that, then SFCFix closed and it then disappeared from Resource Monitor access of the COMPONENTS. I then opened regedit and examined the key. The COMPONENTS hive was still loaded under HKLM, to apparently SFCFix is not unloading it when it completes. But more importantly, the registry key was not in fact updated as SFCFix reported. I then checked again after a reboot. No joy.

I tried SFCFix multiple times with just this one registry fix and the results were the same. The key was not actually being updated in COMPONENTS.

I then used SystInternals
HTML: 
handle.exe -a COMPONENTS
to try to see some more information about what is happening. Here is its output:
Code: 
System             pid: 4      type: File          211C: C:\Windows\System32\config\COMPONENTS.LOG2
System             pid: 4      type: File          214C: C:\Windows\System32\config\COMPONENTS.LOG1
System             pid: 4      type: File          2280: C:\Windows\System32\config\COMPONENTS{5a78f164-4b54-11e6-80cb-e41d2d012050}.TMContainer00000000000000000002.regtrans-ms
System             pid: 4      type: File          22A8: C:\Windows\System32\config\COMPONENTS{5a78f164-4b54-11e6-80cb-e41d2d012050}.TM.blf
System             pid: 4      type: File          22FC: C:\Windows\System32\config\COMPONENTS
System             pid: 4      type: File          2764: C:\Windows\System32\config\COMPONENTS{5a78f164-4b54-11e6-80cb-e41d2d012050}.TMContainer00000000000000000001.regtrans-ms
winlogon.exe       pid: 820    type: Key            198: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\GPClient
winlogon.exe       pid: 820    type: Key            28C: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\NTDS
winlogon.exe       pid: 820    type: Key            290: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\Profiles
winlogon.exe       pid: 820    type: Key            294: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\Sens
winlogon.exe       pid: 820    type: Key            298: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\SessionEnv
winlogon.exe       pid: 820    type: Key            29C: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\TermSrv
winlogon.exe       pid: 6280   type: Key            18C: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\NTDS
winlogon.exe       pid: 6280   type: Key            1B4: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\SessionEnv
winlogon.exe       pid: 6280   type: Key            1C4: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\GPClient
winlogon.exe       pid: 6280   type: Key            270: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\Sens
winlogon.exe       pid: 6280   type: Key            29C: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\Profiles
winlogon.exe       pid: 6280   type: Key            2A0: HKLM\SYSTEM\ControlSet001\Control\Winlogon\Notifications\Components\TermSrv

I watched this for several minutes. I'm guessing that something is preventing the *.regtrans-ms file from being applied to COMPONENTS. Looking at the config folder, I see several other older *.regtrans-ms files. I'm wondering if a corruption in the older files is preventing the update of these keys
Code: 
c:\Windows\System32\config>dir /a COMPO*
 Volume in drive C is System
 Volume Serial Number is A8DA-C007

 Directory of c:\Windows\System32\config

06/13/2023  03:49 PM       122,421,248 COMPONENTS
07/15/2016  11:04 PM         4,194,304 COMPONENTS.LOG1
07/15/2016  11:04 PM        28,619,776 COMPONENTS.LOG2
03/22/2022  10:03 AM         1,048,576 COMPONENTS{5a78f163-4b54-11e6-80cb-e41d2d012050}.TxR.0.regtrans-ms
03/22/2022  10:03 AM         1,048,576 COMPONENTS{5a78f163-4b54-11e6-80cb-e41d2d012050}.TxR.1.regtrans-ms
03/22/2022  10:03 AM         1,048,576 COMPONENTS{5a78f163-4b54-11e6-80cb-e41d2d012050}.TxR.2.regtrans-ms
03/22/2022  10:03 AM            65,536 COMPONENTS{5a78f163-4b54-11e6-80cb-e41d2d012050}.TxR.blf
06/11/2023  04:12 PM            65,536 COMPONENTS{5a78f164-4b54-11e6-80cb-e41d2d012050}.TM.blf
06/11/2023  04:12 PM           524,288 COMPONENTS{5a78f164-4b54-11e6-80cb-e41d2d012050}.TMContainer00000000000000000001.regtrans-ms
09/14/2022  02:41 AM           524,288 COMPONENTS{5a78f164-4b54-11e6-80cb-e41d2d012050}.TMContainer00000000000000000002.regtrans-ms
              10 File(s)    159,560,704 bytes
               0 Dir(s)  31,197,515,776 bytes free


BTW, if I was right about the reason SFCFix kept running was because it opened the notepad process as a child process, then that could be prevented if SFCFix was updated to open the notepad process using UseShellExecute = true.
 
As a test, I exported the COMPONENTS\DerivedData\Components\amd64_microsoft-windows-a..bility-assistant-ui_31bf3856ad364e35_10.0.14393.0_none_763a99f4d581495c key to a .reg file, edited it to have the right identity data, then imported it from the command line. I did not know what to do with the c! and f! commands in the SFCFixScript file so I left those alone. I then ran ComponentsChecker again. This time it reported 1 fewer corruptions. Since SFCFix doesn't seem to be fixing these identities, should I do these manually? And what should I do about the c! and f!?
 
There is one other difference between this server and the repairserver vm that I noticed when running resource monitor. On the disk activity tab it reports file accesses of files on C:\* as F:1\* and files on D:\* as F:2\*. The system does also have an F:\ drive, but none of those files are open. When I do
CSS: 
c:\sysinterals\handle -a C:\
I see normal file paths. Does resource monitor reporting C: and D: file paths as F:1 and F:2 paths have anything to do with windows update or repair failing?
 
mjmeans said:
I watched this for several minutes. I'm guessing that something is preventing the *.regtrans-ms file from being applied to COMPONENTS. Looking at the config folder, I see several other older *.regtrans-ms files. I'm wondering if a corruption in the older files is preventing the update of these keys
Click to expand...
Those transaction log files are just used for logging purposes and to enable the system to rollback any changes during failures. I wouldn't use Resource Monitor for looking at file/registry access either, Process Monitor is a far better tool to use and has good filtering capabilities as well.

This article provides some good information about those files: Digging Up the Past: Windows Registry Forensics Revisited | Mandiant

mjmeans said:
Does resource monitor reporting C: and D: file paths as F:1 and F:2 paths have anything to do with windows update or repair failing?
Click to expand...
No, that shouldn't cause the problems that you're experiencing. Could you please provide your COMPONENTS hive? I think I've got the C# code I used for directly modifying the hive using the data from the ComponentScanner.txt file. It only updated the identity value though since that is the one which seems to always cause this problem. Once I've tested it works (it always used to), I'll write it up as .exe for you and post the source code to GitHub.
 
Thanks and no, it only appears to happen with the identity value for some reason. I'm not completely sure why though?
 
I've been a programmer since the mid 80's in DOS (in MASM, C, BASIC and VB-DOS) and have written over a million lines of Windows desktop app code mostly in VB.net but also C# and C++. I am curious what you find. The strange thing is that the final character is wrong and different for each truncated identity. Some kind of checksum value, maybe?
 
As for the F:2/ and F:1/ issue with Resource Monitor, this appears to only happen when there are more than 10 assigned drive letters. A forum post elsewhere suggested that some legacy code incorrectly assumed that device paths such "\device\harddisk1\Windows" couldn't possibly go higher than 9 (such as "\device\harddisk12\Windows") making the string larger than expected. And hence only allocated enough characters for a single digit in the portion of code that looks up a drive letter. So "\device\harddisk10", etc. results in things like E:0\Windows or E:1\Windows, etc. Seems logical. My alternate view if an array limit was the cause is that the legacy code didn't use array length checking at all (and didn't have that bug) but an automated tool imposed during one of the rounds of protecting code from overflow exploits caused it and nobody initially noticed the weird result.
 
Oh, I was anticipating a fix for SFCFix. But anyway, I wasn't able to load the project as posted. SDK Resolver issue. I have VS 2017, 2019 and 2022 (and VS code) loaded on my dev machine. The multiple VS versions is probably the cause. Time for a round of repairing VS versions. Or maybe I'll just spin up a new VM with only VS 2022 in it. I'm thinking of adding a VS2017 project to target .Net 4 to be able to also run on base Windows 7 and server 2008 machines that never installed later versions of .Net. I'll send a merge request with my suggested changes later today after I test it. Thanks.
 
It targets .NET 7 but should work with .NET 5, was there a .NET 4? I thought they went from .NET 3.1 and then jumped to .NET 5?

I'll probably have a look at what is happening with SFCFixScriptBuilder, there's possibly something being added which is then causing it to get truncated. I can't remember if there is a character limit on the identity value?
 
Yeah, there was a .NET 4, and a 4.5 and maybe a 4.6. I started programming Windows apps in VS 2003 which had .NET 1.1, IIRC. Okay, so I just looked it up while typing this, yes there was even a 4.7 and 4.8.
 
Oh you mean .NET Framework, I know what you mean now. That ended with .NET Framework 4.8 then they moved onto .NET Core with the last version being .NET Core 3.1. Now, confusingly, they refer to everything onwards as .NET, with .NET 5 being the oldest and I think .NET 8 is the latest official release?
 
Repo still won't load after repairing and updating VS versions.
Code: 
The SDK resolver type "DotNetMSBuildSdkResolver" failed to load. The type initializer for 'Microsoft.DotNet.DotNetSdkResolver.VSSettings' threw an exception.

It's not the common preview SDK being the cause of the problem. Preview isn't installed.

I'm gonna spin up a new VM and install VS 2022 Community. I don't own VS 2022 Pro, the latest Pro version I own is 2019.
 
There are two projects that share source. The .net45 version links the .cs files from the main version and uses conditional compilation. I don't think it's a good idea to have both projects in the same solution. There are a number of reasons for this, including 1) Microsoft has changed the way SDKs are installed and registered a couple times over the years with the different versions of VS, which can result in conflicts if someone also has older versions of VS installed; 2) dotNet Framework 4.5 development is not supported in VS 2022, so you wouldn't be able to do it in VS 2022 at all unless there is third-party add-in that does it (fewer third-party pre-compiled tools is better for security reasons).

Strangely, you can still target dotNet Framework 3.5 in VS 2022. So that might be an option at least until VS 2024 comes out. Might be a short-lived solution option. Overall, I think it's just cleaner to have a solution that will target dotNET 4.5 with a version of VS that was designed for dotNet 4.5 rather than crowbarred in as an afterthought while MS tries to push everyone into store apps or whatever other "latest thing" they decide makes more money for them.

Back to my repairs... I've run the .net45 version I wrote from within VS 2015 that I installed on the failing server. Everything seems to be fine. ComponentsScanner reports there are no longer any corrupt data values reported. However, there are still many missing registry keys. I've run SFCFixScriptBuilder against the RepairServer's components hive and has fixes. They look very much like the fixes that were failing. Shough in this case these keys aren't corrupted, they are missing entirely.

Code: 
[HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\amd64_microsoft-windows-a..ce-router.resources_31bf3856ad364e35_10.0.14393.0_en-us_f5b7dccae19b1b6d]
"S256H"=hex:4c,65,aa,b4,b3,b4,f4,b5,92,19,76,ad,ed,c1,06,bc,c2,a6,a3,2b,e4,f8,2b,ad,1f,24,6b,b0,32,d6,45,d3
"identity"=hex:4d,69,63,72,6f,73,6f,66,74,2d,57,69,6e,64,6f,77,73,2d,41,63,74,69,76,65,2d,44,69,72,65,63,74,6f,72,79,2d,53,65,72,76,69,63,65,73,2d,49,6e,74,65,72,66,61,63,65,2d,52,6f,75,74,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,53
"c!microsoft-w..anguagepack_31bf3856ad364e35_10.0.14393.0_de9c1f16a4cb45d1"=hex:
"c!microsoft-w..anguagepack_31bf3856ad364e35_10.0.14393.0_16d3203beb22b10b"=hex:
"f!activeds.dll.mui"=dword:00000001

I checked this key and it does actually exist and has an identity and S256H value. It does not have the c! or f! values.

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?
 
You must log in or register to reply here.
Back
Top