[SOLVED] Windows Server 2019 Standard - Can't Install Updates - SFC Aborts @ 44%

[soj4trade]

Howdy. I was wondering if perhaps you brilliant folks could have a look at one of my servers that's misbehaving. The symptom is that Windows Updates fail to install. A classic symptom. One of my favorites.

DISM /Online /Cleanup-Image /RestoreHealth succeeds with The restore operation completed successfully.

SFC /SCANNOW consistently reaches 44% before failing with Windows Resource Protection could not perform the requested operation.

I have some experience analyzing CBS.log, DISM.log, and setupapi.dev.log, but that's the extent of my comfort zone. The only helpful thing I've found thus far in CBS.log (immediately SFC before it aborts itself) is:

2022-09-14 16:12:55, Info                  CSI    000027ed [SR] Verify complete
2022-09-14 16:12:55, Info                  CSI    000027ee [SR] Verifying 100 components
2022-09-14 16:12:55, Info                  CSI    000027ef [SR] Beginning Verify and Repair transaction
[HI]2022-09-14 16:12:55, Error                 CSI    000027f0@2022/9/14:20:12:55.494 (F) onecore\base\wcp\componentstore\deltastore.cpp(3065): Error STATUS_INVALID_PARAMETER originated in function ComponentStore::CRawStoreLayout::DecompressFile expression: Parameter check failed
[gle=0x80004005][/HI]
2022-09-14 16:12:55, Info                  CBS    Could not get active session for current session file logging [HRESULT = 0x80004003 - E_POINTER]
2022-09-14 16:12:55, Info                  CBS    Could not get file name for current session file logging [HRESULT = 0x80004003 - E_POINTER]
2022-09-14 16:12:55, Info                  CBS    Added C:\Windows\Logs\CBS\CBS.log to WER report.
2022-09-14 16:12:55, Info                  CBS    Added C:\Windows\Logs\CBS\CbsPersist_20220914200806.log to WER report.
2022-09-14 16:12:55, Info                  CBS    Added C:\Windows\Logs\CBS\CbsPersist_20220914183454.cab to WER report.
2022-09-14 16:12:55, Info                  CBS    Added C:\Windows\Logs\CBS\CbsPersist_20220914100104.cab to WER report.
2022-09-14 16:12:55, Info                  CBS    Added C:\Windows\Logs\CBS\CbsPersist_20220913172205.cab to WER report.
2022-09-14 16:12:55, Info                  CBS    Added C:\Windows\Logs\CBS\CbsPersist_20220913040012.cab to WER report.
2022-09-14 16:12:55, Info                  CBS    Not able to add pending.xml to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2022-09-14 16:12:55, Info                  CBS    Not able to add pending.xml.bad to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2022-09-14 16:12:55, Info                  CBS    Not able to add poqexec.log to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2022-09-14 16:12:55, Info                  CBS    Not able to add SCM.EVM to Windows Error Report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
2022-09-14 16:14:58, Info                  CBS    Trusted Installer is shutting down because: SHUTDOWN_REASON_AUTOSTOP
2022-09-14 16:14:58, Info                  CBS    TiWorker signaled for shutdown, going to exit.
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: ExecutionEngineFinalize
2022-09-14 16:14:58, Info                  CBS    Execution Engine Finalize
2022-09-14 16:14:58, Info                  CBS    Execution Engine Finalize
2022-09-14 16:14:58, Info                  CBS    Ending the TiWorker main loop.
2022-09-14 16:14:58, Info                  CBS    Starting TiWorker finalization.
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: ManifestCacheFinalize
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: ExecutionEngineFinalize
2022-09-14 16:14:58, Info                  CBS    CBS Engine already deativated
2022-09-14 16:14:58, Info                  CBS    CBS Engine already deativated
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: ComponentAnalyzerFinalize
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: PackageTrackerFinalize
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: CoreResourcesUnload
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: SessionManagerFinalize
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: CapabilityManagerFinalize
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: PublicObjectMonitorFinalize
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: Enter vCoreInitializeLock
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: WcpUnload
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: DrupUnload
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: CfgMgr32Unload
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: DpxUnload
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: CbsEsdUnload
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: CbsTraceInfoUninitialize
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: CbsEventUnregister
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: AppContainerUnload
2022-09-14 16:14:58, Info                  CBS    CbsCoreFinalize: WdsUnload, logging from cbscore will end.
2022-09-14 16:14:58, Info                  CBS    Ending TiWorker finalization.
2022-09-14 16:14:58, Info                  CBS    Ending the TrustedInstaller main loop.
2022-09-14 16:14:58, Info                  CBS    Starting TrustedInstaller finalization.
2022-09-14 16:14:58, Info                  CBS    Ending TrustedInstaller finalization.

Unfortunately I'm dumbfounded by this one; haven't seen it before. I've reviewed a few old threads @ Sysnative.com that reference the same error, but you folks delve into some files that are above my skillset, and hence I'd probably start breaking things if I attempted to troubleshoot on my own. Any help would be greatly appreciated!! And, I've attached logs. Hope this helps!

 

[Maxstar]

Hi.

Please post the older CBS log(s) as well.

• Open Windows Explorer and browse to the C:\Windows\Logs folder.
• Right-click on the CBS folder and choose Send to > Compressed (zipped) folder.
• Now the message will appear, "Windows cannot create the Compressed (zipped) Folder here. Do you want it to be placed on the desktop instead?"
• Click on the Yes button here.

• Attach the file CBS.zip to your next reply.

Upload your COMPONENTS hive.

• Navigate to C:\Windows\System32\Config and locate the COMPONENTS file.
• 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.
• 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.
• If the file is too large to upload here, upload the file to www.wetransfer.com and post the link in your next reply.

 

[soj4trade]

Hey Maxstar,

Thanks for your reply! Here are the requested files:

CBS: CBS.zip

COMPONENTS: COMPONENTS.zip

 

[Maxstar]

Hi,

Step 1. Download

SFCFix and save it to your desktop.
Warning: This fix was written specifically for this system. Do not run this fix on another system.

• Save any work you have open, and close all programs.
• Download the attachment SFCFixScript.txt and save it to your desktop.
• Drag the SFCFixScript.txt file over the SFCFix.exe executable and release it.

• SFCFix will launch, let it complete.
• Once done, a file will appear on your desktop, called SFCFix.txt.
• Post the logfile (SFCFix.txt) as attachment in your next reply.

Step 2. Run the System File Checker and post the result. If it fails attach a new copy of the CBS log.

SFC /Scannow

 

[soj4trade]

Hey Maxstar,

Nice, thank you! Please find attached SFCFix.txt and CBS.log. It reached 85% this time, so there's some progress.

 

[Maxstar]

Hi,

Here is the following fix, please run SFC afterwards and let me know the result. If it fails attach a new copy of the CBS log.

Warning: This fix was written specifically for this system. Do not run this fix on another system.

• Save any work you have open, and close all programs.
• Download the attachment SFCFixScript.txt and save it to your desktop.
• Drag the SFCFixScript.txt file over the SFCFix.exe executable and release it.

• SFCFix will launch, let it complete.
• Once done, a file will appear on your desktop, called SFCFix.txt.
• Post the logfile (SFCFix.txt) as attachment in your next reply.

 

[soj4trade]

Here's the file!

EDIT: Sorry, missed the top instruction. Running SFC now. More to come soon!

 

[Maxstar]

No problem, I thought I'd briefly shorten the instructions, because you know what you are doing and we have dealed with several other threads....

 

[soj4trade]

Ah! We are getting somewhere! SFC completed @ 100% but it said that it found integrity violations that could NOT be repaired. I see some hash mismatches in CBS.log now. :)

 

[Maxstar]

And the next fix to replace the corrupted RTM payload files. Please run SFC again and post the result.

Warning: This fix was written specifically for this system. Do not run this fix on another system.

• Save any work you have open, and close all programs.
• Download the attachment SFCFix.zip and save it to your desktop.
• Drag the SFCFix.zip file over the SFCFix.exe executable and release it.

• SFCFix will launch, let it complete.
• Once done, a file will appear on your desktop, called SFCFix.txt.
• Post the logfile (SFCFix.txt) as attachment in your next reply.

 

[soj4trade]

Windows Resource Protection did not find any integrity violations.
Windows Resource Protection did not find any integrity violations.
Windows Resource Protection did not find any integrity violations!!!

Haha. Many thanks, again, Maxstar. I'll run Windows Updates on this server tonight and report back to you on how it goes! :)

 

[Maxstar]

Great, I'll probably read the result tomorrow, but for now....

 

[soj4trade]

Hey Maxstar,

I don't want to speak to soon, but it's looking like this server is repaired now!! Windows Updates ran and currently CBS.log is processing startup packages. Typically this lasts for ~48 hours, so I won't have an opportunity to clean up the component store with DISM /Online /Cleanup-Image /AnalyzeComponentStore and DISM /Online /Cleanup-Image /StartComponentCleanup until next week. But I will definitely report back as soon as I have an update!! :)

 

[Maxstar]

Hi,

May I ask why you are manually cleaning up the WinSxS folder after installing updates? Windows will automatically reduces the size of the WinSxS folder if necessary.

"Windows also uses internal processes to reduce the size of the WinSxS folder, such as uninstalling and deleting packages with components that have been replaced by other components with newer versions. Previous versions of some components are kept on the system for a period of time, allowing you to rollback if necessary. After a period of time, these older components are automatically removed from the installation."

Source: Clean Up the WinSxS Folder

 

[soj4trade]

It's because I've ran into dozens of servers with "reclaimable packages" that won't go away, even after using /StartComponentCleanup. Typically I need to further investigate and make changes to get these packages to go away. I assumed that was a spinoff issue that manifested only after we repaired the component store. Is my understanding incorrect? Perhaps it is, and to be honest, I hope I am wrong; it would be a lot simpler to just stop tinkering with servers after Windows Updates are finished.

 

[Maxstar]

Hi,

The reclaimable packages after using the DISM switch /AnalyzeComponentStore indicates the number of superseded packages on the system. When a package is marked as superseded, it can be removed from the Component Store. But, when we have to deal with corruptions into the Components Store or the registry, the first step is to investigate the issue. When you start with cleaning up the system, useful data will may be lost. This makes it more difficult to investigate the specific problem. So personally, I do not recommend to clean up the WinSxS directory manually on a system with problems or after installing updates succesfully.

However, Windows will automatically run the StartComponentCleanup task to cleanup the Components Store every 30 days. So there is no need to run it manually. But there is a little diference between the DISM command to cleanup the Store and the sheduled task.

1. The sheduled task has a timeout of 30 days, before it will remove the previous versions of the component package.
2. The /StartComponentCleanup switch will immediately remove the previous versions of the component package, without the 30 day timeout period.
3. When using the /ResetBase switch as well, it is no longer possible to remove the installed packages.

 

[soj4trade]

I appreciate that info very much! Pardon the delay; I was stuck putting out fires that are completely unrelated to this project.

If I understand you correctly, if my final step in corruption repairs is to clean up the component store, and to verify that the "Reclaimable Packages" drops from whatever number it's at, to zero, I might be causing further damage? If that's the case, then I will definitely stop. I'm with you about the scheduled task. I did see that in the Scheduled Tasks application, but in this case my goal wasn't so much as to clean up the superseded packages, but more so to confirm that a cleanup actually works. I've seen cases where the /StartComponentCleanup command leaves reclaimable packages behind, which, to me, indicates there's an issue somewhere still.

To summarize, I am only running /AnalyzeComponentStore and /StartComponentCleanup to verify that Windows can actually clean up the superseded packages. I don't necessarily care about them being cleaned up; I just want to make sure it's possible. Does that make sense? If it doesn't make any sense, then I'll definitely stop doing it. :)

Thanks!

EDIT: Also, I'm marking this as solved now, since Windows updated!! :)

 

[Maxstar]

Hi,

Glad to hear the problem is solved!

If I understand you correctly, if my final step in corruption repairs is to clean up the component store, and to verify that the "Reclaimable Packages" drops from whatever number it's at, to zero, I might be causing further damage?

Basically, there is no need to run /StartComponentCleanup when updates has succeeded. Usualy - it does not cause any problems - however, problems with Windows Update could be very complicated. So you can never be sure about that!

(...) in this case my goal wasn't so much as to clean up the superseded packages, but more so to confirm that a cleanup actually works.

If Windows Update successfully installed the updates, a cleanup (is not necessary) and will run without any issues as well. If it fails we can take a look at it, but if the updates install without any problems, it might be something not to worry about.