Repository navigation
Add Reload to the start button's context menu (StartMenu.exe -reload) - #2577
Merged
Merged
Conversation
Reload exits the menu and starts it again, so it goes through startup anew: settings, the item and icon caches in memory, and the hook into Explorer. Useful after something the running menu does not notice, like a Store app updating itself under a pinned shortcut. Until now that took Exit and starting StartMenu.exe again by hand. The item sits above Exit, shown and disabled under the same conditions (EnableExit, CanShowMenu), since it exits first. It starts "StartMenu.exe -reload" from the DLL's own folder, so it works for any install location. StartMenu.exe -reload is the new part. Like -exit it posts MSG_EXIT to the running menu, but then it waits for that process to end (up to 20 s) and carries on as a normal start, owning the single-instance mutex. It waits for the process, not only the mutex: the old menu releases the mutex just before it exits, and the new one should hook Explorer only once the old one is gone. "-reloadsettings" also contains "-reload", so -reload counts only when no other command matched. The label is Menu.MenuReload, in English only for now; other languages fall back to the English default until translated.
The Operation section lists what the start button's right-click menu does; it now includes reloading. The Settings section said a few settings need the menu to be exited before they show; reloading is the direct way now, so it says that. The Command Line section gets -reload, next to -exit, including that it just starts the menu when none is running (checked on the real machine). It also no longer counts the parameters: "supports 5" was already short of what StartMenu.exe accepts (for example -reloadsettings), and adding one made it 6 of more.
The -reload handling sat inline in wWinMain, three levels deep, with two bare timeouts. It is now TakeOverFromRunningMenu, with the timeouts named and explained, and wWinMain keeps a three-line call. The start button's Reload item calls ReloadStartMenu instead of building the path inline. One difference, on purpose: if the running menu's window is found but its process can't be opened, the old code still told the menu to exit, then gave up waiting and left no menu running. Now it leaves the running menu alone and returns, as when no menu is found.
ge0rdi
approved these changes
Nov 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2112, which asks for a command line option to restart the menu.
Restarting the menu currently takes Exit and then starting
StartMenu.exeagain. From a scriptthat doesn't work reliably, as #2112 describes:
-exitonly postsMSG_EXITto the running menuand returns, so a
StartMenu.exestarted right after it often still finds the single-instancemutex held by the exiting menu, and quits ("exit (mutex exists)"). The workaround is to wait a few
seconds and hope.
This adds
StartMenu.exe -reload. Like-exitit postsMSG_EXITto the running menu, but then itwaits for that process to end (up to 20 s) and takes the mutex, and carries on as a normal start.
It waits for the process, not only the mutex, because the old menu releases the mutex just before
it exits, and the new one should hook Explorer only once the old one is gone. If no menu is
running,
-reloadjust starts it. If the running menu doesn't exit in time, it is left running and-reloadgives up.The start button's right-click menu gets a Reload item that runs
StartMenu.exe -reloadfromthe DLL's own folder. It sits above Exit and is shown and disabled under the same conditions
(
EnableExit,CanShowMenu), since it exits first.Unlike
-reloadsettings, which rereads the settings from the registry, this goes through startupanew: language files (the case in #2112), the item and icon caches in memory, and the hook into
Explorer.
Notes:
-reloadsettingsalso contains-reload, so-reloadcounts only when no other command matched.Menu.MenuReload, in English only for now. Other languages fall back to theEnglish default until translated.
StartMenu.html) mentions Reload in the right-click menu and in the Settings section,and lists
-reloadwith the other command line parameters. It no longer counts them: "supports 5"was already short of what
StartMenu.exeaccepts.Tested on Windows 11 26H2 (26300):
-reload, and Explorer kept running.StartMenu.exe -reload5 times in a row, each started as soon as the previous one was therunning menu: every time the old process ended, exactly one new menu was running, and Explorer
(same process throughout) kept running with StartMenuDLL loaded.
StartMenu.exe -reloadwith no menu running: starts the menu.Timing: a reload takes about 1.3 s, most of it the 1 s wait in
ExitThreadProc. Reloading a menuthat started less than 5 s earlier takes about 6 s. That is not from
-reload:RefreshInfoThreadfirst waits up to
REFRESH_DELAY(5 s) form_StartEventwithout watchingm_ExitEvent, andshutdown waits for that thread. A plain
-exitright after a start waits the same way. The startuplog shows it: the exit request at +0 ms, the DLL leaving Explorer at +6000 ms.