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

hader said:

...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?

Click to expand...

Yes, I didn't quite trust it myself, so I carefully documented the process on another of my PCs on 26100.3476. Note the times....

I ran AnalyseComponentStore and checked the CBS.log to find these entries.....

After removing just the RollupFix package I did the same again, searching the new CBS.log (attached) for the.1742 FodMetadataServicing package....



The only remaining version of that package was this .3470 one....

Only then did I run the dism StartComponentCleanup command which found that further GB or so to clean up. Prior to all of this the component store had already been cleaned up as much as possible, so this gain was entirely due to the package removal.

hader said:

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.

Click to expand...

My experience with the Insider Beta build (and its 12 unrecoverable packages) suggested otherwise. See post #31.

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.

View attachment 128779

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.

View attachment 128781

Click to expand...

Bree, let us know if you incur any issues going forward, ie update etc. Thank you for your efforts.

gtspeck said:

Bree, let us know if you incur any issues going forward, ie update etc. Thank you for your efforts.

Click to expand...

I have already been running my System One with one of the two (FodMetadataServicing) removed since 8th Nov, 2024 with no issues. I have now removed both from all my 24H2 systems in my specs below, some are supported devices, others not. That should provide a thorough test going forwards.....

Well, deleting went fine , will see if we get problems , updating, etc..........
Made a backup first , so ...........
Very happy , we got about 2GB in return !
So, my backups went faster and smaller in bytes , its a great improvement !
Please , let us know how (??) to fix this again after next update(s)...........

Still wonder why(??) not possible to delete the "normal way" ( disclean-up), must be a reason somehow...........

hader said:

Well I will soon know; I try it for myself in a VM with a build 26100.3194 installation.

Click to expand...

Done!

OK. I am finished with my test on my VM. You are right! By removing that 1 package it automatically removes the other one.
I used a Windows 11 Pro 24H2 26100.3194 installation on my VM for this as promised in this thread; How to identify Reclaimable Packages reported as count by "Dism /Online /CleanUp-Image /AnalyzeComponentStore"

What I did basically;
- Deleted that one package. (the other one was also removed)
- Updated my VM from 26100.3194 to 26100.3476.
- After all checks everything was still OK. Wanted to test that before I apply that to my real system. It seems future-proof also. (as far I can see it)
Finally we have a working solution to get rid of those 2 unreclaimable packages. I would advise everyone if they want to do so also: Make a backup for future possible use!!!

I have attached the complete logging what I did; Logging_3194_Delete_packages_Update_to_3476_and_Check.txt So everyone can see what I did.
I also attached 2 .ps1 scripts I made to check stuff during the process; Maybe someone finds it useful. It's not that exciting. Just some PS command.
Note: Change <UserName> inside the script to your own or choose another location.
Because I do not have OneDrive on my VM; Change the path a bit for;
- No Onedrive: $Location="C:\Users\<UserName>\Desktop\PackageList.txt" Change <Username> only. (Or other location)
- With Onedrive: $Location="C:\Users\<UserName>\Onedrive\Desktop\PackageList.txt" Change <UserName> and Path. (Or other location)
- get_pack_3194Build.ps1 for users who are sitting still on 26100.3194.
- If 26100.3323; adapt the script with info from the PackageList.txt file. You can figure this one out; compare both .ps1 for info.
- get_pack_3476Build.ps1 for users who already sitting on 26100.3476.
Usage .ps1 scripts; Start Powershell as admin, goto your desktop (or other location) and run the script with .\get_pack_xxxxBuild.ps1

Thanks Bree for pointing that out to me!!! (removal of that package) It was an eye-opener!

I'm also in on this experiment, though I'm not as knowledgeable as most of you guys.

For reference, here's what I did: Macrium backup (all disks), then deleted the single package using the command given by @Bree, but didn't bother checking the log files since others did that. Everything went well and component store cleaned up fine.

Now the wait to see if updates mess things up :)

" Now the wait to see if updates mess things up :) "
We know next month , for sure............curious !

pietcorus2 said:

" Now the wait to see if updates mess things up :) "
We know next month , for sure............curious !

Click to expand...

I've already tested installing a CU after removing the packages, the March PT update. I ran up an earlier build as a VM, removed the packages, then checked for updates. All went well.

KB5053598 Windows 11 Cumulative Update build 26100.3476 (24H2) - March 11 - post #140

jimminy said:

Now the wait to see if updates mess things up :)

Click to expand...

As things look as they are now (deleting that one package) nothing will happen during the next update. It will update without any problems. I have the suspicion that it was there for rollback reasons. But nobody will after 1882, 2033, 2161, 2314, 2454, 2605, 2894, 3037, 3194, 3323 and 3476 (11 in total) go back to 1742 with their right minds. The name itself is a clue. "Package_for_RollupFix" There is one for 3476 so the 1742 one is obsolete. Why MS did not deleted this one earlier is anyone's guess. But you will be fine. I am confident. And yes time will tell if I am right.....

pietcorus2 said:

So, my backups went faster and smaller in bytes , its a great improvement !
Please , let us know how (??) to fix this again after next update(s)...........

Still wonder why(??) not possible to delete the "normal way" ( disclean-up), must be a reason somehow...........

Click to expand...

Mhmm. 2 Gb. Faster? Well my C-drive with Windows is now 167 Gb in size now (Windows 26Gb, Program Files x64 25Gb and Users 80Gb. Yes I know have to weed through this to check if anything is relevant; delete it or burn it on DVD) Those 2 Gb makes no difference in speed of the backup. Still 9 min (in my case) to make a backup and to restore it again. How fast your system is does matter. But size and speeds are just as normal as before.

There is no other way to solve this issue. By DISM /Online /Cleanup-Image /StartComponentCleanup for instance. Windows ignores this issue and it finds no reason to clean it up. It's business as usual. No other program will touch this; this is a part of the Windows engine. Better to leave it alone. There is now a way to do so but Microsoft would not advise us to do this. "Don't mess with our software. You don't know what you are doing!" Well it might be, but slowly we are investigating this and try to find out a permanent solution and if it is advisable if you do this to take the consequences or repercussions in the weight of the solution. As far as I can see this; this is a real solution which will have no impact on the workings of windows or future updates.

We are talking about 2 1742 (not important anymore) packages out of a total of 61 pieces!!
Some stats on the subject to get things in perspective;

My current build of 3476 contains 139 packages;
(incl. those 2 NOT deleted packages. I have a bit more than US versions. Language stuff etc.)

- 61x 1742 packages.
- 59x 3470 packages. (If I look at the numbers I would call this a 3470 Build!! It's the bulk of the update!!)
- 4x 3476 packages. (1 language pack, 2 licence packs, 1 RollupFix pack. I suspect that the build of this package determines the build version given.)
- 15x other version bits like; 0.9284, 0.9297, 26100.1, 26100.1588, 26100.2448 packages
139 in total.

Click to expand...

The rest is not affected and are already put aside by Microsoft as well. (staged) It's there but they are doing nothing with it. The only one that Windows is using is the current version 3476 (installed) I tried to delete the other 1742 that was still left and my Windows looked fine but it failed in the end. A device disappeared; My network driver is the one that went broke. Had no means to repair it by an internet connection. Luckily it was a VM. So I dropped it. Have to investigate a bit further about the reason why. I saw the old 1742 package involved but there was a new one also there. So why the fuzz? Maybe Windows is more sensitive about things or I just made an mistake... Will look into this. If I bite in stuff I will not rest until I found it.

There is no need to do this again with the next update. You have to do this once and is permanent. Gone is gone and they will never return. (You have to do this again of course if you install Windows again.)

What is a benefit; A check with DISM goes somewhat faster because it doesn't have to go through things which are obsolete in the first place. I noticed it with the DISM /AnalyzeComponentStore command. For the rest the speed is somewhat the same as before. And of course; the main reason: 0 reclaimable packages! That started this all in the first place. This is what the majority of people wants to see; my system is A-OK! That was the purpose of this whole exercise in the first place. If Microsoft did it already then no one would fall over this. Leaving it as it was is asking for questions....

hader said:

What is a benefit; A check with DISM goes somewhat faster because it doesn't have to go through things which are obsolete in the first place. I noticed it with the DISM /AnalyzeComponentStore command. For the rest the speed is somewhat the same as before.

Click to expand...

For me by far the biggest benefit is that AnalyzeComponentStore now says 0 reclaimable packages and means it. I no longer feel obliged to StartComponentCleanup every time, 'just in case' this time will be different.

Bree said:

For me by far the biggest benefit is that AnalyzeComponentStore now says 0 reclaimable packages and means it. I no longer feel obliged to StartComponentCleanup every time, 'just in case' this time will be different.

Click to expand...

You forgot the main reason part I mentioned....

But I agree fully. Yes. That was the main reason for this exercise in the first place. I was looking at the number 2 and cleaned it and afterwards it's still there. What's going on there? I must have a OCD response for these things, because I want to fix this!! I my real live I am a damn good analyst and problem solver. That's what's driving me. Solved lots of stuff during the time and as a benefit you understand stuff more deeply when you dive into it. For me? A challenge. "Challenge accepted......"

Luckily we are past this point. Update to 26100.3476.... For some people a right nightmare. Some 50! security fixed of which 6 are zero-day and exploited as we speak if you are not on 26100.3476. Hair raising!