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)

TLDR;

check post #48 here. seems to have been a solution for this poster

I have this issue of 2 non-recalimable packages which is due to shoddy software enginnering by MS.

dacrone said:

TLDR;

check post #48 here. seems to have been a solution for this poster

[SOLVED] - Number of Reclaimable Packages Stuck/won't clear out - Server 2012 R2 Standard

Please run the DISM /Online /Cleanup-Image /StartComponentCleanup command while ProcMon is running Step#1 - Capture Process Monitor Trace 1. Download and run Process Monitor. Leave this running while you perform the next steps. 2. Run the DISM command . 3. Stop Process Monitor as soon as it...

www.sysnative.com

Click to expand...

This is about Server 2012 and this post is 2 years old. Not very current and applicable for Win11 24H2 26100.3037 (now at 3194), MS changed it's update mechanism also.
His case is a different one. I posted the reason why there are still 2 un-reclaimable packages are left. With 24H2 the ISO base installation is 26100.1742. The 2 un-reclaimable packages has been identified not only by me. Someone else also came to the same conclusion.

Unfortunately this will remain the case until MS will bring out a big major release like Win11 Pro 24H2 SP1. Once you delete the base packages (1742) after a cleanup of the SxS store you will cleanup up also all the above packages of 1742 also. Your system will be corrupted by that.

I posted more info at: Redirecting

There are no more SP1 releases. Considering you get a new Windows release every year (so far).
If there's a Servicing bug, we'll repeat this drill in another 12 months.

Ran against a very nasty problem with 26100.3194 (Seen at my PC and with a separate VM)

Checking the store (before the update; ScanHealth & RestoreHealth): everything was OK. Analyzed (AnalyzeComponentStore) the store (after the update) and 8 (on my VM less) reclaimable packages. (You will end up with always 2 unreclaimable packages) Ran a cleanup (StartComponentCleanup) and after that I checked the store with ScanHealth again. It found problems!!.
Ran the RestoreHealth command and it seemed to be stuck at 62,3% for a very long time. Looked inside the CBS.log with a Powershell -tail command what it was doing. It was quite busy alright. Checking, repairing, downloading. It had something to do with "photon" packages what DISM doesn't official see. Some kind of internal and hidden package. The package itself is called;
amd64_userexperience-photon_31bf3856ad364e35_10.0.26100.1591_none_faf85d9f2170dfcf inside the C:\Windows\WinSxS directory.

In my case (I have a fast PC, disks, Internet) It took 20 minutes to repair. In my VM with 26100.3037, updated it to 3194. Exact the same behavior. Also 20 minutes. Is suspect this problem was introduced with 26100.3194. Don't know why. It remains hidden until you run the AnalyzeComponentStore and StartComponentCleanup commands. Sooner or later you will run into this problem.

What I do recall is that many people are complaining also that the RestoreHealth seems to be stuck at 62,3%. Seen instances that someone complained that his system was busy for a hour (and some more then that) People have no clue what their system was doing. Speed of your system is crucial in this case; fast machine and fast Internet will reduce the time. If someone run into the same problem; Let it run. Open a powershell as admin and enter;

Get-Content C:\Windows\Logs\CBS\CBS.log -tail 10 -wait

DISM is really ended if you see "Ending TrustedInstaller finalization." Inside services after a short period the Service TrustedInstaller (Windows Modules Installer) will shut itself down automatically; nothing to do....

People can see for themselves that the system is not stuck but quite busy.

Steve C said:

I have this issue of 2 non-recalimable packages which is due to shoddy software enginnering by MS.

Click to expand...

Believe it or not; that's "Normal". Can't be solved!

2 Packages are responsible for that;
- [Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package~31bf3856ad364e35~amd64~~10.0.26100.1742]
- [Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10]

Both packages "is a top-level package and is deeply superseded" There are a lot of 1742 packages inside the Component Store. They all belong to the base version of 24H2 you have used to install Win 11 24H2 Build 26100.1742. (Initial release) They will disappear when 25H2 will be introduced. Microsoft is not keen to solve this issue. So we are stuck with it. Thought that after a quite a few updates this issue would disappear. But Nope.....

This info can be seen inside the C:\Windows\Logs\CBS\CBS.log file after a dism /online /cleanup-image /AnalyzeComponentStore command.

hader said:

2 Packages are responsible for that;
- [Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package~31bf3856ad364e35~amd64~~10.0.26100.1742]
- [Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10]

Both packages "is a top-level package and is deeply superseded" There are a lot of 1742 packages inside the Component Store. They all belong to the base version of 24H2 you have used to install Win 11 24H2 Build 26100.1742. (Initial release) They will disappear when 25H2 will be introduced. Microsoft is not keen to solve this issue. So we are stuck with it. Thought that after a quite a few updates this issue would disappear. But Nope.....

This info can be seen inside the C:\Windows\Logs\CBS\CBS.log file after a dism /online /cleanup-image /AnalyzeComponentStore command.

Click to expand...

I have found that if I uninstall just the Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10 package, in doing so the Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package~31bf3856ad364e35~amd64~~10.0.26100.1742 package gets removed at the same time.

This one command removes both....
dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10
...confirmed by running /AnalyzeComponentStore again and searching the CBS.log in Notepad.



I have also confirmed that the two unrecoverable packages do not reappear after installing a cumulative update.
KB5053598 Windows 11 Cumulative Update build 26100.3476 (24H2) - March 11 - post #140

After removing these packages dism /online /cleanup-image /startcomponentcleanup was able to clean up an additional 1.26GB.

Bree said:

I have found that if I uninstall just the Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10 package, in doing so the Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package~31bf3856ad364e35~amd64~~10.0.26100.1742 package gets removed at the same time.

This one command removes both....
dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10
...confirmed by running /AnalyzeComponentStore again and searching the CBS.log in Notepad.

I have also confirmed that the two unrecoverable packages do not reappear after installing a cumulative update.
KB5053598 Windows 11 Cumulative Update build 26100.3476 (24H2) - March 11 - post #140

After removing these packages dism /online /cleanup-image /startcomponentcleanup was able to clean up an additional 1.26GB.

Click to expand...

Thanks for the info. I didn't expected that.
I saw before with KB5053598 Windows 11 Cumulative Update build 26100.3476 (24H2) - March 11 that you removed "Package_for_rollupFix.." because there were only one package still invalid. (the rollupFix one)
The other one "Microsoft-Windows-Fod.." was already removed I must assume.

But you claim now; By removing one ("Package_for_rollupFix..") you also remove the other. ("Microsoft-Windows-Fod..") That is in contradiction what I saw from your screen dump. (The "Microsoft-Windows-Fod.." was already gone) Can you clarify this for me? That can be a risk. It could in potential; if you remove 1 remove everything. (It didn't, I know. Find it odd that it just would only remove that specific other one.)

Well I will soon know; I try it for myself in a VM with a build 26100.3194 installation. Removing "Package_for_rollupFix" and see if the other one is also removed, and try to update that system to 26100.3476 and see if the updates encounters any issues.

I didn't suggested that those would re-appear with a cumulative update. Gone is gone. An update is not bringing those 2 back again. MS assumes they will still be there. Those 2 are there when Windows was installed in the beginning; build version: 26100.1742 and was never removed by later updates.
I 'll be back what I came across.... (I already have a copy of a earlier fresh VM build 26100.3194, just copy and start....)