The Windows 11 Context Menu: Where Your App's Right-Click Entries Went, and the Supported Way to Get Them Back

A user upgrades to Windows 11, right-clicks a file, and the entry your line-of-business tool has put there for eight years is gone. The backup agent's "Restore previous version" is gone. The developer utility's "Open Bash here" is gone. Everything looks broken. Nothing is broken. The entries moved, and the reason they moved is a deliberate architectural change in the shell that has a documented, supported answer - and a widely-copied registry hack that is neither.

The problem: the entry is not missing, it is demoted

Start with the vocabulary, because half the confusion here comes from two words being used loosely.

A context menu - Microsoft's own documentation calls it a shortcut menu - is the list you get when you right-click something in File Explorer or on the desktop. A shell extension is a piece of third-party code that adds entries to that list. A shortcut menu handler, or context menu handler, is the specific kind of shell extension that does this.

Historically, a shortcut menu handler was a COM object - a Component Object Model object, meaning a class Windows can create on demand by GUID - implemented in a DLL. Explorer loaded that DLL into its own process and asked it for menu items. Every 7-Zip, TortoiseGit, WinMerge, Notepad++, antivirus scanner and backup agent right-click entry you have ever seen worked this way.

Windows 11 introduced a second, compact context menu. It is not a skin over the old one. It is a different menu, built by different code, from a different registration source. Legacy handlers are not enumerated for it at all.

So the symptom in the field looks like this. A helpdesk ticket says the enterprise backup client "lost its right-click integration after the Windows 11 upgrade". The vendor insists nothing changed. Both are telling the truth. The entry is one click away, under Show more options at the bottom of the compact menu.

What happens next is the actual problem. An admin searches for "restore classic context menu Windows 11", finds a two-line reg add command on a forum, tests it on their own machine, sees it work instantly, and pushes it to ten thousand devices as a login script or an Intune platform script. That command is not in any Microsoft documentation. It has no Group Policy backing. It disables the new menu wholesale rather than restoring one app's entry. And its failure modes are quiet - which is the worst kind.

Why it happens: two menus, two registration models

Here is the chain, in order, from the moment the user right-clicks.

Path 1: the Windows 11 compact menu

1. The user right-clicks a file in File Explorer. The window belongs to explorer.exe.
2. Explorer builds the modern menu using the packaged COM class registered on this device under the CLSID {86ca1aa0-34aa-4e8b-a509-50c905bae2a2}, whose registered display name is File Explorer Context Menu and whose in-process server is C:\Windows\System32\Windows.UI.FileExplorer.dll.
3. Explorer places the common commands - cut, copy, rename, delete, share - as icons at the top.
4. It then enumerates commands that apps have registered through the windows.fileExplorerContextMenus package manifest extension. Microsoft's design guidance is that "App extensions are grouped together below Shell verbs", and that an app with more than one command is folded into a flyout attributed to that app.
5. For each such command, Explorer activates the app's COM class and calls its IExplorerCommand methods - GetTitle, GetIcon, GetState - to decide what to draw and whether it should be enabled.
6. The Show more options item is appended at the bottom.

Path 2: the Windows 10 menu behind Show more options

1. The user clicks Show more options, or presses Shift+F10, or presses the dedicated menu key, or holds Shift while right-clicking.
2. Explorer builds the classic menu using the long-standing shell code in shell32.dll and windows.storage.dll.
3. That code reads HKEY_CLASSES_ROOT looking for shellex\ContextMenuHandlers subkeys under the relevant shell object - * for all files, Directory for folders, Directory\Background for the folder background, and so on.
4. For each handler subkey it reads the CLSID, resolves that CLSID to an InprocServer32 DLL, loads the DLL into the Explorer process, and calls IContextMenu on it.
5. It also reads static verbs registered under HKEY_CLASSES_ROOT\<ProgID>\shell\<verb>.

Step 4 of Path 2 is the reason for the whole redesign. Microsoft's documentation on shortcut menu handlers is blunt about the risk: "Take care when creating in-process handlers as they can cause harm to the process that loads them." The developer blog is blunter still, noting that legacy commands "run in-process in Explorer, which can cause performance and reliability issues." A single badly written handler could hang or crash the shell for the whole session. The compact menu keeps that code off the fast path.

The registry surface: classic handler registration

Every classic handler lives beneath one of these. The shell object is the part that varies.

Two more subkey names matter and are frequently confused with ContextMenuHandlers. DragDropHandlers holds handlers that appear when you right-drag an object and drop it. PropertySheetHandlers holds tabs added to the Properties dialog. Both are registered the same way, both also implement in-process COM, and both are outside the compact menu.

The registry surface: approval and policy

These two keys govern whether a registered handler is allowed to run at all.

For MSIX-packaged apps there is a manifest element that writes the Approved entry for you: desktop7:ApprovedShellExtension, taking a Name and a Clsid. Microsoft is explicit that using it requires the package to set desktop7:Scope to machine, which in turn requires the custom capability Microsoft.classicAppCompatElevated_8wekyb3d8bbwe - and that capability "is granted to only a limited set of apps". In practice that route is closed to most software.

The binaries and processes involved

Only files verifiable on a live Windows 11 device are listed. Every one of these was confirmed present on the build used for this article.

How to verify: inventory before you touch anything

Do not change a registry value until you know what is currently registered. The first check is a thirty-second manual one, and it settles most tickets.

Step 1: confirm the entry is only demoted, not gone

Right-click the file. If the app's entry is not in the compact menu, press Shift+F10 - or hold Shift and right-click, or press the dedicated menu key if the keyboard has one. If the entry appears there, the app is a legacy IContextMenu handler and there is nothing wrong with the device. That is the expected, documented behaviour.

Step 2: read the classic handler registration directly

This command lists every classic shortcut menu handler registered for all files, showing the handler name and the CLSID it points at. Run it in a normal console; no elevation is needed to read HKLM class keys.

Read it like this. The PSChildName column is the handler's arbitrary name - it is a label, and Windows never shows it to a user. The Clsid column is what actually matters, because that GUID is the COM class Explorer will try to create.

Step 3: resolve a CLSID to the DLL behind it

A CLSID on its own tells you nothing. Resolve it to the file on disk, then check the file is still there. This is where orphaned handlers surface - a registration left behind by an uninstall that removed the DLL but not the keys.

Step 4: check whether the unsupported override is already deployed

Before you argue about whether to deploy the hack, find out whether a previous admin already did. The override is per-user, so it hides in HKEY_CURRENT_USER and will not appear in a machine-scope audit.

Step 5: run the companion inventory script

Doing steps 2 to 4 by hand across eight shell objects and two hives is tedious and easy to get wrong. The companion script does the whole sweep, resolves every CLSID, checks every DLL on disk, reports the Approved and policy state, and gives a plain verdict on the override. It is strictly read-only - it never creates, changes or deletes a registry value, and it does not restart Explorer.

Event Viewer: honestly not applicable

There is no Event Log channel for context menu construction, and Microsoft publishes no Event IDs for it. This is not an oversight in this article - it is a design consequence. Menu building happens thousands of times a day inside the shell process on the UI path. Emitting an event per handler activation would be self-defeating. If a handler fails to load, Explorer silently omits the item.

Two adjacent channels do exist and are genuinely useful, so use them instead of hunting for IDs that do not exist.

For the packaging side there is also a cmdlet rather than a log file. Get-AppxLog returns the app package installation log produced during deployment, including errors and warnings. That is the documented way to see why a sparse package registration failed.

Services and scheduled tasks: also not applicable

No Windows service drives the context menu, and there is no scheduled task under \Microsoft\Windows\... that rebuilds or refreshes it. Menu construction is synchronous work inside explorer.exe at the moment of the right-click. The only service adjacent to this feature area is AppXSvc (display name AppX Deployment Service), which must be running for a packaged or sparse-packaged app's registration to be applied - but it plays no part in drawing a menu.

Defender and security policy: not applicable, and here is why

Nothing in this feature area is configured through Microsoft Defender Antivirus, Attack Surface Reduction rules, exploit protection, Windows Defender Application Control or the firewall. There is no Endpoint Security profile for context menus. It is worth stating plainly because context menu handlers are DLLs loaded into the shell, which sounds like something ASR ought to govern - it does not. The relevant control is the shell's own approval mechanism, EnforceShellExtensionSecurity plus the Approved list, which is an Administrative Template setting, not a Defender one.

The fix: what is supported, and what only looks like a fix

The supported answer, route 1: the vendor implements IExplorerCommand

This is the real fix and the only one Microsoft documents for getting an app into the Windows 11 compact menu. It is work for the software vendor, not for you, but knowing exactly what to ask for turns a vague support ticket into an actionable one.

Microsoft's requirement is stated directly: Windows 11 apps extend the modern File Explorer context menu by implementing IExplorerCommand and registering the command with app identity. Three parts are needed.

1. A native DLL implements one or more COM classes exposing IExplorerCommand. C++ is the usual choice because the code runs on the shell integration path.
2. The package manifest registers each COM class as a windows.comServer extension, using com:SurrogateServer and a com:Class whose Id is the command's CLSID.
3. The package manifest registers the command as a windows.fileExplorerContextMenus extension, associating a shell item type with that same CLSID via desktop5:ItemType and desktop5:Verb.

The desktop5:ItemType/@Type attribute is the modern equivalent of the old shell object names: * for files, Directory for selected folders, Directory\Background for a folder background. The desktop5:Verb/@Clsid must match the com:Class/@Id and the CLSID on the COM class itself. Get one of the three out of step and the command silently never appears.

Microsoft's own closing note on the topic is the sentence to quote at a vendor: use "Show more options" only to inspect legacy context-menu extensions, because a command registered through windows.fileExplorerContextMenus and implemented with IExplorerCommand appears in the Windows 11 context menu.

The supported answer, route 2: sparse package for an unpackaged Win32 app

The obvious vendor objection is "our product is a Win32 installer, we are not shipping MSIX". That objection does not hold, and this is the most useful thing in this article to bring to a vendor conversation.

An unpackaged Win32 app can use the same IExplorerCommand and the same manifest registrations by installing a sparse package - Microsoft also calls this "packaging with external location". A sparse package does not contain the app binaries. It is a small identity-only package that references the externally installed app. The existing installer, the existing binary locations and the existing update process all stay as they are.

The manifest declares uap10:AllowExternalContent as true in Properties, sets the application's uap10:TrustLevel to mediumIL and its uap10:RuntimeBehavior to win32App, and requests the runFullTrust and unvirtualizedResources restricted capabilities. The AllowExternalContent feature was introduced in Windows 10 version 2004, build 19041, so every supported Windows 11 device has it.

The supported answer, route 3: keep the legacy handler but declare it in MSIX

If a vendor is already repackaging as MSIX and does not want to rewrite the handler, Microsoft documents a middle path. Add the desktop9 namespace and declare the existing IContextMenu implementation through windows.fileExplorerClassicContextMenuHandler, or windows.fileExplorerClassicDragDropContextMenuHandler for right-drag handlers, with a desktop9:ExtensionHandler per item type. Microsoft states this feature is available on Windows 11 version 21H2, build 22000, and later, and requires MaxVersionTested greater than 10.0.21300.0.

The unsupported hack: exactly what it is and exactly why it works

The command that circulates on forums creates a subkey with an empty default value.

The mechanism is not magic, and it rests on one behaviour that Microsoft does document. HKEY_CLASSES_ROOT is a merged view of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes, and, in Microsoft's exact words, "The user-specific settings have priority over the default settings."

So the chain is: Windows registers the modern menu class in the machine store with a real DLL path. The hack writes the same CLSID into the per-user store with an empty path. COM resolves the per-user copy first, gets an empty server path, and activation of the class fails. Explorer, unable to create the modern menu, falls back to the Windows 10 menu. Every legacy handler reappears at the top level, and the user is delighted.

Group Policy reality: there is no setting for this

This is the finding, so let it be plain. There is no Group Policy setting that chooses between the Windows 11 and Windows 10 context menu. Not in any shipped Administrative Template. The two documented context-menu policies both do something else, and both are worth knowing precisely so nobody mistakes them for the switch.

The first is Remove File Explorer's default context menu, registry value NoViewContextMenu. Its documented description is that it "Removes shortcut menus from the desktop and File Explorer" and that if enabled, "menus don't appear when you right-click the desktop or when you right-click the items in File Explorer". It suppresses right-clicking entirely. To find it:

1. Open the Group Policy Management Editor on the GPO you intend to change, or gpedit.msc for a local test.
2. Expand User Configuration. This is a per-user policy; it does not exist under Computer Configuration.
3. Expand Administrative Templates, then Windows Components, then File Explorer.
4. Double-click Remove File Explorer's default context menu.
5. Select Enabled only if you genuinely want right-click menus gone. Click Apply, then OK.
6. Confirm on the client with gpupdate /target:user /force, then read HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer and expect NoViewContextMenu to be 1.

The second is Allow only per user or approved shell extensions, registry value EnforceShellExtensionSecurity. Its documented purpose is to direct Windows "to only run those shell extensions that have either been approved by an administrator or that won't impact other users of the machine". The same navigation applies:

1. Navigate to User Configuration > Administrative Templates > Windows Components > File Explorer.
2. Double-click Allow only per user or approved shell extensions.
3. Select Enabled, click Apply, then OK.
4. Both policies live in WindowsExplorer.admx and write to Software\Microsoft\Windows\CurrentVersion\Policies\Explorer.
5. Before enabling this in production, inventory the Approved list first. A handler that is registered but not approved stops loading, and the entry disappears from the classic menu too.

Intune reality: the same two policies, no menu switch

Both settings are ADMX-backed Policy CSP entries. Microsoft documents them as user-scope only, which matters when you choose how to deliver them.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices, then Configuration, then Create, then New policy.
3. Set Platform to Windows 10 and later and Profile type to Settings catalog. Click Create.
4. Name the profile something an auditor will understand later, for example W11 - File Explorer shell extension approval.
5. Click Add settings and search the picker for File Explorer.
6. Pick Allow only per user or approved shell extensions to deliver EnforceShellExtensionSecurity, or Remove File Explorer's default context menu to deliver NoViewContextMenu. Set the toggle deliberately.
7. Assign the profile to a user group. Because both policies are user-scope, assigning them to a device group is the classic mistake that makes them appear to do nothing.
8. Review and create, then confirm delivery under Devices > Configuration > the profile > Device status.

If you would rather use a custom OMA-URI profile, the documented paths are exactly these two. Both are ADMX-backed, which means the value must be supplied in SyncML format rather than as a bare number.

Proof it worked: a real run on build 26200

The output below is a genuine run of the companion script on a Windows 11 Enterprise device, build 26200, under Windows PowerShell 5.1. Identifiers are replaced and one third-party product name is redacted. Nothing else is altered.

The second half of the same run answers the question the whole article is about.

Three things in that output are worth reading carefully, because each one is a decision point.

First, HKCU Approved : absent together with EnforceShellExtensionSecurity : not configured means no approval enforcement is in play. Every registered handler is allowed to load. If you turn that policy on without first populating the Approved list, entries will vanish from the classic menu too, and the tickets will look identical to the Windows 11 demotion tickets you were trying to solve.

Second, PackagedCom\ClassIndex : 124 shows the modern path is alive and well on this device. Packaged apps are registering COM classes normally. If a vendor claims Windows 11 "does not support" context menu extensions, this number is the counter-argument.

Third, the verdict line is the one to put in a report. It states which of the two menu behaviours the device is actually in, and it distinguishes "the override is absent" from "I could not read the key" - the script exits 1 rather than printing a clean-looking result when any read fails.

References

Microsoft official

Community

One community write-up was fetched and verified as being genuinely on this topic. It is listed because it documents the unsupported override that this article argues against deploying - useful for recognising the exact command your users have already run, not as a recommendation.

Companion script

The read-only inventory script used for the output above lives in the Windows 11 scripts repository, one folder per post:

Get-ShellContextMenuInventory.ps1 - enumerates every classic context menu handler, resolves each CLSID to its backing DLL, flags orphans, reports the Approved and policy state, and gives a verdict on the unsupported override. It never writes a registry value.