weixin_39793434
2021-01-07 01:31 阅读 1

Start Menu moves to the background if fullscreen program is running on primary display

Describe the bug When using multiple displays with DisplayFusion taskbars, if any fullscreen application is running on the primary display, Start Menu won't open properly on any secondary displays. It flashes for a split second, then moves to the bottommost level (under every open window), making it unusable.

To Reproduce Steps to reproduce the behavior: 1. Disable built-in multi monitor taskbars 2. Enable DisplayFusion multi monitor taskbars 3. Run any fullscreen application on primary monitor (e.g. some game or video player) 4. Try to open Start Menu on any secondary monitor (either with click or Win key) 5. Observe Start menu flashing and immediately moving under every open window

Expected behavior Start Menu should open and stay on top, be visible and clickable.

Screenshots main start menu opened start_menu_hidden

submenu opened with cursor keys start_menu_hidden_submenu_shown

Version: - Open-Shell: 4.4.142 - OS: Windows 10 19041

Additional context After the bug has occurred, interacting with the Start Menu somehow (e.g. going to a submenu with cursor keys and back) brings it back to the top. Interestingly, the submenus in these cases always open on top while the main column remains invisible until going back to it with cursor keys. Additional findings: 1) happens with any fullscreen application, not tied to a specific program or a type of program 2) happens only if the trigger app is in full screen mode - setting a game to windowed or restoring video player to regular window brings back the Start Menu functionality 3) affects this combo only (trigger app on primary, start menu on secondary) - start menu opens on the primary monitor even if the trigger app is running, and it opens everywhere if the trigger app is running on a secondary display 4) not monitor specific - moving the primary role to another display doesn't bring any change in this behavior 5) doesn't happen with Windows built-in taskbars, BUT 6) doesn't happen with any other Start Menus with DisplayFusion either (tried built-in Start Menu, Start10/Classic Start Menu/Start Menu X, StartIsBack) 7) this bug was already present in Classic Shell (tested) DF thread about the problem: https://www.displayfusion.com/Discussions/View/classic-shell-start-menu-opening-in-the-background/?ID=60c5cfb5-1c53-4b0b-9890-fd41a1850593 Since this only affects Open Shell and they don't seem to be able to fix it (or it takes at least 3 years), I'm hoping there's something you can do about it. I'd be most happy with any simple workaround, like somehow forcing the Start Menu to always be on top.

该提问来源于开源项目:Open-Shell/Open-Shell-Menu

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

34条回答 默认 最新

  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    I just found out about logging, so I made one. While it was running, I tried to open Start Menu twice, first time it succeeded - also a new piece of information here, the full screen application was in the background at this moment (behind regedit). Second time the only thing I did is to bring the full screen app to the foreground and tried to open Start Menu on the same monitor as before - this time the problem was reproduced, it went straight behind all windows. I hope this helps identify the problem. StartMenuLog.txt

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    Any feedback on this please? DF just released a new version but they still seem to be unable to fix this.

    点赞 评论 复制链接分享
  • weixin_39568889 weixin_39568889 2021-01-07 01:31

    test this :
    https://ci.appveyor.com/project/passionate-coder/open-shell-menu/build/artifacts

    best

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    no change :(

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    is there anything else I can try or do, logs repro etc ?

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:31

    Some developer needs to replicate it and debug what's the problem. Unfortunately currently I don't have multiple monitors at hand :(

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    I'd gladly give it a try with some basic instructions, swdev here feeling adventurous.

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:31
    • Install VS2019 and required components (see BUILDME.txt for more info)
    • Open OpenShell.sln in VS
    • Right click on StartMenu project and select Set as Startup Project
    • Rebuild StartMenu project
    • Exit current Open-Shell instance (right click on Start and select Exit)
    • In VS run current project (Ctrl + F5)
    • In Debug -> Attach to process .. select explorer.exe and attach to it
    • Now you can add breakpoints (for example CMenuContainer::ToggleStartMenu is function that creates actual start menu)
    • BP should be triggered once you click on Start button
    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    Thank you, the instructions are perfect, but I can't get it to run in VS for some reason. I can see the StartMenu.exe running in Task Manager, did attach to explorer.exe but nothing is happening when I invoke the start menu (either by click or win key), just the built-in start menu opens. Got any idea what I'm doing wrong?

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:31

    Forgot to mention you should build Debug|x64 configuration.

    Once you'll attach to explorer.exe process you can break in (Ctrl+Alt+Break) and check Modules window whether StartMenuDLL.dll is loaded (it should be loaded from folder where you did compile it).

    If DLL is loaded press Continue (F5) and then you can set breakpoints. You can put BP to CMenuContainer::ToggleStartMenu in MenuContainer.cpp line 7487.

    Then it should break there as you'll press Start button.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    Thanks, the build config was indeed the problem.

    I started to work on it and could set and use breakpoints, everything seemed to be working with VS but I didn't have time for a week and now OpenShell won't even show when running from VS. I'm doing exactly the same (rebuild, exit, ctrl+f5, attach). For Win key, the default start menu is being shown (it's set to show OpenShell) and for clicking the button, I get the following output message (the default start menu is then may or may not show): pcshell\shell\explorer\cortanataskbarbutton.cpp(385)\Explorer.EXE!00007FF76B7A8740: (caller: 00007FF76B708ADB) ReturnHr(100) tid(18b4) 80070578 Invalid window handle.

    When I set a breakpoint at the same line as before, it now has a tooltip saying: The breakpoint will not currently be hit. No symbols have been loaded for this document.

    I tried restarting everything, deleting/readding the entire project, running with/without debugging etc. even updated VS but nothing seems to make a difference.

    What could the problem be now?

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:31

    When I set a breakpoint at the same line as before, it now has a tooltip saying: The breakpoint will not currently be hit. No symbols have been loaded for this document.

    This means you don't have Open-Shell running.

    Try to rebuild StartMenu project (Debug|x64) again. And make sure it ended without any error and proper files were created. There should be StartMenu.exe and StartMenuDLL.dll (with actual dates) in Src\StartMenu\Debug64 created.

    Then try to just run the executable from the folder. You should see Open-Shell start menu now. And then you should be able to attach explorer and debug it.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    Starting from the created .exe file makes it run, but only affects Win key invoking, clicking the button still shows the default start menu. The regular installed version works with click. This seems unimportant but makes debugging impossible because winkey invoking is also bugged (in regular installed version as well) and it always opens the start menu on the primary monitor, no matter where the pointer or the active window is.

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:31

    Check Settings -> Controls -> Left Click opens. Do you have Open-Shell Menu enabled there?

    If so then put break point into HookDesktopThread function (this is actual hooking thread), line 3570 (it is within if (bClick || bNcClick) block). This should be invoked once you left-click on start menu. It should then decide what action to do. Normally it should call ToggleStartMenu at line 3608.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    Now somehow I managed to run it from VS and attach to explorer, and breakpoints started to work. Open-Shell is selected for left click action in settings. I have inserted a breakpoint to L3570 and L3608 but neither gets hit for left click. Putting one at the function you suggested earlier (CMenuContainer::ToggleStartMenu) gets hit only when pressing winkey. In both cases I get the above error for cortanataskbarbutton and nothing else in the output while winkey opens OpenShell menu and left click does nothing (I think the behavior when it opened the built in start menu was caused by opening and closing OpenShell several times when I was trying to get it to work, now I did a cold boot and the very first thing I did is to start VS and rebuild/run the project). Might worth to note that OpenShell is not set to autorun on Windows startup.

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:31

    I have inserted a breakpoint to L3570 and L3608 but neither gets hit for left click.

    Then try to put BP at the beginning of HookDesktopThread to see if the hook is even getting called. Eventually put BP to InitStartMenuDLL that is registering the hook. Look for: g_StartHook=SetWindowsHookEx(WH_GETMESSAGE,HookDesktopThread,NULL,GetCurrentThreadId());

    If the hook is correctly installed and then it is not called then I guess there has to be some other SW that is doing the same hook and not calling next one in chain.

    Might worth to note that OpenShell is not set to autorun on Windows startup.

    Have you tried to run it on startup?

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    I think I'm still missing something in VS options because only the compiled one behaves like this. Or is it possible that the code in the repo is different from the one in the latest installer version? If I start the compiled one (either from VS or the generated exe), it only works with winkey and not click. The normal installed version works with click also. Both are set to open Open-Shell on click.

    I have tried to run both at startup, behavior is the same. Compiled one only ever works for winkey.

    Also, is there another process started other than StartMenu.exe? If I exit the installed version (by right clicking on the start button and selecting Exit), and/or kill StartMenu.exe from Task Manager, they still remain active and I can't find any related running processes.

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:31

    Or is it possible that the code in the repo is different from the one in the latest installer version?

    Latest nightly version (4.4.162) was compiled from the code in repo. I'm not aware of any changes that could affect mouse click behavior.

    Also, is there another process started other than StartMenu.exe?

    No.

    If I exit the installed version (by right clicking on the start button and selecting Exit), and/or kill StartMenu.exe from Task Manager, they still remain active and I can't find any related running processes.

    Right click + Exit is the preferred way of exiting Open-Shell. After that StartMenuDLL.dll should be unloaded from explorer.exe (you can verify that using Process Explorer / Process hacker tools). If the DLL stays loaded (try to wait few minutes, it may happen that something does still reference it). Anyways, you should definitely make sure only your compiled StartMenuDLL.dll is loaded inside explorer.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:31

    Right click + Exit is the preferred way of exiting Open-Shell.

    Unfortunately, I can't use that with the debug version because it doesn't react to right click either.

    After that StartMenuDLL.dll should be unloaded from explorer.exe (you can verify that using Process Explorer / Process hacker tools).

    It never gets unloaded after exiting OpenShell by any method. I can only get rid of it by restarting explorer.exe in most cases, but sometimes even that doesn't work, StartMenuDLL.dll is just stuck there, sometimes StartMenuHelper64.dll too.

    Anyways, you should definitely make sure only your compiled StartMenuDLL.dll is loaded inside explorer.

    Checked. It is loaded alongside the compiled version and only the one from the compiler output is loaded.

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:32

    It never gets unloaded after exiting OpenShell by any method.

    You may also try running: "C:\Program Files\Open-Shell\StartMenu.exe" -exit

    This should exit actual Open-Shell instance.

    sometimes StartMenuHelper64.dll too

    That one is ok.

    Checked. It is loaded alongside the compiled version and only the one from the compiler output is loaded.

    My guess is that those two are simply clashing (that's why mouse click doesn't work for you). You simply have to get to the state where Open-Shell is not loaded and then you can start your debug version and debug it.

    I'm not sure what else to do. In worst case just uninstall Open-Shell (you can install it back once you are done with debugging). Your settings and everything will be not affected.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:32

    You may also try running: "C:\Program Files\Open-Shell\StartMenu.exe" -exit

    Thanks! That finally works for exiting the running instance properly.

    But my problem is still that I can't get the compiled version to work or at least behave the same way as the installed one. I never start the latter, it is not set to autostart, no exe is running from it, no dll is loaded, so it's not a clash. I start the compiled exe first thing after a cold boot and it never reacts to any kind of clicks, only winkey. Same if it's set to autostart.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:32

    I still can't figure out why the compiled version behaves differently, but how about a different approach: since both bugs (disappearing on secondary displays & always opening on primary for winkey) are only present if the built-in multi monitor taskbars are disabled, would it be possible to ignore this condition or "emulate" it somehow? Leaving it enabled is not an option because it generates a lot of problems.

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:32

    I don't quite understand what do you mean. Unless we'll figure out what exactly is a problem, there is nothing we could do about this. I'm sorry.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:32

    If windows multi monitor taskbars are enabled, all works fine. But with a simple search I couldn't find where this is checked in OpenShell.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:32

    So I've searched back and forth and can't find a single point where this is checked, but maybe I've missed it. Would it be possible to hardcode or emulate that windows built-in multi monitor taskbars is set to enabled? It would solve both problems.

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:32

    I will try to get second monitor so I can eventually have a look at this. Until that I'm afraid I cannot help much :(

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:32

    Thank you. Btw I think you can simulate it with DF split screen feature, should behave the same. Also I still think there's some VB option I'm missing that causes the compiled version behave differently, do you have any other idea what I can check? I was trying to create an installer as well but couldn't find any usable tutorial on how to do it :\

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:32

    I'm sorry, but I have no clue why it should behave differently. If you compiled from the same code, it should behave the same way (uses the same settings, appdata).

    Possibly check what VS version you have, Nightly builds on AppVeyor were done with 16.7 (iirc). Latest version is 16.8 which should work well (at least I haven't noticed any discrepancies).

    Well, there may still be some bug that makes code behave different, but without replicating and debugging it won't be possible to do anything with it.

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:32

    So I managed to make an installer and that just inherits the same behavior as the compiled one, still different from the release version. My VS is 16.8.2 so it should be fine. I give up on this.

    On the other hand, I had some success with reproducing: the one when start menu moves to primary monitor for winkey can be seen using DF splits. No luck with the disappearing menu yet because I can't get a fullscreen window to not occupy the whole display only a split. Will continue trying with some other virtual desktop SWs.

    点赞 评论 复制链接分享
  • weixin_39693971 weixin_39693971 2021-01-07 01:32

    I've got the same issue as the OP: OpenShell: 4.4.160 DisplayFusion: 9.7.1 beta-6 Win10: build 1909

    点赞 评论 复制链接分享
  • weixin_39558521 weixin_39558521 2021-01-07 01:32

    I'm in a similar boat. Same version of Open Shell, 4.4.160 DisplayFusion v 9.7 Windows 10 2004

    I've got the same issue as the OP: OpenShell: 4.4.160 DisplayFusion: 9.7.1 beta-6 Win10: build 1909

    点赞 评论 复制链接分享
  • weixin_39793434 weixin_39793434 2021-01-07 01:32

    Seems they fixed this in DF latest beta (or one of the recent ones). There's still the issue of the start menu always opening on primary monitor when invoking with winkey, should I open a new thread for that problem?

    点赞 评论 复制链接分享
  • weixin_39986169 weixin_39986169 2021-01-07 01:32

    Seems they fixed this in DF latest beta (or one of the recent ones).

    Cool 👍

    There's still the issue of the start menu always opening on primary monitor when invoking with winkey, should I open a new thread for that problem?

    Please, always create new thread for separate issues. It is much easier to track them that way. Thank you.

    点赞 评论 复制链接分享
  • weixin_39693971 weixin_39693971 2021-01-07 01:32

    Seems they fixed this in DF latest beta (or one of the recent ones).

    Agreed - seems to be working now for me as well.

    点赞 评论 复制链接分享

相关推荐