Context menu icons

[epic]

Anyone know where in the registry someone can remove icons for items in the context menu?

I see no ico listings under:

HKEY_CLASSES_ROOT\*\shellex\HKEY_CLASSES_ROOT\DirectoryHKEY_CLASSES_ROOT\AllFilesystemObjects\

[CharlotteTheHarlot]

Anyone know where in the registry someone can remove icons for items in the context menu?

I see no ico listings under:

HKEY_CLASSES_ROOT\*\shellex\HKEY_CLASSES_ROOT\DirectoryHKEY_CLASSES_ROOT\AllFilesystemObjects\

Don't forget ... HKEY_CLASSES_ROOT\Folder

Remember that such entries will use a ShellEx subkey hanging off a higher key which is not necessarily easily identifiable. That ShellEx subkey contains a pointer to another class where a DLL is specified. That DLL holds the code that displays the icon. It is not something that can be adjusted from within the registry, but some of the context menu handlers might provide customization of their program through its own interface.

Here is a thread that delves into it. Post #15 and beyond covers this subject in detail.

More information here ... Read the whole thread to get a feel for it and see post #12 for specifics.

[epic]

Thanks for the info. I read through those pages and it seems like a heck of a lot of work. I'm not into customizing Windows anymore, as in the past, just looking for a quick fix to remove unnecessary, if not all, icons from Windows context menus.

As for handlers in the applications interface, majority of applications out there don't make available the option to hide/remove the icon or the applications preferences, the only way to remove either is to uninstall the applications entirely.

[CharlotteTheHarlot]

Thanks for the info. I read through those pages and it seems like a heck of a lot of work. I'm not into customizing Windows anymore, as in the past, just looking for a quick fix to remove unnecessary, if not all, icons from Windows context menus.

As for handlers in the applications interface, majority of applications out there don't make available the option to hide/remove the icon or the applications preferences, the only way to remove either is to uninstall the applications entirely.

Can you mention the program whose icon you are interested in? Or in what menus it appears? To track down its ShellEx key usually involves some sleuthing. For example, does the context menu entry with the icon only show up when you right-click files or folders? If it is one or the other then we have narrowed it down substantially. It really is a matter of locating the CLSID that the program has reserved for itself such as this ...

[HKEY_LOCAL_MACHINE\Software\Classes\*\ShellEx\ContextMenuHandlers\WinRar]

@="{b41db860-8ee4-11d2-9906-e49fadc173ca}"

Note that this is one of the more obvious ones since Eugene Roshal chose to use literally "WinRar" in that key name, but he didn't have to, it could be named "xxx" or anything else really. The Windows shell code simply enumerates everything under "*" and "Folder" and "Directory" ( and etc ) and follows the @=CLSID to get the shell extension and icon. The key names are irrelevant. However, they are enumerated in sequential order they appear in the registry ( I mean the way they really appear in an export, NOT necessarily how they appear in the REGEDIT GUI which allows sorting ). This bit of info is helpful when sleuthing because the entry above and below WinRar will appear that way in the context menu ( or DragDrop handlers, etc ). Anyone who tries to re-order WinZip and WinRar in the DragDrop popup needs to understand this ( the solution is to delete the first one and then re-import it which reverses their order ).

Anyway, if you look at that WinRar key you see it is pointing to {b41db860-8ee4-11d2-9906-e49fadc173ca} which is a class that contains the icon handler ( usually a DLL reference ).

So the trick is to now place {b41db860-8ee4-11d2-9906-e49fadc173ca} into the search field ( easiest way is to export the entire registry and search in a good text editor ) and find all the occurrences of that CLSID. Here's a few more places it pops up ...

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Drive\Shellex\ContextMenuHandlers\WinRar]

@="{b41db860-8ee4-11d2-9906-e49fadc173ca}"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\Shellex\ContextMenuHandlers\WinRar]

@="{b41db860-8ee4-11d2-9906-e49fadc173ca}"

( I'm not sure if everyone has these same keys, I have a habit of customizing everything so they may be handmade ). Anyway, you see that it is set for * and Drive and Folder which covers most right-click objects.

Now back to your case. If you know the context menu entry only appears on a folder but NOT on a file, then you can simply search under "Folder" or "Directory" where it will most likely be. And vice versa. It really is a matter of just locating one occurrence of it and then using that CLSID to find the others. And if they happen to use a unambiguous name it will be very easy. ( This is one reason I carefully log installs to have a searchable database of such things to refer back to. I usually can bypass any sleuthing. ).

Here's an example of one that has no helpful clues in the name ...

[HKEY_LOCAL_MACHINE\Software\Classes\Drive\ShellEx\ContextMenuHandlers\{59099400-57ff-11ce-bd94-0020af85b590}]

@=""

It is for a built-in Windows file called Diskcopy.dll that creates a "Disk Copy Extension" right-click entry for "Copy" ( pretty sure about that, it's the only one I see in the context menu ).

Interestingly, it uses a lesser known method, where it does not post the @=CLSID pointer, instead it leaves it blank. In this case the shell simply picks up the CLSID right from the key name itself.

As I mentioned above, you cannot control the icon from the registry, except to kill it or enable it. The code exists in the DLL file and the Windows shell handles that. But there are some utilities that add some control over these things ( one is mentioned in the 1st linked thread above ). I always have been wary of most of these utilities because they operate at the Shell level, being processed at each and every right-click. Buggy, broken or missing entries have been known to crash EXPLORER.EXE and worse. And the older the Windows version the more likely a BSOD or hard lockup ( albeit with some other variables in play like total RAM, core system settings ).

[epic]

So, let me get this straight...

Anything within:

*\ShellEx\ContextMenuHandlers\*

Is considered to be pointing to an ICO within the applications dll? If so, pretty straight-forward from there.

What about ICO's that are handled by Windows? (also: paste, cut, copy, etc... Windows context ICO)

Though, when removing the entries from the main context menu (ie: above), how can I tell the difference of a sub-menu entry?

*like to keep entries as these (ie: below)

Edited February 8, 2014 by epic

[CharlotteTheHarlot]

So, let me get this straight...

Anything within:

*\ShellEx\ContextMenuHandlers\*

Is considered to be pointing to an ICO within the applications dll? If so, pretty straight-forward from there.

It's better to think of it as: ShellEx is read by Windows shell code, it follows the link to its class where a file is pointed to, and then runs whatever code is inside that file. It may or may not have icons, and may or may not have flyout submenus, that is up to that particular author. For example, those programs that I mentioned that customize the context menu by allowing custom entries and icons will have a main ShellEx container entry and then a flyout subcontainer that holds the user custom entries. I've even seen a single ShellEx spawn multiple consecutive top level entries with icons and each with sub-flyouts. The sky's the limit to what is contained in these shell extensions.

What about ICO's that are handled by Windows? (also: paste, cut, copy, etc... Windows context ICO)

Let's back up. It is best to envision the context menu as a Super-Object. It pulls together a variety of objects from various locations, and this has evolved a bit since the original Win95 shell. Indeed that is a pretty good description because it is very similar to the Start Menu itself, also a super-object that pulls together many different components. From what I have gathered ...

NON-REGISTRY :: There is common core Windows shell code that is not seen in registry entries, like PASTE and SHORTCUT and RENAME and the main PROPERTIES items. These are present in the Shell DLL ( and possibly EXPLORER.EXE ) and these vary widely across Windows versions, especially in their use of icons. This category of context menu items is what is always present, even in a brand new fresh minimal install. What they do in there is up to the actual Windows shell programmers ( icons, flyouts, etc that you show in that screencap depend on Windows version, they have gotten much more visual and fancy with icons and things in recent versions ). This constitutes the absolute minimal context menu you will ever see, ( well not really, see the next one in the list ). This code is part of the shell mechanism - if you have a shell you will see base components in the menu. Modifying such context menu entries would mean modifying the Shell DLL and that is an unlikely scenario. Look for a complete replacement shell ( presumably with a new context menu system ) as a better idea.

REGISTRY VISIBLE :: There is also Windows code that sits in some extra DLL's like the one mentioned above with DiskCopy, and Briefcase and SendTo and CopyTo and MoveTo. The DLLs are/were using names like DISKCOPY, SENDTO, SYNCUI, SHDOCXXX. I'm not sure anyone has ever endeavored to make a complete list. Whether they have icons or flyouts is naturally up to those programmers as well. When these files are registered they do appear in the various registry keys that the shell code acts upon. The manner of control we have here is the same as all registry entries, leaving them in or deleting them, or moving them up/down relative to one another.

The Registry visible items is where it gets complicated. The ShellEx items are now co-mingled with the plain Shell context menu items, but in the past in Win9x that was not the case so they appeared separately in groups with divider lines between them. So within ShellEx, consecutive items as they appear in an actual registry export will maintain that relationship to each other in the context menu, but, with the added possibility that Shell items ( following the same rules ) might appear co-mingled. Each of these registry methods, ShellEx and Shell, in turn appear as subkeys off a variety of shell objects ( * or FOLDER or DRIVE, etc ). So the complexity of displaying this context menu super-object grows exponentially.

( Digression: I haven't really been able to get a handle on this co-mingling yet, but I am fairly certain that the shell code that reads the ShellEx keys has been strengthened in Windows XP and above, with the goal of providing a much more stable shell in general. Indeed, it is much harder to crash EXPLORER since XP and it has gotten even better since then. I believe they have added some kind of error checking that pulls out questionable items, and perhaps does even more than that. As mentioned in another thread, I used fake entries in Shell and ShellEx with some text to create a comment at the top and bottom of each section, and on Win9x the labels appear as expected, but on XP and above the Windows shell code removes the labels and co-mingles the entries. )

In your screencap you show a few core Windows items like NEW and SORT. Just like SENDTO, NEW are SORT are examples of Windows shell code, and up to Windows XP "SENDTO" was a DLL and "NEW" was core code. ( I haven't looked carefully in later versions ). SORT looks to me like a function pulled from EXPLORER.EXE and is used wherever named objects are grouped ( I am guessing that screencap was a right-click on the desktop? ). The important thing to realize is that whatever appears in context menu submenus really has nothing to do with the ShellEx mechanism, its job ended with displaying the SENDTO and icon and flyout. In its submenu are merely explorer folder views of files and objects. In the case of "NEW", in the old days it used to just show files from a folder called \ShellNew, but nowadays it is actually showing registry items demarked with a \ShellNew] subkey ( BTW this is a thing I always edit as I prefer very few things in that list, and the more that are flagged in the registry the longer it takes for that menu to appear, sometimes very long! ). In the case of SENDTO, it simply displays the shortcuts found in various \SendTo folders located on the physical disk ( no longer just in \Windows, but now scattered throughout user profiles all over the place ). Editing the contents of these SENDTO folders to have less items and removing broken links is a very good idea BTW.

The important point being that talking about context menu icons really ends at the first level of the context menu. Anything appearing in submenus are completely divorced from ShellEx and all other context menu mechanisms.

Finally, about those screencaps, each is missing the single most important detail ... what was right-clicked upon? ... It really is the starting point to understanding the context menu(s) in Windows and is critical to tracking down an entry to either kill it or move it. Was the right-click on a file, or a directory, or a pseudo-directory, a drive, a shell object construct like "My Computer", etc. This detail is the main clue to how what appears in a context menu actually got in there. In a link earlier I posted a fairly complete table of well-known shell objects which give us the main locations for registry items.