If you're one of those people who get frustrated with menus full of options you don't use, poorly implemented integrations, or slow folder opening , you're in the right place.
In Windows, you can modify the behavior of File Explorer and the context menu in several ways (including tricks for File Explorer in Windows 11 ): through the Registry, with classic shell extensions in the form of DLLs, with modern MSIX packages, and even by creating your own extensions in .NET or C++. Let's explore all these possibilities calmly, but without going into too much detail.
What are Shell extensions and why does the Registry fall short?
The Windows Shell can be extended in a basic way using Registry entries and .ini files . This approach is simple and usually sufficient for customizing icons by file type, adding extra commands, or associating extensions. However, it has a significant limitation: everything you define applies at the file type level, not to individual files.
A typical example is custom icons by extension : if you assign an icon to .docx files in the Registry, all copies of that file type will see the same icon, even if you want to distinguish them from one another. And there are areas of the Shell, such as the properties window that appears when you right-click and choose Properties , that simply cannot be modified using only Registry keys.
To truly control the Explorer, you need to take it a step further and use shell extension handlers . These are COM components (usually DLLs) that the shell invokes whenever it's going to perform a specific action: displaying an icon, opening the context menu, rendering a thumbnail, showing a tooltip, etc. The Explorer consults the handler just before executing the operation, giving it the opportunity to change the outcome.
A very common example is the context menu handler . If you create one for a file type, Windows will invoke it every time you right-click on any file of that type. This component can add different menu items depending on the specific file, the number of selected items, the path, etc., something impossible to achieve with just a simple command association in the Registry.
Within this family of controllers, there are two main groups : those tied to specific file types (and acting "per file") and those that execute in general shell operations (without depending on a particular extension). Looking at them in some detail helps you understand their capabilities.
Main controllers associated with file types
File type-based handlers let you customize Explorer's behavior for specific file extensions . They work at the individual file level, so you can tailor menus, icons, or properties for each file type.
- Context menu controller. It runs just before displaying a file's context menu. It allows you to add additional commands, rearrange items, and display options only for specific files or situations (for example, if multiple files are selected, if it's a special folder, etc.).
- Data Handler. It comes into play in drag-and-drop operations on Shell objects. It can contribute Additional Clipboard Formats so that the destination has more information (for example, an alternative representation in XML or binary format).
- Drop Handler. This command is invoked when you drag or drop data onto a specific file. It allows a file to act as the destination for a drag-and-drop operation, for example, dropping multiple files onto a .zip file or a database.
- Icon Handler. It is called before the Shell displays a file icon. It allows you to replace the generic icon of a file type with a custom-generated one for each file, which is very useful for elements such as images, project documents, synchronization statuses, etc., and for this it is advisable to review the best extensions for Explorer.
- Property sheet controller. It is activated when you are about to display the dialog box Properties of an object. You can use it to add additional tabs or replace some of the existing ones, so that your application exposes its settings directly in the file's properties tab.
- Thumbnail Handler. It generates the image you see in the Explorer thumbnail. This allows a video file to display a representative frame or an uncommon image format to be previewed without relying on external applications.
- InfoTip Handler. This is used to generate the tooltip that appears when you hover your mouse over a file. Here you can display relevant metadata: audio duration, photo resolution, document status, etc.
- Metadata controller. It provides read and write access to the properties stored within a file. Thanks to it, you can expand the view of Details, tooltip information, groupings, and additional columns with custom metadata.
Other Shell drivers not tied to a file type
In addition to the file-type-dependent controllers , there are others that the Shell invokes before certain general Explorer operations. These are the ones that allow for higher-level customizations.
- Column controller. The view is checked before being displayed. Details from a folder. It is used to add custom columns (for example, "Rating", "Internal Author", "Validation Status") that are populated with information calculated by your extension.
- Copy Hook Handler. This command is invoked when the system is about to move, copy, delete, or rename a folder or printer. It allows you to approve or block that operation, which is very useful in security solutions, corporate policies, or monitored folders.
- Contextual Drag & Drop Handler. This is called when you drag a file with the right mouse button. You can modify the context menu that appears when you release the mouse button, incorporating special actions such as "Convert and Move," "Upload and Delete Original," etc.
- Icon Overlay Handler. Add a small marker to a file or folder icon (for example, the green checkmark for synced files or an exclamation mark). The shell invokes this just before painting the icon, and your code decides which overlay to apply.
- Search controller. It's used to launch custom search engines integrated into the shell itself. With it, you can expose your own search engine, accessible from the menu. Home or from the Explorer, which works on remote data or non-standard structures.
Namespace extensions: virtual folders in Explorer
Windows Explorer doesn't just display the traditional file system ; it actually reflects a complete "namespace" that includes virtual folders like the Recycle Bin, Libraries, and Printers. With a namespace extension, you can enclose any body of data and present it as if it were a regular folder.
When you create a namespace extension, Explorer displays your data as a hierarchy of folders and files , even though they may actually reside in a database, on a remote device, or be simple logical links (as with printers). To the user, it behaves just like any other folder: you can copy, move, delete, view properties, and even perform searches.
Technically, each folder visible in Explorer is represented by a COM object called a "folder object" . When the user interacts with that folder or its contents, the shell communicates with this object through standard interfaces such as IShellFolder . The object responds to requests (listing items, returning icons, names, attributes, etc.) and the shell updates the graphical interface.
This model is especially useful when your data doesn't fit well into the standard file and folder structure . Think of a database you want to navigate like folders, the contents of a digital camera without a Windows file system, or a collection of purely logical objects (for example, print jobs in a queue).
A namespace extension is broadly divided into two parts : a data manager (how and where you store the information, according to your preferences) and an interface layer with the Explorer that packages that data as folders and files. This second part is what implements the COM interfaces so that DefView (the default folder view) and the rest of the shell know how to display and manipulate the content.
How Explorer views interact with an extension
The Explorer window is composed of several areas: tree view, folder view, menu and toolbars, and status bar . When you enter a folder managed by your namespace extension, your code can influence all of them, albeit to varying degrees.
The tree view provides a high-level overview of the hierarchy . It hosts a TreeView control that displays each folder in the namespace and its position. From here, the user can expand levels, drag folders, use the context menu, or open subfolders. The Explorer primarily communicates using IShellFolder , requesting attributes, listing subfolders, and requesting display names and icons.
The folder view (the right-hand panel with the files) is even more flexible . Unlike the tree view, Explorer doesn't directly control its contents; it simply creates a child window and passes it to your folder object. That window can host a classic ListView, a web browser control with dynamic HTML, or anything else that makes sense for your data.
The usual approach is to reuse DefView using the SHCreateShellFolderView function , which provides the standard view with icons, details, sorting, groups, etc., allowing you to focus on providing the data. However, if you require a very specific presentation, you can create a completely custom view.
The Explorer's menu and toolbars can be customized from your extension . The shell exposes the IShellBrowser interface , which allows you to add or remove buttons and menu items, or react to specific commands. When the user clicks a custom button, the Explorer forwards the WM_COMMAND message to your window for processing.
The status bar is another very useful channel . From within IShellBrowser, you can update the text to display contextual information about the selected object, the number of items, errors in your extension, etc., thus improving the feeling of integration with the system.
Create browser extensions using a .NET class library
If you develop in .NET, you can use a library with base classes to simplify the creation of many extensions . The idea is very straightforward: you create a class library project, add a COM class, and make it inherit from the base class that corresponds to the type of extension you want to implement.
For example, BrowserHelperObjectBase makes it easy to create Browser Helper Objects for Internet Explorer by mapping browser methods, events, and properties to your code. You expose things like the IE instance (the InternetExplorer property ), the window in which the object runs ( Site ), and handle events like OnConnection and OnDisconnection.
ContextMenuHandlerBase simplifies the creation of context menus for Explorer . You simply populate the MenuItems collection with MenuItem objects, just as you would in a Windows Forms form, and hook into the Click event of each option. The Files property provides the list of selected files, and the OnMenuSelected method updates the help text in the status bar.
With DropHandlerBase you implement drag & drop handlers associated with a file . You have properties such as Filename (the destination where files are dropped) and Files (the dragged files), and methods such as OnDragEnter , OnDragOver , OnDragLeave , and OnDragDrop to react to each phase of the drag.
IconHandlerBase lets you return the icon that Explorer will display for each file. OnGetIconLocation lets you specify the icon's location, and OnExtractIcon lets you return the specific icon handlers, allowing you to generate thumbnails or more advanced representations.
Registering these .NET extensions is done via COM using regasm.exe . The base classes include methods marked with ComRegisterFunction and ComUnregisterFunction that handle creating or deleting the appropriate registry entries when you register the assembly. Additionally, many of these classes support the ExtensionFileTypes attribute to specify which file types they affect (this can be a comma-separated list or the wildcard * for all).
Replace or modify the shell (explorer.exe) at the system level
Another way to radically modify the Windows environment is to change the default shell , that is, the program that starts when you log in. On single-purpose systems (kiosks, industrial devices, terminals), you sometimes don't want Explorer to run, but rather a single full-screen application; if you need other options, see alternatives to Windows Explorer.
In Windows Server and client environments, this behavior is controlled through the Registry , specifically in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell . Replacing the value with the path to your executable will cause your program to load instead of the classic Explorer at login.
The caution here is clear : disabling explorer.exe as the shell leaves the end user without a desktop, taskbar, and folder windows, so it's an option intended for closed systems. Furthermore, it's always advisable to have an alternative method of administration and recovery (RDP, safe mode, GPO, etc.).
Customize Windows 11 File Explorer from the Registry
Beyond COM extensions, many users simply want to remove annoying options from the context menu or restore the classic behavior . In Windows 11, the redesign of the right-click menu and the integration of features like Copilot have generated considerable criticism, especially among advanced users.
The first thing to keep in mind is that modifying the Registry is no joke . A wrong change can destabilize your system, so before you do anything, create a restore point or a backup of the Registry. And, of course, make sure you copy the paths exactly as shown.
To open the Registry Editor, simply type "regedit" in the Start menu and launch the Registry Editor . From there, you can navigate through each branch we'll mention and create keys, string values, or DWORD values as needed.
Remove “Ask Copilot” and other entries from the context menu
If you have the Copilot app or integration installed on Windows 11 , right-clicking on a file will likely display the "Ask Copilot" option . This entry takes up space in the menu and, if you don't use the feature, it's just clutter.
To disable it from the Registry, navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Shell Extensions . Within this branch, create a new key called Blocked . Once inside, add a new string value named {CB3B0003-8088-4EDE-8769-8B354AB2FF8C} and leave the contents blank.
The same trick works to clear other options like "Edit with Notepad", Paint, or Clipchamp . Always working under the branch HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Shell Extensions and within the Blocked key , you can create different string values:
- {CA6CC9F1-867A-481E-951E-A28C5E4F01EA} to hide “Edit with Notepad”.
- {8BCF599D-B158-450F-B4C2-430932F2AF2F} to remove the option Clipchamp.
- {2430F218-B743-4FD6-97BF-5C76541B4AE9} to remove the integration of Paint.
Once these values are created, restart Explorer or your computer so that Windows reloads the settings . To revert any of them, simply delete the corresponding value or the entire Blocked key if you want to recover all entries.
Bring back the classic Windows 10 context menu
One of the most talked-about changes in Windows 11 is the new, simplified context menu . It's not that it's inherently "bad," but many long-time users miss the full Windows 10 menu, with all the options visible without having to click "Show more options."
To revert to the classic style, you can use another small modification in the Registry . Go to HKEY_CURRENT_USER\SOFTWARE\CLASSES\CLSID (note: do not confuse this with the .cls branch) and create a new key named {86ca1aa0-34aa-4e8b-a509-50c905bae2a2}.
Within this newly created key, add another one called InprocServer32 . In the right panel, double-click on the value (Default) and ensure the data field is completely empty. Accept the changes and close the editor.
After restarting your PC, right-clicking on files or folders will display the context menu just as it appeared in Windows 10 , with all the traditional options instantly available. If you decide to revert to the original Windows 11 behavior, simply delete this CLSID key (and its subkey InprocServer32).
Improve Explorer performance by adjusting the folder view
File Explorer can become quite slow if Windows tries to apply specific folder templates to each path (for example, "Pictures," "Videos," "Documents," etc.) and has to analyze the contents to decide which view to use. This is especially noticeable on computers with many files or mechanical hard drives.
A trick to speed up navigation is to tell the system to treat all folders as generic , making the analysis more straightforward. This is achieved in the key HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell.
Within this key, create a string value called FolderType and assign NotSpecified as its content . Save the changes and restart your computer or log out and log back in.
When you reopen Explorer, you'll notice that switching folders is smoother , especially if you frequently navigate through paths with thousands of files or a mix of different types. It's not magic, but it helps shave off precious seconds here and there. This adjustment is particularly useful if Explorer is running slowly.
Integration of the Explorer with MSIX-packaged applications
So far, we've mainly discussed extensions registered directly in the Registry , which is the classic approach used by MSI or ClickOnce installers. These technologies create keys in different branches of the Registry to register context menus, file associations, and so on.
With MSIX-packaged applications, the picture changesThe Registry is virtualized for the app, and you can no longer rely on it to register Explorer extensions. Instead, you must use the package extensions defined in the package manifest (Package.appxmanifest), where you declare file type associations, context menu verbs, and COM servers.
The simplest way to integrate with Explorer on MSIX is through the windows.fileTypeAssociation extension . You declare which file types you support (for example, .foo), what parameters your executable receives when the user opens one of those files, and what additional verbs will appear in the context menu (for example, "Resize file").
The FileTypeAssociation element defines the logical name of the association and the types it supports . Its Parameters attribute typically contains at least %1 , representing the path of the selected file. Inside, the SupportedFileTypes element lists the specific extensions (.foo, .bar, etc.), and SupportedVerbs contains the verbs that will be added to the context menu with their own parameters.
There are two important limitations to this model : you can only display verbs for file types that your app already has associated with it, and they will only be shown if your app is the default for that type. Furthermore, the verb can only launch the app's main executable (albeit with different parameters), not another arbitrary EXE.
Advanced Shell COM extensions in MSIX packages
If you need to go further (control generic folders, launch other tasks, or not open the main app every time) , the option is to create a classic Shell COM extension (DLL) and register it within the MSIX manifest, instead of using the system registry.
A Shell COM extension is essentially a DLL that exposes one or more COM classes with a unique CLSID . Windows loads this DLL when Explorer needs to display the context menu, icons, thumbnails, etc., and calls methods such as GetTitle , GetIcon , GetTooltip , or Invoke (in the case of menu commands).
The typical implementation is done in C++ for performance and memory efficiency . A classic example is a project similar to "ExplorerCommandVerb," where the CExplorerCommandVerb class implements the menu command. The Invoke method is executed when the user clicks your entry in the context menu, and from there you can do practically anything you want: display dialog boxes, launch other processes, process multiple items, etc.
To register the COM server in an MSIX package, you use the com namespace in the manifest . In the node com:Extension Category="windows.comServer" you declare the COM server, the server type (for example, SurrogateServer ) and inside a com:Class element where you indicate the Id (your CLSID) and the Path (the DLL that contains the implementation).
Integration with the file explorer is then done through the windows.fileExplorerContextMenus extension , declared within a desktop4:Extension node . This defines one or more desktop5:ItemTypes (for example, Directory , * , or a specific extension) and, within them, desktop5:Verb elements that reference your CLSID.
The DLL file must be packaged within the MSIX and copied along with the app . If you are using a Windows Application Packaging Project, the easiest way is to add the DLL to the project and mark it to always be copied to the output directory, or automate the copy with a post-compilation event in the C++ project.
After installing the MSIX package, Explorer will not load the new extension until you restart your computer . You can restart your entire computer or kill the explorer.exe process from Task Manager and restart it. After that, the new context menu entry will appear where you specified it.
Taken together, the ecosystem of Shell extensions, Registry tweaks, and MSIX manifests allows you to take File Explorer to the next level , whether it's to clean up cluttered menus, speed up navigation, integrate your own applications, or even turn complex data structures into user-friendly "folders." With some care when modifying the Registry and good planning of COM extensions, you can have a File Explorer perfectly tailored to your needs without sacrificing system stability.
