Windows 10: Deleting context menu handlers vs using the blocked subkey?

So im doing some pruning, and various regfiles delete/replace context menu handlers while others seem to add the handler to a blocked subkey.

The result is the same, its gone from the context menu.

I'm trying to ascertain whether any other difference exists however.

Does windows replace the deleted ones on a version update, whereas ones placed in blocked stay removed from the context menu for example?

or are they simply different ways to skin a cat so to speak? identical apart from method?

:)

 

Deleting context menu handlers vs using the blocked subkey?

So im doing some pruning, and various regfiles delete/replace context menu handlers while others seem to add the handler to a blocked subkey.

The result is the same, its gone from the context menu.

I'm trying to ascertain whether any other difference exists however.

Does windows replace the deleted ones on a version update, whereas ones placed in blocked stay removed from the context menu for example?

or are they simply different ways to skin a cat so to speak? identical apart from method?

 

Deleting context menu handlers vs using the blocked subkey?

thats exactly what im "un-doing" lol. Id much prefer manage it myself. actually iirc correctly the "blocked" key is used by one of nirsofts programs.

between that, and regfiles, and winaerotweaker i found myself trying to untangle a mess to get certain things restored or removed due to different methods used for removal.

Hence my seeking as much parity as possible amongst methods im using via regfiles.

trying to ascertain if theres much or anything to be gained from using the "blocked" method vs delete method other than a visual representation of whats been removed by checking the blocked subkey.

I have very few regfiles using blocked and was considering converting the ones that "remove" to the former if there was anything to be gained.

 

Deleting context menu handlers vs using the blocked subkey?

yea. simple in theory except in my case, the fact that usually theres not 1 program to cover "eeeverything" and even when one does exist, im operating on a windows install thats been running for several years and god willing is going to continue to perpetually.

Considering the aforementioned, some frontends for customizing such things werent discovered until a later point when certain things were already modified. Or windows itself restores certain portions and not others when doing version upgrades etc. Or microsoft makes changes under the hood that render the "method" used by said program moot. The lessons learned from all of this over a lot of years is what led me to doing what im doing now.

if i have my own registry keys, then i not only know exactly what was modifed, but I have a record of it thats not hidden behind the code of a third party program and I can revert it just as easily.

My original question still stands. Does a functional difference exist between removing the key, vs adding the CLSID to the blocked list?

I dont imagine anything would outside from/apart from the windows version update scenario which is my primary concern.

I want to keep "maintenance" to a minimum so if using a blocked clsid leads to a windows update NOT reverting the change, that would be great (which i presume may be the case).

if it doesnt matter and windows will clear that subkey of any entry its trying to remediate, well then it is simply potatoe/potato or whatever.

i dont believe the blocked subkey exists by default though, so i'm unsure if a windows update would even look for it.

backing up is sound advice if i ever heard some. I certainly learned that one the hard way and nowadays do so compulsively. Its afforded me the ability to use a windows install thats been kicking almost since OG 10