[SOLVED] Windows Server 2012R2 not updating

[kogermd]

The different .NET frameworks aren't dependent on each other. Do you remember if you did a component cleanup with the reset base switch at some point? That can cause that message to appear since it merges the earlier "versions" of the COMPONENTS hive into one.

I didn't, but our hosting support may have. When we first reported that the server was not receiving/applying updates properly (thinking that it was a WSUS issue), they tried to reset the Windows Update components to get it working again. When that didn't work, they said that there was nothing that they could do and that we needed to rebuild the server (which was a last resort option for us)

Was this ComponentDetect under the Component Based Servicing in the SOFTWARE hive or the ComponentFamilies key within the COMPONENTS hive? Those are the two subkeys which I can think which have the versioning information for each component.

This was in the ComponentDetect key under the Component Based Servicing in the SOFTWARE hive.

SFCFix Script
Warning: this fix is specific to the user in this thread. No one else should follow these instructions as it may cause more harm than good. If you are after assistance, please start a thread of your own.

1. Download SFCFix.exe (by niemiro) and save this to your Desktop.
2. Download the file below, SFCFix.zip, and save this to your Desktop. Ensure that this file is named SFCFix.zip - do not rename it.
3. Save any open documents and close all open windows.
4. On your Desktop, you should see two files: SFCFix.exe and SFCFix.zip.
5. Drag the file SFCFix.zip onto the file SFCFix.exe and release it.
6. SFCFix will now process the script.
7. Upon completion, a file should be created on your Desktop: SFCFix.txt.
8. Copy (Ctrl+C) and Paste (Ctrl+V) the contents of this file into your next post for me to analyse please - put
   tags around the log to break up the text.

For reference, the file belongs to a .NET Framework 4.8 security update (KB4601058).

Thanks, this seemed to work. I'm not seeing any more errors in the CBS.log file after running this script and then running "sfc /scannow". However, I'm still not seeing any updates when checking for new updates in Windows Update - I'm not sure if it requires a system reboot in order for that to clear up or not. If so, I'll have to wait until our next scheduled maintenance to see if that is indeed resolved now.

Here's the results from running the SFCFix script:

SFCFix version 3.0.2.1 by niemiro.
Start time: 2022-04-05 07:43:17.815
Microsoft Windows Server 2012 R2  - amd64
Using .zip script file at D:\SFCFix.zip []




PowerCopy::
Successfully took permissions for file or folder C:\Windows\WinSxS\msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17105_none_71df9291f4509bd1\UIAutomationTypes.dll

WARNING: File C:\Windows\WinSxS\msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17105_none_71df9291f4509bd1\UIAutomationTypes.dll was not backed up as that would replace the current backup.
Successfully copied file C:\Users\TEMP.DC3N\AppData\Local\niemiro\Archive\msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17105_none_71df9291f4509bd1\UIAutomationTypes.dll to C:\Windows\WinSxS\msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17105_none_71df9291f4509bd1\UIAutomationTypes.dll.

Successfully restored ownership for C:\Windows\WinSxS\msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17105_none_71df9291f4509bd1\UIAutomationTypes.dll
Successfully restored permissions on C:\Windows\WinSxS\msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17105_none_71df9291f4509bd1\UIAutomationTypes.dll
PowerCopy:: directive completed successfully.




Successfully processed all directives.
SFCFix version 3.0.2.1 by niemiro has completed.
Currently storing 1 datablocks.
Finish time: 2022-04-05 07:43:23.159
----------------------EOF-----------------------

 

[x BlueRobot]

However, I'm still not seeing any updates when checking for new updates in Windows Update - I'm not sure if it requires a system reboot in order for that to clear up or not. If so, I'll have to wait until our next scheduled maintenance to see if that is indeed resolved now.

You might need to, my Windows Server 2012 R2 VM took some time to get the latest cumulative update despite manually checking for it.

This was in the ComponentDetect key under the Component Based Servicing in the SOFTWARE hive.

Okay thanks for letting me know, I would done something similar using FRST64. However, you need to be quite careful with amending things in the registry since the COMPONENTS hive and the Component Based Servicing subkey are interlinked together.

 

[kogermd]

Thanks, unfortunately a reboot still didn't resolve the issue. I went ahead and re-ran SFCFix with no update scripts and it's complaining that the last file we updated is corrupt. Here's the log file from running SFCFix:

SFCFix version 3.0.2.1 by niemiro. 
Start time: 2022-04-07 18:49:46.111
Microsoft Windows Server 2012 R2  - amd64
Not using a script file.




AutoAnalysis::
CORRUPT: C:\Windows\winsxs\msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17105_none_71df9291f4509bd1\UIAutomationTypes.dll


SUMMARY: Some corruptions could not be fixed automatically. Seek advice from helper or sysnative.com.
   CBS & SFC total detected corruption count:     1
   CBS & SFC total unimportant corruption count:  0
   CBS & SFC total fixed corruption count:        0
   SURT total detected corruption count:          0
   SURT total unimportant corruption count:       0
   SURT total fixed corruption count:             0
AutoAnalysis:: directive completed successfully.




Successfully processed all directives.
SFCFix version 3.0.2.1 by niemiro has completed.
Currently storing 0 datablocks.
Finish time: 2022-04-07 19:05:09.134
----------------------EOF-----------------------

Any idea what's going on there?

 

[x BlueRobot]

It looks like another possible registry f! mark issue. Could you please run the attached FRST64 script followed by the SFCFix script? The file itself should actually be okay but let's make sure.

 

[kogermd]

It looks like another possible registry f! mark issue. Could you please run the attached FRST64 script followed by the SFCFix script? The file itself should actually be okay but let's make sure.

Unfortunately, it looks like I'm still seeing the same issue. Attached are the Fixlog.txt and SFCFix.log files from running the two scripts. After checking to see if Windows Updates was updating (it wasn't), I then re-ran SFCFix again, and this is the output (this was after running the two previous scripts).

SFCFix version 3.0.2.1 by niemiro.
Start time: 2022-04-08 16:40:59.369
Microsoft Windows Server 2012 R2  - amd64
Not using a script file.




AutoAnalysis::
CORRUPT: C:\Windows\winsxs\msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17105_none_71df9291f4509bd1\UIAutomationTypes.dll


SUMMARY: Some corruptions could not be fixed automatically. Seek advice from helper or sysnative.com.
   CBS & SFC total detected corruption count:     1
   CBS & SFC total unimportant corruption count:  0
   CBS & SFC total fixed corruption count:        0
   SURT total detected corruption count:          0
   SURT total unimportant corruption count:       0
   SURT total fixed corruption count:             0
AutoAnalysis:: directive completed successfully.




Successfully processed all directives.
SFCFix version 3.0.2.1 by niemiro has completed.
Currently storing 1 datablocks.
Finish time: 2022-04-08 16:41:31.550
----------------------EOF-----------------------

 

[x BlueRobot]

Hmm, your registry subkey should be correct now and that is typically the cause of this issue. Could you please run SFC or DISM and see what they report?

 

[kogermd]

Okay, a couple of things here. When I initially run "dism /online /cleanup-image /restorehealth", it comes back with an error that the directory "C:\Windows does not appear to be a valid Windows directory". In troubleshooting this previously, I have identified that there are multiple version directories under C:\Windows\Servicing\Versions (6.3.9600.19750 and 6.3.9600.19991) - if I delete the 6.3.9600.19991 directory, DISM will then run correctly. I found that fix in another post here on sysnative. Attached is the DISM log from running DISM after applying this change. I was hoping that issue would be resolved once the Windows Updates are working again.

When I run "sfc /scannow", it places that folder back under C:\Windows\Servicing\Versions. From what I can tell in looking at the logs, that's the only corruption that it finds/repairs. Attached is the CBS log from running that.

A couple of other observations, and I'm not sure if any of them are related, just things that I noticed:

1. Under the WinSxS directory, there is a folder for a later version of UIAutomationTypes - msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17120_none_71e2050df44e4e5a
2. I was mistaken earlier - the registry key that I modified was in fact neither ComponentDetect under the Component Based Servicing in the SOFTWARE hive or the ComponentFamilies key within the COMPONENTS hive. It was HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\msil_uiautomationtypes_31bf3856ad364e35_none_db1206d14c69dfb1. It was missing the subkey for 4.0, which looks like it lists all of the versions installed as well as sets the current/default version (from what I can tell)
3. Under the ComponentDetect\msil_uautomationtypes key under the Component Based Servicing in the SOFTWARE hive doesn't appear to have any packages for version 4.0.9696.17120
4. The msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17120_none_71e2050df44e4e5a key under Components within the COMPONENTS hive has a value of CF = 0x200 - I know that one of our previous fixes was to remove the CF values (along with CTS and DV) for several of the msil_uiautomationtype keys under the COMPONENTS hive

 

[x BlueRobot]

2022-04-09 06:58:38, Error                 DISM   DISM OS Provider: PID=1668 TID=8524 Unable to retrieve servicing stack folder for DLL search path modification. - CDISMOSServiceManager::SetDllSearchPath(hr:0x80070003)
2022-04-09 06:58:38, Error                 DISM   DISM OS Provider: PID=1668 TID=8524 Unable to set the DLL search path to the servicing stack folder. C:\Windows may not point to a valid Windows folder. - CDISMOSServiceManager::SetWindowsDirectory(hr:0x80070003)
2022-04-09 06:58:38, Error                 DISM   DISM.EXE: Failed to set the windows directory to 'C:\Windows'. HRESULT=80070003

That error means your servicing stack has become corrupt, could you please provide your CBS hive using the following instructions:

Step#1 - Export CBS hive

• Click on the Start button and in the search box, type regedit
• When you see regedit on the list, right-click on it and select Run as administrator.
• 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\Component Based Servicing
• Once selected, click File > Export....
• Change the Save as type: to Registry Hive Files (.).
• Name this file ComponentBasedServicing (with no file extension) and save it to your Desktop.
• Right-click on the saved file and choose Send To -> Compressed (zipped) Folder.
• Attach the .ZIP file to your next post.
• If the file is too large to upload here, upload to Dropbox or OneDrive or SendSpace and just provide the link here.

 

[x BlueRobot]

I have identified that there are multiple version directories under C:\Windows\Servicing\Versions (6.3.9600.19750 and 6.3.9600.19991) - if I delete the 6.3.9600.19991 directory, DISM will then run correctly.

The Version directories contains references to each version of your servicing stack. You delete those folders for a slightly different DISM error.

When I run "sfc /scannow", it places that folder back under C:\Windows\Servicing\Versions. From what I can tell in looking at the logs, that's the only corruption that it finds/repairs.

SFC is probably pulling the corrupted version from your WinSxS folder back into the Version folder and believes that it's resolved the issue.

It was HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\msil_uiautomationtypes_31bf3856ad364e35_none_db1206d14c69dfb1. It was missing the subkey for 4.0, which looks like it lists all of the versions installed as well as sets the current/default version (from what I can tell)

Okay, the Winners key is used to find the "winning" or active version of a given component. It's linked to the ComponentFamilies subkey found in the COMPONENTS hive. The WinSxS folder will contain multiple versions of the same component, the older versions are usually cleaned up automatically once Windows schedules the scavenger task to run.

Under the ComponentDetect\msil_uautomationtypes key under the Component Based Servicing in the SOFTWARE hive doesn't appear to have any packages for version 4.0.9696.17120

Hmm, it shouldn't cause any problems and haven't seen any errors regarding it, so I wouldn't worry about it for now. Let's focus on getting the DISM working consistently with no errors.

The msil_uiautomationtypes_31bf3856ad364e35_4.0.9696.17120_none_71e2050df44e4e5a key under Components within the COMPONENTS hive has a value of CF = 0x200 - I know that one of our previous fixes was to remove the CF values (along with CTS and DV) for several of the msil_uiautomationtype keys under the COMPONENTS hive

If the file isn't compressed then it may cause problems, however, I can't see any errors related to that particular component at the moment so we've leave it for now.

 

[kogermd]

That error means your servicing stack has become corrupt

It wouldn't surprise me if that was the case... I know that there was a SSU update for Windows 2012 R2 back in April 2021 (KB5001403) and the server stopped receiving expected updates starting in May. I also don't see that KB installed on the server either in the Installed Updates or when running Get-Hotfix with the KB number.

I have uploaded the Component Based Servicing registry hive file here: ComponentBasedServicing.zip

Also, thanks for those explanations in the last response. That was very informative, I still don't understand all the ins and outs of the WinSxS, Components, etc but I understand a little bit more now than I did going into all of this.

 

[x BlueRobot]

Your current SSU is from KB4566425 (July 2020) which corresponds to SSU version 6.3.9600.19750. You can actually find your current SSU version by checking the Version subkey of the CBS hive. It should have one value which is the version number and then the corresponding WinSxS folder which is what we're replacing in this fix.

I'm surprised deleting the other version managed to get DISM running somewhat? Could you please run the attached SFCFix zip and then try DISM again?

I know that there was a SSU update for Windows 2012 R2 back in April 2021 (KB5001403) and the server stopped receiving expected updates starting in May. I also don't see that KB installed on the server either in the Installed Updates or when running Get-Hotfix with the KB number.

Your current SSU is much older, wonder if something went wrong when it was trying to update to the newer SSU?

That was very informative, I still don't understand all the ins and outs of the WinSxS, Components, etc but I understand a little bit more now than I did going into all of this.

We're always learning new things about it too, Microsoft have changed things here and there, but it seems to be largely unchanged since Windows Vista.

 

[kogermd]

Your current SSU is from KB4566425 (July 2020) which corresponds to SSU version 6.3.9600.19750. You can actually find your current SSU version by checking the Version subkey of the CBS hive. It should have one value which is the version number and then the corresponding WinSxS folder which is what we're replacing in this fix.

I'm surprised deleting the other version managed to get DISM running somewhat? Could you please run the attached SFCFix zip and then try DISM again?

I ran SFCFix with the last SFCFix.zip that you attached. Attached is the results of running that. I tried running DISM right after, but received the same error regarding "The directory C:\Windows does not appear to be a valid Windows directory" that I was receiving before. I then tried deleting the 6.3.9600.19991 folder under C:\Windows\Servicing\Version and then DISM ran successfully. I then tried to run "sfc /scannow" and it placed the same 6.3.9600.19991 folder back under C:\Windows\Servicing\Version. Here's the portion of the CBS.log file that referenced that:

2022-04-12 08:19:15, Info                  CSI    00001594 [SR] Verify complete
2022-04-12 08:19:15, Info                  CSI    00001595 [SR] Verifying 24 (0x0000000000000018) components
2022-04-12 08:19:15, Info                  CSI    00001596 [SR] Beginning Verify and Repair transaction
2022-04-12 08:19:16, Info                  CSI    00001597 [SR] Verify complete
2022-04-12 08:19:16, Info                  CSI    00001598 [SR] Repairing 1 components
2022-04-12 08:19:16, Info                  CSI    00001599 [SR] Beginning Verify and Repair transaction
2022-04-12 08:19:17, Info                  CSI    0000159a [SR] Repairing corrupted file [ml:520{260},l:94{47}]"\??\C:\Windows\Servicing\Version\6.3.9600.19991"\[l:26{13}]"x86_installed" from store
2022-04-12 08:19:17, Info                  CSI    0000159b [SR] Repair complete
2022-04-12 08:19:17, Info                  CSI    0000159c [SR] Committing transaction
2022-04-12 08:19:17, Info                  CSI    0000159d Creating NT transaction (seq 2), objectname [6]"(null)"
2022-04-12 08:19:17, Info                  CSI    0000159e Created NT transaction (seq 2) result 0x00000000, handle @0x1774
2022-04-12 08:19:17, Info                  CSI    0000159f@2022/4/12:15:19:17.435 Beginning NT transaction commit...
2022-04-12 08:19:17, Info                  CSI    000015a0@2022/4/12:15:19:17.457 CSI perf trace:

One thing that I noticed is that it's placing the "x86_installed" file under that 6.3.9600.19991 folder. In the 6.3.9600.19750 folder that also exists, there is only an "amd64_installed" file. I checked a working Windows 2012 R2 server that we have, and it has both an "x86_installed" and an "amd64_installed" file under the 6.3.9600.19991 folder.

 

[x BlueRobot]

It does seem that something is wrong with that particular folder and "store" in the CBS log refers to the WinSxS folder. Just did some further investigation, for some reason, your ComponentDetect key doesn't have any reference to 6.3.9600.19991? And it just so happens that, that particular SSU is actually part of the KB5001403 update which you mentioned earlier. Something really odd has happened during that update.

I think the best approach will be to attempt to remove KB5001403 using WUSA and then ensure that the 6.3.9600.19750 folder under servicing\Version has both files amd64_installed and x86_installed (it should have both):

SFCFix Script

Warning: this fix is specific to the user in this thread. No one else should follow these instructions as it may cause more harm than good. If you are after assistance, please start a thread of your own.

1. Download SFCFix.exe (by niemiro) and save this to your Desktop.
2. Download the file below, SFCFix.zip, and save this to your Desktop. Ensure that this file is named SFCFix.zip - do not rename it.
3. Save any open documents and close all open windows.
4. On your Desktop, you should see two files: SFCFix.exe and SFCFix.zip.
5. Drag the file SFCFix.zip onto the file SFCFix.exe and release it.
6. SFCFix will now process the script.
7. Upon completion, a file should be created on your Desktop: SFCFix.txt.
8. Copy (Ctrl+C) and Paste (Ctrl+V) the contents of this file into your next post for me to analyse please - put [CODE][/CODE] tags around the log to break up the text.

Remove Update Manually
1. Click on the Start button and in the search box, type Command Prompt
2. When you see Command Prompt on the list, right-click on it and select Run as administrator
3. When command prompt opens, copy and paste the following command into it, and press Enter
wusa /uninstall /KB:5001403

There should only really be one folder in your servicing\Version folder and that would be your current SSU version which is 6.3.9600.19750 folder.

 

[kogermd]

No luck. Attached is the SFCFix log after running the SFCFix script. That ran fine, and I see both the amd64_installed and x64_installed files under the 6.3.9600.19750 folder in C:\Windows\Servicing\Version (and the 6.3.9600.19991 folder is gone).

I then attempted to uninstall the KB5001403 using wusa and received an error message that the update is not installed. I then attempted to install the KB on the server and received a message that the KB is not applicable to the server. I also tried installing using wusa and dism with similar results.

I ran DISM and SFC, and after running SFC, the 6.3.9600.19991 folder is back under C:\Windows\Servicing\Version (with only the x86_installed file).

 

[x BlueRobot]

Let's search your registry for the update using FRST64:

FRST Registry Search
1. Click your Start button and type in cmd.
2.After you find the Command Prompt, right click on it and select Run as Administrator.
3. Copy and paste the following into the Command Prompt:
reg load HKLM\COMPONENTS C:\WINDOWS\SYSTEM32\CONFIG\COMPONENTS
4. Please download Farbar Recovery Scan Tool and save it to your Desktop.
Note: You need to run the 64-bit Version so please ensure you download that one.
5. Run FRST64 by Right-Clicking on the file and choosing Run as administrator.
6. Copy and paste KB5001403 into the Search box and click the Search Registry button.
7. When the scan is complete a notepad window will open with the results. Please attach this to your next reply. It is saved on your desktop named SearchReg.txt.

 

[kogermd]

Thanks, attached is the results of searching the registry with FRST64.

 

[x BlueRobot]

Ah, I see! It looks like part of the update still exists in your registry which explains why you couldn't install it and why SFC keeps pulling in that Version folder from the WinSxS folder. Let's remove the leftover remnants using FRST64.

Step#1 - FRST Fix
NOTICE: This script was written specifically for this user, for use on that particular machine. Running this on another machine may cause damage to your operating system
1. Please download Farbar Recovery Scan Tool and save it to your Desktop.
Note: You need to run the 64-bit Version so please ensure you download that one.
2. Download the attached fixlist.txt and save it to the Desktop.
Note. It's important that both files, FRST64 and fixlist.txt are in the same location or the fix will not work (in this case...the desktop).
3. Run FRST64 by Right-Clicking on the file and choosing Run as administrator.
4. Press the Fix button just once and wait. If for some reason the tool needs a restart, please make sure you let the system restart normally. After that let the tool complete its run.
5. When finished FRST64 will generate a log on the Desktop (Fixlog.txt). Please post the contents of it in your reply.

If it's successful, then please remove the 6.3.9600.19991 folder from Version as you did before and then run DISM. When you run SFC (/scannow), the folder shouldn't get replaced this time.

 

[kogermd]

I was very hopeful that we might finally have the solution. I ran FRST with the fixlist that you provided. Here are the results from that:

Fix result of Farbar Recovery Scan Tool (x64) Version: 20-03-2022
Ran by Michael.Koger (15-04-2022 14:54:25) Run:6
Running from D:\
Loaded Profiles: svc.sql.prd.engine & svc.sql.prd.agent & svc.sql.prd.ssas & Michael.Koger & MSSQLFDLauncher$NAVATFPAR
Boot Mode: Normal
==============================================

fixlist content:
*****************
CMD: REG LOAD HKLM\COMPONENTS C:\Windows\System32\config\COMPONENTS
CreateRestorePoint:
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\2ec66b6dd30..ba736caca43_31bf3856ad364e35_6.3.9600.19991_f8000f31d5a1ec19|p!CBS_package_22_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_7edc3ff180b7c05e
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\2ec66b6dd30..ba736caca43_31bf3856ad364e35_6.3.9600.19991_f8000f31d5a1ec19|s!CBS_package_22_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_7edc3ff180b7c05e
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\2ec66b6dd30..ba736caca43_31bf3856ad364e35_6.3.9600.19991_f8000f31d5a1ec19|i!CBS_package_22_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_7edc3ff180b7c05e
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\b7365634fa8..9e33c96e24f_31bf3856ad364e35_6.3.9600.19991_a2ff854248b50b4a|p!CBS_package_16_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_a352ad9944425036
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\b7365634fa8..9e33c96e24f_31bf3856ad364e35_6.3.9600.19991_a2ff854248b50b4a|s!CBS_package_16_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_a352ad9944425036
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\b7365634fa8..9e33c96e24f_31bf3856ad364e35_6.3.9600.19991_a2ff854248b50b4a|i!CBS_package_16_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_a352ad9944425036
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\c6689d4e730..5e4bfc79fcc_31bf3856ad364e35_6.3.9600.19991_3f75ba6a149c6a3a|p!CBS_package_14_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_689c9c5beb194dc6
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\c6689d4e730..5e4bfc79fcc_31bf3856ad364e35_6.3.9600.19991_3f75ba6a149c6a3a|s!CBS_package_14_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_689c9c5beb194dc6
DeleteValue: HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\c6689d4e730..5e4bfc79fcc_31bf3856ad364e35_6.3.9600.19991_3f75ba6a149c6a3a|i!CBS_package_14_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_689c9c5beb194dc6
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ApplicabilityEvaluationCache\Package_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1]
DeleteValue: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect\amd64_microsoft-windows-s..ingstack-base-extra_31bf3856ad364e35_0.0.0.0_none_9efd7c4ec3db3fc9|Package_16_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1.5001403-16_neutral_GDR
DeleteValue: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect\x86_microsoft-windows-servicingstack_31bf3856ad364e35_0.0.0.0_none_2d3956f60f74b69a|Package_14_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1.5001403-14_neutral_GDR
DeleteValue: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Windows-ServicingStack-Base-CrossArch-Package~31bf3856ad364e35~amd64~~0.0.0.0|Package_14_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Package_22_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1]

*****************


========= REG LOAD HKLM\COMPONENTS C:\Windows\System32\config\COMPONENTS =========

The operation completed successfully.


========= End of CMD: =========

Error: (0) Failed to create a restore point.
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\2ec66b6dd30..ba736caca43_31bf3856ad364e35_6.3.9600.19991_f8000f31d5a1ec19\\p!CBS_package_22_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_7edc3ff180b7c05e" => removed successfully
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\2ec66b6dd30..ba736caca43_31bf3856ad364e35_6.3.9600.19991_f8000f31d5a1ec19\\s!CBS_package_22_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_7edc3ff180b7c05e" => removed successfully
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\2ec66b6dd30..ba736caca43_31bf3856ad364e35_6.3.9600.19991_f8000f31d5a1ec19\\i!CBS_package_22_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_7edc3ff180b7c05e" => removed successfully
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\b7365634fa8..9e33c96e24f_31bf3856ad364e35_6.3.9600.19991_a2ff854248b50b4a\\p!CBS_package_16_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_a352ad9944425036" => removed successfully
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\b7365634fa8..9e33c96e24f_31bf3856ad364e35_6.3.9600.19991_a2ff854248b50b4a\\s!CBS_package_16_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_a352ad9944425036" => removed successfully
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\b7365634fa8..9e33c96e24f_31bf3856ad364e35_6.3.9600.19991_a2ff854248b50b4a\\i!CBS_package_16_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_a352ad9944425036" => removed successfully
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\c6689d4e730..5e4bfc79fcc_31bf3856ad364e35_6.3.9600.19991_3f75ba6a149c6a3a\\p!CBS_package_14_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_689c9c5beb194dc6" => removed successfully
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\c6689d4e730..5e4bfc79fcc_31bf3856ad364e35_6.3.9600.19991_3f75ba6a149c6a3a\\s!CBS_package_14_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_689c9c5beb194dc6" => removed successfully
"HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\c6689d4e730..5e4bfc79fcc_31bf3856ad364e35_6.3.9600.19991_3f75ba6a149c6a3a\\i!CBS_package_14_for_kb5001403~31bf3856ad364e35~amd64~~6.3.1.1.500_689c9c5beb194dc6" => removed successfully
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ApplicabilityEvaluationCache\Package_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1 => removed successfully
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect\amd64_microsoft-windows-s..ingstack-base-extra_31bf3856ad364e35_0.0.0.0_none_9efd7c4ec3db3fc9\\Package_16_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1.5001403-16_neutral_GDR" => removed successfully
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect\x86_microsoft-windows-servicingstack_31bf3856ad364e35_0.0.0.0_none_2d3956f60f74b69a\\Package_14_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1.5001403-14_neutral_GDR" => removed successfully
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Windows-ServicingStack-Base-CrossArch-Package~31bf3856ad364e35~amd64~~0.0.0.0\\Package_14_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1" => removed successfully
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Package_22_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1 => removed successfully

==== End of Fixlog 14:54:26 ====

I then removed the 6.3.9600.19991 folder from Version and ran DISM and SFC. Unfortunately, at the end of it all, the 6.3.9600.19991 folder showed back up under Version. I then ran FRST again to check the registry for instances of KB5001403 and this was the results from that:

Farbar Recovery Scan Tool (x64) Version: 20-03-2022
Ran by Michael.Koger (15-04-2022 22:30:56)
Running from D:\
Boot Mode: Normal

================== Search Registry: "KB5001403" ===========

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ApplicabilityEvaluationCache\Package_for_KB5001403~31bf3856ad364e35~amd64~~6.3.1.1]

====== End of Search ======

I modified the fixlist.txt that you provided to only remove that one instance in the registry and reran FRST. I then ran another registry scan with FRST to verify that it wasn't showing up in the registry anymore. I then ran DISM and SFC again, and the 6.3.9600.19991 folder still came back (I had removed it prior to running DISM). I scanned the registry again for KB5001403 with FRST, and I still don't see any more instances of it. Attached is the CBS log from my attempts yesterday.

 

[x BlueRobot]

I was very hopeful that we might finally have the solution.

Don't worry, we'll get there. Could you please run the following:

SFCFixScript.txt

Warning: this fix is specific to the user in this thread. No one else should follow these instructions as it may cause more harm than good. If you are after assistance, please start a thread of your own.

1. Download SFCFix.exe (by niemiro) and save this to your Desktop.
2. Download the attached file, SFCFixScript.txt, and save this to your Desktop. Ensure that this file is named SFCFixScript.txt - do not rename it.
3. Save any open documents and close all open windows.
4. On your Desktop, you should see two files: SFCFix.exe and SFCFixScript.txt.
5. Drag the file SFCFixScript.txt onto the file SFCFix.exe and release it.
6. SFCFix will now process the script.
7. Upon completion, a log should be created on your Desktop: SFCFix.txt.
8. Copy (Ctrl+C) and Paste (Ctrl+V) the contents of this into your next post for me to analyse please - put [CODE][/CODE] tags around the log to break up the text.[/list]
   
   One or two of the folders/keys may not exist so don't worry if it says it couldn't delete them. Afterwards, please delete the 6.3.9600.19991 from Version and then run SFC as you did before. If the folder doesn't reappear then follow up with DISM, otherwise please let me know.

 

[kogermd]

Alright, it definitely looks like we're starting to make some progress now. When I first ran the SFCFixScript, it threw an error when trying to delete C:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.19991_none_9df11c11e2ef1b5b:

SFCFix version 3.0.2.1 by niemiro.
Start time: 2022-04-17 21:00:06.818
Microsoft Windows Server 2012 R2  - amd64
Using .txt script file at D:\SFCFixScript.txt []




RegistryScript::
Successfully took ownership and permissions for registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components.
Successfully took ownership and permissions for registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.19991_none_9df11c11e2ef1b5b.

Successfully deleted registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.19991_none_fa0fb7959b4c8c91.
Successfully deleted registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.19991_none_9df11c11e2ef1b5b.

Successfully restored ownership and permissions for registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components.
Failed to open registry key HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.19991_none_9df11c11e2ef1b5b with error code ERROR_FILE_NOT_FOUND.
RegistryScript:: directive failed to complete successfully.




Delete::
WARNING: No files or folders matched deletion pattern C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.19991_none_fa0fb7959b4c8c91.
Failed to delete all files and folders matching pattern C:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.3.9600.19991_none_9df11c11e2ef1b5b with result code 2.
Delete:: directive failed to complete successfully.




Failed to process all directives successfully.
SFCFix version 3.0.2.1 by niemiro has completed.
Currently storing 2 datablocks.
Finish time: 2022-04-17 21:00:10.580
----------------------EOF-----------------------

I took ownership if that folder and then reran the SFCFixScript with SFCFix, and it removed the folder the second time around. I then deleted the 6.3.9600.19991 folder and re-ran SFC which didn't find any integrity violations. The folder didn't come back this time, so then I re-ran DISM. It still didn't pop back up, so that's definitely promising. I tried running Windows Update, but it's still showing that I don't have any updates pending.