MSMG ToolKit

I don't think the issue is with components not being removed completely because of when I installed windows and did dism scan health after Resetbase got error 3 and when I removed tsprint from winsxs the error wasnt fixed only when i copied tsprint from untouched ISO to winsxs error was gone to never show again and I tried it against several win 11 versions also used dism++ to do reset base and to clean up winsxs and error never showed up again.

I also did another test where I used only toolbox components removal number 1 2 3 4 skipped 5 6 7 8 didn't use any tweaks and still got error 3 from dism after I installed windows.

Not a big issue it was fun actually trying to figure out why dism was giving me error 3 and why wasn't fixing files on its own.


I think the same issue other people are having and the solution is really simple

 

@MSMG
would it be possible for you to add via toolkit helper
an indicator of experimental components?
when this command is ran?
ToolKitHelper.exe c:\t\mount\install\3\ /?
currently, no indication is given in output.
Majid

 

I probably should have gotten into more in-depth details, but I wanted to make sure that I don't confuse anyone with too much information added.

The issue I am facing is very unique in the way that it only happens when you install an update for an image with these 2 components removed and preventing them from being added back to system by the update.
Every time you install an update, the removed components (if included in the update) will be added back, defeating the purpose of the removal to begin with (sadly).
This is the returning components issue that everyone talks about.
The update itself forcefully contains the deployment of the components regardless what you have set up on your system, this is the reason why they are coming back.
You cannot modify the content, because the .cat file verifies the .mum (deployment instructions) integrity, and if it is not matching, the update will fail.
If you cannot sign the modified .mum files, you cannot make changes to it without failure as an end result.
Removing these files, however, will let the update move on skipping them.

ResetBase, by the way, does more than shifting the baseline of the OS (you will not be remove updates prior that point as you probably know).
If, for instance, you perform a ResetBase on a system that has Edge removed, but having InternetBrowser components present in the system, ResetBase will actually redeploy Edge.

The control that you have on what can be present on the system when deploy an update is very much limited to certain registry tweaks that will prevent programs to show up, but the packages will still be present.

The component removal is definitely partially done (which may be due to other dependencies), and the only reason why people are not facing issues as I do, is that these packages will be added back each time you deploy an update (I keep repeating myself to emphasize the core problem people have with the update process).
I am working on countering this, but even my options are limited to reactive actions rather than proactive.
Proactive would be to recreate the update data by removing packages, but many of them are merged together.
InternetBrowser and Holographic packages are easy to remove, but the Toolkit can go sub-package level, which cannot be done when simply managing .cat and .mum files in the update.
Again, .mum gives you the option for this, but .cat verifies the integrity, and as soon as you touch them, the update will fail (unless you have the means to sign the changed setup).
My script is trying to emulate on a live system what the Toolkit has done to the offline image.
As the updates are cumulative, each will contain to previous entries (unless replaced by newer versions), which means that the data to be processed grows with each patch, so the processing time also gradually increases.
In have no experience with in-place update, but I would assume the packages will still be added to the system, whereas here I am in complete control what will be added there.
Also, if I fix the issues I am facing with the workaround I described, the "system created" in my way works without issues.
Though I did testing with limited 3rd party applications installed, the system was stable, and there were no diagnostics errors (Dism / SFC).
Additionally I would like to point out that I have spent several months of writing, testing and fixing the script, during which I acquired a rather solid experience, from which you can benefit from if you can fix unexpected issues yourself (just like you did in your case, as I got to understand).

Additionally, HKLM\COMPONENTS and WinSxS go hand in hand.
You will be facing problems if you have only one of them.
If both are not there, the system will not have anything to complain about.

And a fun fact, that may be useful for some maybe: when I trying to solve the ResetBase issue earlier, I was fooling around with HKLM:\COMPONENTS\DerivedData\Component Registry keys, for which you have the CF value present.
I wanted to enter the hexadecimal of value 12 (character "c" in decimal, which I have seen for other entries), but I accidentally entered it as decimal.
This value also fixed the ScanHealth issue after Resetbase, which makes me believe that CF = 12 decimal value will have the components ignored somehow.
I was not able to find any information about this (descriptive options for CF) online.
(Edit: as per my notes, HKLM:COMPONENTS\CanonicalData\Deployments keys were also removed, to make it work with CF = 12, but WinSxS was untouched in this case)
This was a more dirty workaround, I still prefer removing everything that was meant to be removed, so that no use of workarounds will ever be needed.
Besides, why would you want to have something on your system that you tried to remove intentionally?

 

Additionally, HKLM\COMPONENTS and WinSxS go hand in hand.
You will be facing problems if you have only one of them.
If both are not there, the system will not have anything to complain about.

And a fun fact, that may be useful for some maybe: when I trying to solve the ResetBase issue earlier, I was fooling around with HKLM:\COMPONENTS\DerivedData\Component Registry keys, for which you have the CF value present.
I wanted to enter the hexadecimal of value 12 (character "c" in decimal, which I have seen for other entries), but I accidentally entered it as decimal.
This value also fixed the ScanHealth issue after Resetbase, which makes me believe that CF = 12 decimal value will have the components ignored somehow.
I was not able to find any information about this (descriptive options for CF) online.
(Edit: as per my notes, HKLM:COMPONENTS\CanonicalData\Deployments keys were also removed, to make it work with CF = 12, but WinSxS was untouched in this case)
This was a more dirty workaround, I still prefer removing everything that was meant to be removed, so that no use of workarounds will ever be needed.
Besides, why would you want to have something on your system that you tried to remove intentionally?[/QUOTE]


Why don't you make your own tool according to your knowledge? You seem to know a lot about Windows. Why should you waste time and words? Just create a tool and publish it to MDL.

 

Good point, absolutely right.. i prefer the same as u

As far as i know... cmiiw.. MSMG Toolkit still leaves a lot of remnants of the components we removed.
Unfortunately we can't edit the toolkit, because it's actually @MSMG 's program, and Toolkit is free software, not open source software.
Maybe someone wants to make a toolkit like the MSMG Toolkit but in an open source form? we can fix it together if it's open source, many brains are far more powerful than only 1 brain.
no offense to @MSMG
just saying my opinion.

 

He just saying his opinion... come on...
I think he knows alot about windows..
Maybe he can make one, hope so... so he can share it with us... dunno...
As far as i know, many of u guys also knows alot about windows, but u keep it for ur self, no intention to share it.. many of u guys act like u guys are smart and know lots about windows.. but actually just a zonk... no different than script kiddies...
That is why i respect @MSMG and @inTerActionVRI .. they know something and they share it to help the others.
@tempdrive1 im sure he know something, he willing to share it... thats good point...

Thats the point of a community forum...right? To share and to help... cmiiw

(so sorry if i said "you guys"... didnt mean to dis-respect elder peoples.. i know many of u are "old men" 40++ to 65++ years old... and some of u guys are old perverts.. )

 

Not exactly sure how old am i my memory aint as goood as it used to be but Im definitely over 80.

 

Why don't you make your own tool according to your knowledge? You seem to know a lot about Windows. Why should you waste time and words? Just create a tool and publish it to MDL.[/QUOTE]


It was meant to be a bug report/enhancement request, I merely added some additional knowledge to it, which may be hard to come by, and useful to some.

Creating a tool that does identical things would hardly make any difference, having some adjustments made to this would achieve more.
The tool evolved with the help of the community, I was trying to contribute myself.
Every enhancement will be beneficial to you as well, even if you don't know what is going on behind the scenes.
Besides, I don't see the need by anyone for another/different tool.

The experience I have is sufficient to find my way around issues that I encounter, but usually takes quite the time and effort to get there with no know-how available beforehand, just like in this particular case.

The time and words will not be a waste if changes will be made eventually, otherwise I don't mind it.

 

It was meant to be a bug report/enhancement request, I merely added some additional knowledge to it, which may be hard to come by, and useful to some.

Creating a tool that does identical things would hardly make any difference, having some adjustments made to this would achieve more.
The tool evolved with the help of the community, I was trying to contribute myself.
Every enhancement will be beneficial to you as well, even if you don't know what is going on behind the scenes.
Besides, I don't see the need by anyone for another/different tool.

The experience I have is sufficient to find my way around issues that I encounter, but usually takes quite the time and effort to get there with no know-how available beforehand, just like in this particular case.

The time and words will not be a waste if changes will be made eventually, otherwise I don't mind it.[/QUOTE]

Hi dear friend @tempdrive1

In first place I hope that you and all yours be safe and heathly.

From what I've read from your reports and notes, you already have a tool (Script) "My script is trying to emulate on a live system what the Toolkit did with the offline image." which you use.

Would it be possible for you to really share it not as an alternative, but as a tool that, as you said above, can be used in images already deployed, creating a repo on Github openly so that others can contribute, test, evaluate and suggest implementations ?

Here's the idea,

Anyway, even though I have almost no knowledge, I thank you for your contributions and intention to improve the knowledge of the community, after all, as you yourself said, when one of us does it, everyone wins.

A big hug and good computing.

Best Regards,

@JeepWillys58

 

Hi my dear friend @MSMG

In first place I hope that you and all yours always be safe and heathly.

I try to find the version 13.4, but it's only avaliable 13.3 it's right my dear friend?

Thanks in advanced.

Best Regards,
@JeepWillys58

 

@JeepWillys58 Was asking this myself, until i noticed that you have to download the standalone exe and cmd file and replace it witht the ones from 13.3!
Just look at the filetimes and you will see what i mean.

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

Hi dear friend @tempdrive1

In first place I hope that you and all yours be safe and heathly.

From what I've read from your reports and notes, you already have a tool (Script) "My script is trying to emulate on a live system what the Toolkit did with the offline image." which you use.

Would it be possible for you to really share it not as an alternative, but as a tool that, as you said above, can be used in images already deployed, creating a repo on Github openly so that others can contribute, test, evaluate and suggest implementations ?

Here's the idea,

Anyway, even though I have almost no knowledge, I thank you for your contributions and intention to improve the knowledge of the community, after all, as you yourself said, when one of us does it, everyone wins.

A big hug and good computing.

Best Regards,

@JeepWillys58[/QUOTE]

Hi @JeepWillys58,

I suppose I could publish it, but perhaps GitHub is not the best place to put it to (in the sense that I am not certain if there would be any implications).
Perhaps I open a new topic here.
While it is pretty much production ready (need to add one more thing for which I haven't decided which route to take yet), I have been only using it on Virtual Machines and stopped working on it some months back when I discovered the issue I reported above.
The updates are being applied successfully and no breakage of the system was detected in the latest revisions.
(Technically speaking I could "patch everything" on my end, but I prefer having the issue resolved at the source of origin - so here - and not to build up countless workarounds that may show up later as well).
The usage of the script (PowerShell) is super simple, but I still need to create a proper documentation so anyone can understand what is going on, because there is quite a lot actually.
One or two weeks should be enough, I suppose, if there is a real interest.

 

I suppose I could publish it, but perhaps GitHub is not the best place to put it to (in the sense that I am not certain if there would be any implications).
Perhaps I open a new topic here.
While it is pretty much production ready (need to add one more thing for which I haven't decided which route to take yet), I have been only using it on Virtual Machines and stopped working on it some months back when I discovered the issue I reported above.
The updates are being applied successfully and no breakage of the system was detected in the latest revisions.
(Technically speaking I could "patch everything" on my end, but I prefer having the issue resolved at the source of origin - so here - and not to build up countless workarounds that may show up later as well).
The usage of the script (PowerShell) is super simple, but I still need to create a proper documentation so anyone can understand what is going on, because there is quite a lot actually.
One or two weeks should be enough, I suppose, if there is a real interest.[/QUOTE]

Don't get me wrong, if i sound rude. I am really interested for having another tool that is similar to MSMG Toolkit, and i would be happy to test it if you publish it.

 

Don't get me wrong, if i sound rude. I am really interested for having another tool that is similar to MSMG Toolkit, and i would be happy to test it if you publish it.[/QUOTE]

No worries.

This tool that I have created is not like MSMG Toolkit, it is more like an addition to it for live systems.
It does not perform component removal, but a component deployment prevention instead - unfortunately in a reactive way, since as soon as an update process is started (via Windows Update, installing the .msu, or .cab with DISM yourself), changes will already be made to system, which will be finalized after reboot.
Services, files and folders, Registry entries, drivers and the responsible packages will be added back to system upon next startup, which is much more that you can notice actually.
The only exception would be the modern apps showing up which are prevented by Registry values, but they may still be lurking around passively.
This tool will undo the changes - I dare to say - in the cleanest way possible.

While I understand that there is alternative way to manage this by doing in-place upgrade, it is also quite a hassle to manage, not to mention the effort required to prepare the installation media again, which I would not call as a user-friendly approach at all - it should be used to fix system issues related to updates.
Though I have never tried it myself, I have doubts on how clean that process is as it may touch various parts of the system, including personal data from what I understand.

There are some key benefits if you look at the big picture:
- updating the system would be much faster (compared to in-place upgrades)
- you do not need to skip any updates and wait to make performing an in-place upgrade worthwhile.
- if you remove properly something later on, it will be prevented from being deployed from future update installations, so you don't need to redeploy the system when you figured out how to remove more parts of the system that you do not wish to have

Spoiler

- it will not be needed to remove Windows Update component: I have a stable script for updating the system (SSU, LCU, 3.5 - 4.x .NET Framework upgrades and updates are supported), it can deploy every update (that is being) released regardless of your edition installed (fyi, that means 2032-01-13 for Win10 21H2), which I am using for years on multiple machines already, and no system update or upgrade is ever performed that is not started by the system maintainer this way.
The ultimate goal is to merge them together and have a single tool for live systems for keeping the system update-to-date for as long updates are released under complete control, and also ensuring that none of the removed or any newly added (a.k.a. new "features") component will ever get installed at the same time.

For this we need a solid, unbreakable base - but unfortunately I was able to break it for the time being.
And while I am able to manage (prevent) all the breaks on my end since I already know about the workarounds, MSMG Toolkit would need to handle it in the first place as it may have a positive impact on other things as well.

Spoiler

Additional hint: if this works out, you want to use the cleanest official image as a base, which is the very first release, since does not have the (bloated) features added later on, and as such integrating updates will not be necessary anymore, and the current latest update can be installed online very fast (e.g. with the other script I was referring to).

 

Hi @JeepWillys58,

I suppose I could publish it, but perhaps GitHub is not the best place to put it to (in the sense that I am not certain if there would be any implications).
Perhaps I open a new topic here.
While it is pretty much production ready (need to add one more thing for which I haven't decided which route to take yet), I have been only using it on Virtual Machines and stopped working on it some months back when I discovered the issue I reported above.
The updates are being applied successfully and no breakage of the system was detected in the latest revisions.
(Technically speaking I could "patch everything" on my end, but I prefer having the issue resolved at the source of origin - so here - and not to build up countless workarounds that may show up later as well).
The usage of the script (PowerShell) is super simple, but I still need to create a proper documentation so anyone can understand what is going on, because there is quite a lot actually.
One or two weeks should be enough, I suppose, if there is a real interest.[/QUOTE]

hello again my dear @tempdrive1

How cool would it be if you came to share this with us, absolutely on my part and I believe that many people are really interested in this, I personally don't have much knowledge in developing codes, but I am available and I propose to test it with absolute certainty.

I look forward to your contact, be it open or by PM.

A big hug and much success in everything you do, I'm sure "He" is always ahead illuminating your paths and your thoughts.

Kind Regards,
@JeepWillys58

 

Hi @MSMG,

Thank you so much for your attention, I understand exactly how much time and effort it takes to go after such issues, so I highly appreciate it along with all your work on this tool.

A small clarification with regards to my script that is intended to mimic your tool's actions on a live system: it does not modify the system's internal updating behavior in any way.
What it exactly does is working with pending.xml, migration.xml (sysprep.xml and others are yet to be looked after), Registry keys, and some files prepared/allocated by the update itself, and in its current state it does not touch things that were there prior calling the update.
Once the changes are undone/removed, the windows update process will try to work with the remaining parts and proceed as if the rest (that my script was touching) never existed.

I have returned to my scripts only recently, and also migrated to a new machine, so I will rebuild the base and do the testing again.
This should be done within the next 2 days, but before I do so, I would like to draw your attention to the following:

I think I noticed some misunderstanding on your end for the tests you have performed, which I believe would be the reason for the errors that you were encountering.
I have played with these Registry entries more than I would like admit - though only on a live system, not on the base image in an offline state while using your tool to answer your question -, and thus managed to build up my confidence to make these posts.
From what I understand based on your reply, you remove the values "i!CBS*" under the keys referenced, but it is crucial that the whole key is removed instead, e.g. [HKEY_LOCAL_MACHINE\components\CanonicalData\Deployments\dual_percep..nsixdof.inf_31bf3856ad364e35_10.0.19041.1_f4ec94a67cd216ca]
This may solve the trouble that you are facing with DISM and SFC.

To be more specific, you need to focus on these Registry paths:

MixedReality:
HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\dual_percep..nsixdof.inf_31bf3856ad364e35_10.0.19041.1_f4ec94a67cd216ca
HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\amd64_dual_perceptionsimulationsixdof.inf_31bf3856ad364e35_10.0.19041.1_none_f4ec94a67cd216ca

Tsprint:
HKEY_LOCAL_MACHINE\COMPONENTS\CanonicalData\Deployments\dual_tsprint.inf_31bf3856ad364e35_10.0.19041.153_356ebfa943b1edf9
HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\amd64_dual_tsprint.inf_31bf3856ad364e35_10.0.19041.153_none_356ebfa943b1edf9

The highlighted key names are the folders you will find in WinSxS.
Though these components do have more folders and keys, these was the bare minimum to remove in order to solve the terminating error for /ScanHealth.

I did see some SFC fixing attempts, but they are these generic entries:

2023-02-23 18:52:10, Info CSI 0000005b [SR] Verifying 100 components
2023-02-23 18:52:10, Info CSI 0000005c [SR] Beginning Verify and Repair transaction
2023-02-23 18:52:11, Info CSI 0000005d [SR] Verify complete

After calling SFC again, they will not appear anymore.
I suppose this may be the ghost error everyone talks about.

Needless to say, this makes no difference as I have noticed during my latest tests, but I perform SFC check to be certain that no error left on the system nevertheless.

As for ResetBase: I did not disable ResetBase by applying DisableResetbase"=dword:00000000", and I intentionally called DISM /Cleanup-Image /StartComponentCleanup with the /Resetbase switch.
I would like to disclose a few things regarding this:
- scenario 1: on a system, where you do a normal windows update, which restores the removed components, ResetBase will not cause any issues
- scenario 2: on a system, where I cleanup MixedReality and tsprint leftovers (by removing the full registry keys and winsxs files) and I perform the partial update (excluding the removed components), I did not notice any issues
- in case both of the above (scenario 1 and scenario 2), /ResetBase and /ScanHealth completes successfully
- scenario 3: on a system that I deploy partial update (excluding the removed components) but do not take manual actions (by removing the above specified full registry keys and winsxs files) to cleanup MixedReality and tsprint leftovers, /ResetBase still completes, but /ScanHealth will break down
- SFC did not fail in any scenarios, but it did mostly the invisible fixes (normally it would list in the CBS.log what it did fix, and for my own earlier failed update attempts it was actually fixing a lot of things)


More technical details with regards to scenario 3, just focusing on MixedReality this time:
c:\Windows\WinSxS\amd64_dual_perceptionsimulationsixdof.inf_31bf3856ad364e35_10.0.19041.1_none_f4ec94a67cd216ca has inf file(s) with human readable content by default.
When /ResetBase is used with my custom update deployment, the content of these files will be "restored" to some encrypted (or perhaps corrupted) format, where it is not readable anymore.
It may have to do something with the encryption applied to manifest files (c:\Windows\WinSxS\Manifests), but I am unsure to be honest.
So when /ScanHealth is called, CBS.log will show the follwing error that will terminate the process: STATUS_OBJECT_PATH_NOT_FOUND for '\SystemRoot\WinSxS\Temp\InFlight\201809f9b047d901180100006815a806\3803E232ACAB2476E81BC8A88D5B231A677DA3BC\PerceptionSimulationSixDof.inf'
The file c:\Windows\WinSxS\amd64_dual_perceptionsimulationsixdof.inf_31bf3856ad364e35_10.0.19041.1_none_f4ec94a67cd216ca\3803E232ACAB2476E81BC8A88D5B231A677DA3BC\PerceptionSimulationSixDof.inf will be there, however, and I think the reason behind the error is the corrupted file.
This is nothing but a pure guess at this point.
When an update is deployed in a standard way (Windows Update, .msu, .cab of the .msu) the system will restore the parts that were removed by your tool (sorry for repaiting myself, but it this part must be emphasized), hence this corruption will not appear, and this is the reason why people are not facing errors, since the system will "heal" itself.
I have to say, it is a nice way to standardize systems and minimize errors coming from discrepancies, but given that we don't like the system components, we are trying our best to "destroy" this process, and this is why it would be important to do it in the safest, most stable way possible.

Reminder: for you to reproduce my custom update, all you have to do is to remove the .cat and .mum files from the .cab files in the .msu, repackage the .cab file and deploy it with DISM.
Do this for MixedReality, because it is the easiest to achieve and will verified before tsprint anyway.
The error for tspint will only show up once MixedReality is resolved as the "missing files" (which aren't actually missing as stated just above) are terminating errors.

How I perform health checks (I rename the CBS.log and dism.log files after each step so it is very easy to review them):
0. I create the image with your tool, make sure MixedReality is not there, and install it (right after installing DISM /ResetBase and /Scanhealth with not do much, as the image I create was done with /ResetBase already)
1. install the partial update (use the .cab file without MixedReality component .cat and .mum files - you know, the Holographic* stuff) and reboot the machine so the deployment completes
2. wait about 5 minutes or so in order to let the post-update processes finish (you can see the marks for it in CBS.log) and perform SFC /SCANNOW and Dism.exe /Online /Cleanup-Image /ScanHealth
SFC will fix the ghost errors along with complaining about double owned directories, and I tend to see *_microsoft-windows-mediaplayer-skins_31bf3856ad364e35_10.0.19041.1_none_* related errors for /ScanHealth, which I thought for a very long time were the reason behind the final failure. This error is silent and does not terminate /ScanHealth
3. Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
This will complete without trouble. There are pretty much errors all the time regardless what you are doing, thanks to the advanced engineering performed on our favorite vendor's side, but they will be irrelevant if you look after them in CBS.log or dism.log
4. wait about 5 minutes or so in order to let the post-update processes finish (you can see the marks for it in CBS.log) and perform SFC /SCANNOW and Dism.exe /Online /Cleanup-Image /ScanHealth
SFC will again do the ghost errors along with complaining about double owned directories, but /ScanHealth will terminate with STATUS_OBJECT_PATH_NOT_FOUND #159450# from Windows::Rtl::SystemImplementation: DirectFileSystemProvider::SysCreateFile(flags = 0, handle = {provider=NULL, handle=0, name= ("null")}, da = (FILE_GENERIC_READ|FILE_WRITE_ATTRIBUTES|FILE_WRITE_EA|FILE_APPEND_DATA|FILE_WRITE_DATA), oa = @0x28f4b7b848->OBJECT_ATTRIBUTES {s:48; rd:NULL; on:[137]'\SystemRoot\WinSxS\Temp\InFlight\201809f9b047d901180100006815a806\3803E232ACAB2476E81BC8A88D5B231A677DA3BC\PerceptionSimulationSixDof.inf'; a OBJ_CASE_INSENS[gle=0xd000003a]
On the console it will display DISM Error 3.
Do note that /ScanHealth does restore files in the \WinSxS\Temp\InFlight folder, and whenever it gets terminated, it will not remove them and the space consumed will increate notably.
You can call /ScanHealth as many times as you want, the previous folders have no impact on it as they seem to be randomly (maybe seeded) regenerated.

Again, I would like to point out that even though I remove almost everything with your tool (I only keep Notepad, AppResolverUX, pretty much), once the tsprint and MixedReality issues are resolved, the errors are gone and no other component needs any of these workarounds, therefore I trust myself that what I am doing is not entirely wrong.
Also, do note that for the above steps you would not need to involve my script at all - you did a pretty much preventive approch by not letting windows update find anything to deploy for MixedReality.
It could be that this is still a flawled approach.
Technially speaking you must trigger something that the system recognizes as changes to it base state, and this would be one of them.
Calling /Resetbase on an system that has a resetbase performed already will not do anything, it finishes almost immediately.
The goal is still fixed nonetheless: remove components with your tool, and make sure they won't come back, while updating everything that was left there.

It is important to note that my last attempts were months ago, so I may not recall all details exactly even with my notes taken.
You can see from the log entries from above that they were lastly performed in February.
I can do any kind and amout of testing in a relatively short time, but only after this weekend.

Thank you for the clarification with regards to the Internet Explorer parts.
Given that the eventually old GPUs will be phased out, and security related aspects as well, could you perhaps include a separate option in the tool to remove everything that is not covered by the other option(s), so ie9props.propdesc, iernonce.dll, iertutil.dll, and anything else that was not covered but you are aware of?
I am certain that others would be interested in this as well, and it would greatly benefit my update script, too, along with reduced security risk on a live system (fewer executables and .dlls = less exploitable system) that it would bring.
I will perform tests for Windows Search part I am going to test what kind of impact it has on when I remove the file ie9props.propdesc, because I did remove it myself for a couple tests, but don't recall any notable side effects from it.
Feel free to be more specific what I should be looking for.

I kindly ask you to perform another test which resembles my steps provided in this response as identical as possible, and do let me know if there are mistakes made on my end.
If you don't mind, I will wait with additional testing until you confirm that it still does not work or have other concerns and need me to perform specific tests.
Either way, I am waiting for your next feedback.