windows 11 classic context menu weird handling of IExplorerCommand

Question

windows 11 classic context menu weird handling of IExplorerCommand

peter li 46

My app registered the file and folder context menu by implementing IExplorerCommand interface. On my own PC, it worked well. The menu is shown in both the new windows 11 and the classic menu (the windows 10 style menu when you click "Show more options").

However, some users reported the menu entry is missing in only the classic menu. It shows up correctly in the new menu.

After some endless debugging (by removing all logic, and only preserve the menu entry), I found out that to ensure the menu entry shown in the classic menu, we have to register the desktop5:Verb Id initial letter to be aggressively at front when sorted. Something like putting a bunch of 0 as the Id, like the following in Package.appxmanifest

        <desktop4:Extension Category="windows.fileExplorerContextMenus">
          <desktop4:FileExplorerContextMenus>
            <desktop5:ItemType Type="Directory">
              <desktop5:Verb Id="0000ShellExtensionTest" Clsid="7A9C3E21-4B6D-4F8A-9E2C-1D5F8B3A6C40" />
            </desktop5:ItemType>
            <desktop5:ItemType Type="*">
              <desktop5:Verb Id="0000ShellExtensionTest" Clsid="7A9C3E21-4B6D-4F8A-9E2C-1D5F8B3A6C40" />
            </desktop5:ItemType>
            <desktop5:ItemType Type="Directory\Background">
              <desktop5:Verb Id="0000ShellExtensionTest" Clsid="7A9C3E21-4B6D-4F8A-9E2C-1D5F8B3A6C40" />
            </desktop5:ItemType>
          </desktop4:FileExplorerContextMenus>
        </desktop4:Extension>

If I use S as initial (like my real app), it is very unlikely to be picked up.

This behavior is very confusing and seems documented nowhere. I am not sure whether this is a BUG or something. And in that link, some known apps are indeed using this trick, without a Microsoft official confirmation on this.

0 comments

Answer accepted by question author

Taki Ly (WICLOUD CORPORATION) 4,440 Microsoft External Staff Moderator

Hello @peter li ,

Thank you for the detailed investigation and minimal repro.

I reviewed the documentation and tested this on a machine with 225 installed packaged context-menu verbs. The desktop5:Verb Id is documented only as a 1-to-64-character string. I could not find any documented ordering or count limit that determines whether packaged verbs appear in the classic Show more options menu.

On my test machine, an Id beginning with S, such as ShellExtensionTest, appeared near the end of the sorted list, while an Id beginning with 0000 appeared ahead of the other entries. This is consistent with your observation and suggests that ordering may affect which commands are surfaced. However, this remains an observed behavior rather than a confirmed Shell implementation rule.

As a workaround, you may use a unique Id that sorts earlier while keeping the same Clsid, then validate it on the affected machines. There is currently not enough documented information to classify this conclusively as either a bug or intended behavior.

If the issue continues to affect your application, you may also report it through the Windows Feedback Hub as a suspected Windows Shell issue. Please include the affected Windows build, minimal repro, tested Id values, and screenshots or a recording of the behavior.

Please let me know whether changing only the Id consistently restores the command on the affected machines. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

peter li 46 Reputation points

2026-08-19T08:04:42.84+00:00

@Taki Ly (WICLOUD CORPORATION) Thank you for your attention. If you look into my link, that contributor did find out that the menu appeared after changing the initial from S -> C. You might test the Verb Id with Z as initial.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-19T10:45:15.93+00:00

Hi @peter li ,

I tested the Z prefix directly. I built a minimal packaged IExplorerCommand extension registering verbs with different Id first characters (0000, C, S, Z) and enumerated the classic ("Show more options") IContextMenu to see which were surfaced. On my machine the Z verb appeared the same as 0000, and even with up to 36 verbs (first characters 0-9 and A-Z) all of them, including S and Z, still appeared once Explorer had fully settled. So here the first character alone did not decide visibility.

This points to the behavior being environment dependent, tied to the number and set of packaged context-menu extensions already installed rather than the letter itself, which would explain why it shows on some machines but not others. There is no documented ordering or count limit for the classic menu, so this stays observed, undocumented behavior. The unique earlier-sorting Id is a reasonable mitigation to try on the affected machines, but not a guaranteed fix.

If you can share how many packaged context-menu extensions are installed on an affected machine, I can look further into where the boundary sits. Thank you.
peter li 46 Reputation points

2026-08-19T17:24:38.1366667+00:00

@Taki Ly (WICLOUD CORPORATION) Can you attach a screenshot to show all your classic menu items? It might be related to numbers of menu entry registered, and there is a limitation to it. Please show the menu on a file.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-20T07:23:51.45+00:00

Hi @peter li ,

I opened the classic ("Show more options") menu on a file with the test extension registered and captured it below.

For this run the extension registered 12 verbs, with first characters 0 through 9 plus S and Z. All 12 appear in the menu: the ten digit-prefixed ones show as REPROIDX_048 through REPROIDX_057 (ASCII 48-57 = 0-9), REPROIDX_083 is the S verb, and REPROIDX_090 is the Z verb, interleaved with the other packaged entries such as WinRAR, Move to OneDrive, and Edit in Notepad. The whole menu here has 38 items.

I also pushed the count higher, registering up to 36 verbs (first characters 0-9 and A-Z), and all of them still appeared, so I did not hit a per-count cutoff on this machine. One thing worth noting: if the menu is opened while Explorer is still restarting after the extension is registered, a partial menu shows and some entries are missing, which can look like a hard limit, but once Explorer had fully settled every registered verb appeared.

If there is a count limit, it may sit higher than what my machine reaches, or it may depend on the total across all installed packaged extensions rather than a single package. Knowing how many packaged context-menu extensions are installed on a machine where the entry is dropped would help compare against this baseline.

Thank you.
peter li 46 Reputation points

2026-08-20T08:10:47.53+00:00

@Taki Ly (WICLOUD CORPORATION) There is still a possibility to rule out. That is due to Windows 11 limitation, multiple entry has to be placed into a cascading menu (sub menu items) in the modern menu. Please put your 083 and 090 into a secondary menu and then re-check.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-20T09:10:45.7733333+00:00

Hi @peter li ,

I moved 083 and 090 into a cascading submenu and re-checked. Instead of registering them as two top-level verbs, I registered a single top-level command (REPRO Submenu Parent) that returns ECF_HASSUBCOMMANDS and exposes 083 and 090 as its subcommands through EnumSubCommands, then reopened the classic ("Show more options") menu on a file.

Both children appear inside the cascading submenu: REPRO Submenu Parent shows at the top level, and hovering it reveals REPROIDX_083 and REPROIDX_090. So on this machine the cascading form is surfaced correctly in the classic menu, and both entries are present.

This matches the earlier top-level result, where the same two verbs also appeared, so I was not able to tie the missing entry to whether a submenu is used. If a machine that reproduces the drop shows the entries only when they are inside a cascading submenu, that would be a useful signal, and the count of packaged context-menu extensions installed there would still help locate where the boundary sits.
peter li 46 Reputation points

2026-08-20T09:41:18.89+00:00

@Taki Ly (WICLOUD CORPORATION) Sorry I should describe it more clearly. Please register a lot of first-level entries (that is your previous 0-9 entries) and also register some second-level entry (that is your 083 and 090). The user's symptom is they have a lot of first level entries and then my second-level entries is not visible.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-21T10:50:54.0066667+00:00

Hi @peter li ,

I registered both levels in one package: ten top-level first-level verbs (REPROIDX_048 through REPROIDX_057, matching the earlier 0-9 set) plus one first-level parent (REPRO Submenu Parent) whose subcommands are the second-level entries REPROIDX_083 and REPROIDX_090. I then opened the classic ("Show more options") menu on a file.

All ten first-level entries are present, and the second-level entries are also present inside the parent's submenu, as the screenshot shows. I then increased the first-level set to 34 entries (0-9 and A-Y, 60 items in the whole menu) while keeping the same submenu, and both second-level entries still appeared. So, on this machine I did not see the second-level entries drop when many first-level entries are registered.

Since the symptom reproduces on the affected users' machines but not here, it still looks tied to the total set already present on those machines rather than to the two-level layout by itself. On a machine that shows the drop, it would help to know the total number of packaged context-menu entries installed and whether removing some first-level entries brings the second-level ones back, which would point directly at a count boundary.

1 additional answer

Your answer

peter li 46 Reputation points

2026-08-19T08:04:42.84+00:00

@Taki Ly (WICLOUD CORPORATION) Thank you for your attention. If you look into my link, that contributor did find out that the menu appeared after changing the initial from S -> C. You might test the Verb Id with Z as initial.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-19T10:45:15.93+00:00

Hi @peter li ,

I tested the Z prefix directly. I built a minimal packaged IExplorerCommand extension registering verbs with different Id first characters (0000, C, S, Z) and enumerated the classic ("Show more options") IContextMenu to see which were surfaced. On my machine the Z verb appeared the same as 0000, and even with up to 36 verbs (first characters 0-9 and A-Z) all of them, including S and Z, still appeared once Explorer had fully settled. So here the first character alone did not decide visibility.

This points to the behavior being environment dependent, tied to the number and set of packaged context-menu extensions already installed rather than the letter itself, which would explain why it shows on some machines but not others. There is no documented ordering or count limit for the classic menu, so this stays observed, undocumented behavior. The unique earlier-sorting Id is a reasonable mitigation to try on the affected machines, but not a guaranteed fix.

If you can share how many packaged context-menu extensions are installed on an affected machine, I can look further into where the boundary sits. Thank you.
peter li 46 Reputation points

2026-08-19T17:24:38.1366667+00:00

@Taki Ly (WICLOUD CORPORATION) Can you attach a screenshot to show all your classic menu items? It might be related to numbers of menu entry registered, and there is a limitation to it. Please show the menu on a file.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-20T07:23:51.45+00:00

Hi @peter li ,

I opened the classic ("Show more options") menu on a file with the test extension registered and captured it below.

For this run the extension registered 12 verbs, with first characters 0 through 9 plus S and Z. All 12 appear in the menu: the ten digit-prefixed ones show as REPROIDX_048 through REPROIDX_057 (ASCII 48-57 = 0-9), REPROIDX_083 is the S verb, and REPROIDX_090 is the Z verb, interleaved with the other packaged entries such as WinRAR, Move to OneDrive, and Edit in Notepad. The whole menu here has 38 items.

I also pushed the count higher, registering up to 36 verbs (first characters 0-9 and A-Z), and all of them still appeared, so I did not hit a per-count cutoff on this machine. One thing worth noting: if the menu is opened while Explorer is still restarting after the extension is registered, a partial menu shows and some entries are missing, which can look like a hard limit, but once Explorer had fully settled every registered verb appeared.

If there is a count limit, it may sit higher than what my machine reaches, or it may depend on the total across all installed packaged extensions rather than a single package. Knowing how many packaged context-menu extensions are installed on a machine where the entry is dropped would help compare against this baseline.

Thank you.
peter li 46 Reputation points

2026-08-20T08:10:47.53+00:00

@Taki Ly (WICLOUD CORPORATION) There is still a possibility to rule out. That is due to Windows 11 limitation, multiple entry has to be placed into a cascading menu (sub menu items) in the modern menu. Please put your 083 and 090 into a secondary menu and then re-check.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-20T09:10:45.7733333+00:00

Hi @peter li ,

I moved 083 and 090 into a cascading submenu and re-checked. Instead of registering them as two top-level verbs, I registered a single top-level command (REPRO Submenu Parent) that returns ECF_HASSUBCOMMANDS and exposes 083 and 090 as its subcommands through EnumSubCommands, then reopened the classic ("Show more options") menu on a file.

Both children appear inside the cascading submenu: REPRO Submenu Parent shows at the top level, and hovering it reveals REPROIDX_083 and REPROIDX_090. So on this machine the cascading form is surfaced correctly in the classic menu, and both entries are present.

This matches the earlier top-level result, where the same two verbs also appeared, so I was not able to tie the missing entry to whether a submenu is used. If a machine that reproduces the drop shows the entries only when they are inside a cascading submenu, that would be a useful signal, and the count of packaged context-menu extensions installed there would still help locate where the boundary sits.
peter li 46 Reputation points

2026-08-20T09:41:18.89+00:00

@Taki Ly (WICLOUD CORPORATION) Sorry I should describe it more clearly. Please register a lot of first-level entries (that is your previous 0-9 entries) and also register some second-level entry (that is your 083 and 090). The user's symptom is they have a lot of first level entries and then my second-level entries is not visible.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-21T10:50:54.0066667+00:00

Hi @peter li ,

I registered both levels in one package: ten top-level first-level verbs (REPROIDX_048 through REPROIDX_057, matching the earlier 0-9 set) plus one first-level parent (REPRO Submenu Parent) whose subcommands are the second-level entries REPROIDX_083 and REPROIDX_090. I then opened the classic ("Show more options") menu on a file.

All ten first-level entries are present, and the second-level entries are also present inside the parent's submenu, as the screenshot shows. I then increased the first-level set to 34 entries (0-9 and A-Y, 60 items in the whole menu) while keeping the same submenu, and both second-level entries still appeared. So, on this machine I did not see the second-level entries drop when many first-level entries are registered.

Since the symptom reproduces on the affected users' machines but not here, it still looks tied to the total set already present on those machines rather than to the two-level layout by itself. On a machine that shows the drop, it would help to know the total number of packaged context-menu entries installed and whether removing some first-level entries brings the second-level ones back, which would point directly at a count boundary.

Answer 1

Taki Ly (WICLOUD CORPORATION) 4,440 Microsoft External Staff Moderator

Hi @peter li ,

I'm working on this issue and will try to get back to you soon. Thank you for your patience.

0 comments