How to identify Reclaimable Packages reported as count by "Dism /Online /CleanUp-Image /AnalyzeComponentStore"

This is some truly great work @Bree. I'm going to blog about this soon and give you a major shout-out. It has been my observation, too, that "the next CU" undoes this work, so I've learned to live with it. But it's great to have conclusive evidence that these anomalies are part of what CUs put down as the update process proceeds. Thanks, thanks, thanks!
--Ed--

I wrote a PowerShell script that simply shows the lines of interest. Here 'tis:

# Path to the input text file
$inputFilePath = "path\to\your\inputfile.txt"

# Read the file line by line
Get-Content $inputFilePath | ForEach-Object {
# Check if the line contains both "Staged" and "Feature Pack"
if ($_ -match "Staged" -and $_ -match "Feature Pack") {
# Output the line
$_
}
}

I saved it as kbfilt.ps1 and ran it against KB.txt and got two results for my 2-item spurious image

PS C:\Users\etitt> .\filtkb.ps1
Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package~31bf3856ad364e35~amd64~~10.0.26100.1742 | Staged | Feature Pack |
Microsoft-Windows-Licenses-Professional-Package~31bf3856ad364e35~amd64~~10.0.26100.1742 | Staged | Feature Pack |
PS C:\Users\etitt>

Click to expand...

If you wanted, it would be easy to save this output in another file instead -- perhaps kbfilt.txt. With only two such items, I don't mind cutting and pasting the package names from Terminal itself. Readers can do as they see fit.

Cheers!
--ed--

Ed Tittel said:

I saved it as kbfilt.ps1 and ran it against KB.txt and got two results for my 2-item spurious image

Click to expand...

The first of those two you have found can be removed with Dism /online /remove-package /packagename:<full name of package> as I did in post #26.

Bree said:

I also have an RTM 24H2 machine, and it too has two unreclaimable packages. The Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package~31bf3856ad364e35~amd64~~10.0.26100.1742 Superseded Feature Pack was certainly one of them, deleting it reduced the count to one unreclaimable package.

Click to expand...

And it has not returned with a subsequent CU.

The second cannot, access is denied....



I'm down to just the one unreclaimable package now.

Bree said:

The second cannot, access is denied

Click to expand...

What if you ran powershell as TrustedInstaller or NT Authority\System?

KevTech said:

What if you ran powershell as TrustedInstaller or NT Authority\System?

Click to expand...

How? I wondered. Then I found Nirsoft's AdvancedRun - Run a Windows program with different settings

Tried both, same result - access denied.

Bree said:

Tried both, same result - access denied.

Click to expand...

That license package is in 24H2 but not 23H2?
I could not find it in 23H2.

Bree said:

How? I wondered. Then I found Nirsoft's AdvancedRun - Run a Windows program with different settings

Tried both, same result - access denied.

Click to expand...

You can use this I think:

Concerning this issue (2 Reclaimable Packages are not cleaned from the SxS store) I have this seen also since late 2024. Whatever I do I can’t convince Windows to clean them up. After a Sandbox disaster that would not uninstall whatever I did (I did everything even by hand; DISM f**** up and stays that way. So I reverted to a backup from last year (end of 2024) with a new install and installed all patches available in the correct order. (Version: 24H2, 26100.2605) Today after Patchday Tuesday; 3 new Updates (KB890830, KB5050009, KB5049622) were installed & after a reboot. System was OK; No SFC of DISM errors. (Version: 24H2, 26100.2894) 7 Packages where found Reclaimable after analyzing the SXS component store. Cleaned the SXS component store and it left 2 packages.

Used the DISM /ONLINE /GET-PACKAGES /FORMAT:TABLE > C:\<Path>\KB.txt command to write to the KB.txt file and ran Ed's (thanks) kbfilt.ps1 file. It came up with 1 package only; Microsoft-Windows-onceLicenses-Professional-Package~31bf3856ad364e35~amd64~~10.0.26100.1742 | Staged | Feature Pack | 10-9-2024 05:56

I can see that it belongs to Version 26100.1742 with a timestamp of 10-9-2024, 05:56. I am sitting on 26100.2894. Looking in the KB.txt file one thing catches my eye; A lot!! of packages with xxx10.0.26100.1742 and xxx10.0.26100.2894 names have the same entry's.

With a difference; All *1742 has the status "Staged" (1 superseded) and all the *2894 package has the status "Installed".

You have to inspect the KB.txt file to see the 2 occurrences in your case. Edit the attached kbfilt_edit.ps1 for your case. Running it will produce in my case; 1742.txt with 79 occurrences and a 2894.txt file with 83 occurrences. If I look at the 1742 lines there are a few with a later date then 10-9-2024. So later updates occurred but where also not implemented.

Conclusion; There is something wrong (in my case) with the cleanup of the old 1742 packages. Reason why? Unknown. Maybe they are waiting for a final update after which the whole bunch will be cleanedup. It’s not just 2 packages but a lot more. Deleting them without any knowledge will damage your Windows 11 system.

Nope!... My advice: Leave it as it is.
I have no clue why the old packages are left there with the status "staged" (and 1 superseded) It looks like these are not Installed. The 2894 versions has all the status "Installed". I suspect that they distributed version 1742 but someone pulled the plug on them because there was something wrong with it. They just continued with their next version and left these behind. I am up-to-date to 2894 and I think they will never implement 1742 because they are to old.
I am asking Microsoft what they are going to do to clean this (now) rubbish.

Keep you posted. If anyone has an other explanation or other packages; feel free to respond.

Updated files; Reason: Formating issues.

Attachment #1: kbfilt_edit.ps1 (Run as admin) : Edited to produce a 3-digit number line. This file (must be edited to your Filepath. Change "<Path>" into e.g. "Users\<your name>\Downloads"). Produces 1742.txt and 2894.txt files or a filename of your choosing.

Attachement #2 and #3: Updated 1742.txt and 2894.txt files with 3-digit number entry's.

Forget the attachment files 1742.txt, 2894.txt and kbfilt_edit.ps1 in previous post. Can't change the post anymore. (Strange)

It's still popping up even on Insider Preview 24H2 releases. I now just check in from time to time to see if it's still there.
Windows is such a trip!
--Ed--

Ed Tittel said:

It's still popping up even on Insider Preview 24H2 releases. I now just check in from time to time to see if it's still there.
Windows is such a trip!
--Ed--

Click to expand...

Hi Ed,

Agree!! The wall I keep up running against; I want to see a reason for it all in order to understand why stuff is going wrong. If you know the root-reason for a problem you can try to address it. Now? Things are so complicated that even the root-cause is concealed. Look at the uncountable issues arround Windows errors and so called fixes and solution that don't work because a error is a general sign that "something is wrong" There is no general solution for a problem because the conditions are not alike. You can try it but it many cases the problem remains.

There is a need for a program developed by Microsoft that analyze problem situations that points to the root-cause. Now we are searching through loggings which is crammed with normal lines that has nothing to do with the root-cause and staring at countless lines that is giving us not a clue about the problem. Only the tools SFC and DISM are not enough. An in-depth look is needed where normal behavior is stripped out from it's output.

Microsoft is stepping back with their fixed troubleshooters that was supplied with Windows in the first place. They now are being replaced by online troubleshooters which can be modified in order to finetune things. Do they work? No. Try to fixed it and comes up with "not fixed" and do you want to report it. And if you do? Seen never a feedback, solution or adaptation in their online troubleshooters that will work. Third party's also are claiming that they have a fix but are failing also in many cases.

No wonder that these issues are seen also in the Insider program. (live test environment) The frequency is even much higher because stuff are pre-released and they want getting feedback and fix them before they officially release a build version.

Was once a Insider myself. Came across a release riddled with problems. I tried to turn things back again with the expliciet understanding; Leave my apps and personal data alone!!! After more than one hour I was back again... ?? A restore of an backup takes 8 minutes.... And all my apps and personal data where.. Gone. Poef. Gone up in smoke. I am now using my own policy; No Insider and if things look 300% alright and stable; Make a backup of the whole disk. I have used this backup more than I thought to be necessary. At the moment I must make an other snapshot because an old backup is getting outdated while new build versions are stacking up. It takes longer to getting an old version up to date again.

Can advice everybody to do the same thing I do. Back to an older backup? Make a new backup first!! Then restore. In this case you can restore files left in the new backup that wasn't included in the older backup. Stuff not related to registry entry's and stuff that you forgot to copy to a different disk.

Well... I found out a lot.

Contacted Microsoft and on their advice;
- Check the integrity of the Windows installation with the SFC and DISM commands. No errors but still 2 reclaimable packages.
- dism /online /cleanup-image /startcomponentcleanup Still 2 reclaimable packages remains. Same situations as before.
- dism /online /cleanup-image /startcomponentcleanup /resetbase Did totally nothing. Finished in 1 sec.
- Check pending updates; dism /online /get-packages Nope. Same as before 1742: Staged (with 1 superseded), 2894: All Installed.
- Cancel pending updates; dism /online /cleanup-image /revertpendingactions Nope. Did nothing. No Updates pending.
- Remove the 1742 packages.

Made a ps1 script that generated a remove_1742.ps1 script.
Command/package is: dism /online /remove-package /packagename:<packagename> /norestart.

Ran it. Removal was a succes with some explainable errors. Did all the checks possible to check Windows integrity. It all checked out OK, no errors an no 2 reclaimable packages anymore. Zero. Number of 2984 packages was still the same. Succes!!!

Until the final hurdle to make sure: DISM /Online /Cleanup-Image /StartComponentCleanup After that reboot and ran SFC /Scannow. It detected errors and fixed them. Futher DISM checks; No errors. Winver? Still 26100.2894.

Looked at the number of 2984 packages. Oh No!! It dropped from 61 to 9. 9 language related. Winver? Still 26100.2894.
I suspect that the /StartComponentCleanup command saw that the 1742 were gone and decided to remove the 2894 as well because of invisible relationships, links or dependencies. All I was left with; a damaged Windows 11 Pro installation. All integrity checks checked still OK but with 85% removed 2894 packages?? No way that's a good thing.

And my Ethernet card functionality (also a package) was gone. So no internet even after a New installation with all my personal data untouched. Only a fresh install from scratch will resolve that problem.

Future updates will fall over this problem.
Lucky for me; it happened on a virtual machine so I could drop it and copy the original virtual machine back again.

So DON'T remove packages by hand. We know nothing about the invisible relationships between 1742 and 2894. /StartComponentCleanup did and that had consequences. It corrupted the system as result.

It's up to Microsoft to remove these outdated 1742 (or other) packages in future updates. And more important: 2 reclaimable packages that not can be reclaimed is under certain conditions a normal known issue. No need to take action. Eventually Microsoft have to deal with it. So that the SXS Store is not completely clean; we have to live with that fact. There is nothing we can do to resolve it. (except corrupting your system)