Taskbar loses topmost when clicking at the same time the taskbar finishes hiding #3
Comments
|
Thanks for the WindowInvestigator output. I can indeed see that your taskbar has lost topmost. You don't seem to have any transparent or full screen windows though, so this might be a new failure mode. I have a few questions:
|
|
I can't parse this sentence. When you make Discord what?
How often does it happen? Every few minutes? Hours? Days? The reason I'm asking because if it triggers frequently enough we might be able to set up a trace recording which would provide much more information.
So basically you're activating the taskbar. After you've done that, the problem goes away for some time, yes?
How are the monitors arranged? Side-by-side, top-bottom? Where is the main monitor located? Best would be to send a screenshot of your Windows display control panel. I need a precise understanding of your monitor layout because I need to understand how window coordinates relate to your monitors. |
|
Sorry for my sentences I am not native English. I'm from Germany.
|
|
Okay. The reason why I was so confused by the window coordinates is because WindowMonitor is reporting the "virtual" coordinates with scaling applied - so in this case the primary monitor's 3840x2160 dimensions are reported as 2560x1440. What makes this even more confusing is that the secondary monitor coordinates are not translated in kind - the X coordinates still start at 3840 (and end at 5520, as expected since the secondary monitor is not scaled). I will update WindowMonitor to report physical coordinates instead and thus avoid future confusion. So in the end we have:
The taskbar lost topmost on the primary monitor, which suggests the Rude Window Manager has marked the primary monitor rude. From the information we have, it's not clear to me why that happened. One thing that caught my eye is the dimensions of the maximized Discord window. When I reproduce your setup (3840x2160 monitor with 150% scaling, maximized Discord), WindowMonitor reports a window rect of (-5, -5, 2566, 1446) and a client rect of (0, 0, 2560, 1438). However in your case the window rect is (-7, -7, 2568, 1448). This suggests the window borders are thicker. I dug deeper and managed to reproduce these thick borders by setting a high-contrast theme. You wouldn't happen to have a high-contrast theme enabled by any chance? (As a side note it would probably be useful for WindowMonitor to report the client area coordinates in screen coordinates, since that's how the Rude Window Manager uses client coordinates.) In any case, I still have no clue what's triggering your problem. I will need to set up a procedure for continuous tracing and then walk you through it. Stay tuned. |
|
|
Ok, here we go. I have published new releases of RudeWindowFixer and WindowInvestigator to help with this kind of in-depth troubleshooting. Please download the latest versions and then follow the instructions here to gather a trace. The idea is that you keep the trace running until you notice the problem - even if it takes hours, that should be fine. Share your trace with etienne@edechamps.fr (do not post it on GitHub!). Hopefully the trace should contain enough information to fully root cause the problem. |
|
Ok. I will try it in the next days. When I have the problem next time i will send it to this email and write here an comment that I sent it. |
|
Thanks. Oh, and by the way, I guess it could also be helpful to record you "stopping" the problem in the trace as well. That is, after you add the marker in step 14, I would suggest making the problem stop the way you usually do it (i.e. activating the taskbar), and then once you've done that, add another marker (Ctrl+Alt+Win+X), and then continue with step 15. |
|
|
|
Oh, sorry, I thought In the mean time you can either obtain the UI by installing the ADK, or you can use the command line version as you suggest (which indeed appears to bundled with Windows). I gave it a quick try and it looks like the following command is equivalent, assuming the various Looks like the command line version doesn't support Ctrl+Alt+Win+X; you'll need to use To save the trace, run Note all these commands must be run as Administrator. |
|
I already installed the adk short time after writing the comment but it is useful to add it to the readme file for tracing |
|
I could reproduce it short after starting the tool. What I saw: When the problem occurs there is one pixel-row at the bottom of the screen, which is fully white. I will send it in the next hour. |
|
I took a look at your trace. What I found was quite unexpected and doesn't match any behaviour I've seen before. Basically the timeline goes like this:
So basically it looks like things were already going downhill around T=86s, 34 seconds before you started placing the marker. There's a lot going on here and I'm not sure where to start. It's very different from anything I've seen before so I can't promise I'll be able to figure it out, but I'll give it a try. I might need to make a few adjustments to WindowMonitor because it didn't log changes to taskbar window properties while it was hidden, which is expected but might have robbed us of potentially useful information here. |
|
Windows 11 looks very strange to me. If i had the possibility I returned to Windows 10 but Microsoft updated automatically without Windows.Old ... It is full of very strange behaviour... |
|
Should I do something at the moment or just wait for your next work... |
|
Okay I managed to figure out what this "taskbar disappear act" is about. Basically, when the Start Menu is opened, or when using Win+Tab (but not Alt+Tab), the taskbar window ( The problem is, the taskbar window lost topmost while it was hidden from WindowMonitor, which means the data about this event is not in the trace, so we're stuck :( I'll see if I can improve WindowMonitor to not lose track of such Windows. In the mean time, here's how you can work around the problem and generate a new trace with the data we need:
This approach will also provide much more detailed timing of events that affect the taskbar window, which should make it easier for me to correlate to other system activity. Note that this will only gather data for the taskbar on the primary monitor, so there's no point in sending a trace if the problem occurred on the secondary monitor. |
|
I just released WindowInvestigator 0.4 which includes fixes for the shortcomings we encountered. Feel free to use for your next trace, though I'd still recommend you run a separate WindowMonitor instance for the taskbar window as described above because the more precise timing measurements might come in handy. |
|
I sent you a next trace with the solution of the previous comment (1 hour ago) some minutes ago. |
|
If you need a trace with WindowInvestigator 0.4 please write. |
- Use wpr.exe (which is bundled with Windows) instead of wprui.exe (which is not) - Recommend the use of a dedicated WindowMonitor instance for the taskbar See #3
- Use wpr.exe (which is bundled with Windows) instead of wprui.exe (which is not) - Recommend the use of a dedicated WindowMonitor instance for the taskbar See #3
|
I looked at your latest trace and unfortunately it's not really usable - there are too many dropped events. It looks like WPR can't keep up with the sheer rate of events happening on your system. The beginning of the trace is cut off so much that by the time I can see anything the taskbar had already lost topmost. I never had that problem before. I don't know what's causing events to get dropped. My best guess is that there's simply too much going on. My advice would be to try to reproduce with a more "idle" system. For example, if you were using voice in Discord, try to reproduce without it. If you can reproduce without Minecraft running that'd be great as well. Alternatively we could adjust the trace procedure to log fewer events, but I'm worried the lack of data could make it impossible to root cause the issue. |
The open Minecraft-Window was only the Launcher. Discord was open but without being in a voice channel or any active text channel. What is running in the background is my virus scanner "Bitdefender" and "PowerToys" by Microsoft other things are not running in the idle state spart from the system. I can try it tomorrow to reproduce it with 0.4 and without PowerToys |
|
Mmm, that's strange. The other possibility is that the second WindowMonitor instance (the one for the taskbar window) is polling at such a rapid rate that it's overflowing the trace. Seems unlikely, but you never know… My suggestion then would be to not run the second WindowMonitor instance next time - just stick to the original procedure with a single WindowMonitor running. Make sure to use WindowInvestigator 0.4. The timing won't be as precise but it might still be enough. |
|
I could reproduce it again with no PowerToys / Jetbrains Toolbox / Anti Virus running. Is it ok, when I delete the old traces from workupload? My storage goes to the end (full)... |
|
No worries, I have them locally. |
|
One question i have because I am interested in it: With which tools do you analyze these reports and the files in the folders. For the main file I found an tool in this ADK but for the others not. |
|
The NGENPDB files are just auxiliary information that relate to the trace. I didn't look at this closely, but my understanding is that the Windows Performance Analyzer automatically finds them based on the file name and uses them to help decode certain kinds of stacks that involve .NET code. To be honest I'm only asking for them to make sure I have the full dataset; I strongly suspect the NGENPDB files are not actually that useful for the kind of investigation I'm conducting. They could probably be left out entirely. |
|
Yes that was the file, which I opened with the Performance Analyzer. There you can view Cpu Usage and other Hardware related values. You are working with the pdb (or similar, I don't know the ending) files, which are located in the subfolders, or? How do you analyze them? (I am asking because I want to make an apprenticeship as software developer and System Integration soon) |
|
PDB files cannot be opened directly, they have to be used in conjunction with a debugger (or similar, such as WPA). In the specific case of NGENPDB files generated by WPR, my understanding is that WPA loads them automatically when you open the trace file and uses them to find symbols for certain stacks involving .NET code. |
|
Thanks for the new trace. I can now see the taskbar lose topmost at T=111.28, at the same time it switches from band 6 to band 1. At first glance things look quite similar to the first trace, but this time WindowMonitor can track the taskbar window as it changes band, as expected. I'll need to take a deep dive into the trace but I'll be quite busy for the next few days so this might take some time. Especially since at first glance this looks like unknown territory compared to the stuff I saw while designing RudeWindowFixer. |
|
Thanks for your answer and the time. No stress I have time. I am very busy in school at the moment too. Hopefully it is fixable... |
- Use wpr.exe (which is bundled with Windows) instead of wprui.exe (which is not) - Recommend the use of a dedicated WindowMonitor instance for the taskbar See #3
|
I took a closer look. I don't think I'm anywhere close to finding the cause yet - this seems very different from the original failure mode RudeWindowFixer was meant to fix, and I'm not even sure it's related to the Rude Window Manager at all, given that the rudeness state seems constant throughout. I managed to get a stack for the code path that's causing the taskbar to switch from band 6 to band 1 (which happens at the same time it loses Another bunch of stacks that look interesting include: Still have no idea what's going on here since none of my original reverse engineering efforts covered any of these paths, but it's a start. I get the impression the whole thing got triggered by a mouse move event, possibly moving the mouse away from the taskbar. I wasn't able to find a clear stack for the code path that actually drops One thing that complicates the reading of your traces is that there are lots of stacks that include I took a quick look at the disassembly for some of the relevant code paths and I noticed some logging calls to a provider I haven't seen before: Microsoft-Windows-Shell-Core. I added it to the WindowInvestigator toolbox and to the RudeWindowFixer tracing instructions as these logs could be useful. Incidentally, I recently noticed a somewhat similar issue happening on my own system. Like you I am unable to reproduce but I did manage to capture it in a trace and it looks somewhat similar to yours. This is good news because obviously it's much easier for me to experiment on my own system than to ask you to experiment with yours! I'll see if I can spend some time over the next few days to dig deeper into this. If you want to help it might be useful if you could provide another trace with BitDefender disabled and the ShellCore profile added to WPR. However if we are indeed observing the same issue then hopefully I will be able to manage with my own tracing. |
|
Thx for update to the issue and your time. The mouse could be a point. When I resize a window and then snap it to the border that it goes big the taskbar sometimes goes wrong. I couldn't find a real system behind it, when it every time happens because I am resizing the window very much in different directions... But it is a good first step to fix it or/and report it to Microsoft because you could reproduce it ones. BitDefender is not the cause as far as I THINK because on an other pc of me with the same screens and system version and BitDefender I couldn't see this issues. Eventually it is the situation which Microsoft fixed in Dev Channel, which does not fix the normal issue for which your tool is thought. I don't want to switch to Dev Channel to then have to load a big backup. Windows 11 on my side is very, very strange. System files are not 'destroyed'. I try sfc /scannow and dism ones a week without errors. |
|
Additional Info: I have the option enabled that the taskbar automatically goes down to hide it. When it is down and the mysterious thing happens when snapping/resizing (I think) the taskbar goes not up anymore because the window is in the front. The very strange thing is the one white pixel row at the bottom of the screen when it happens. Sorry when I repeat sometimes. |
Sorry, I didn't mean to imply it was. I'm just saying BitDefender makes it harder to analyze the traces because it tends to injects itself into various stacks, making things harder to read. However I'm not using BitDefender so I won't have that problem with my own traces.
Wait, do you know this is precisely the bug they fixed in Dev Channel build 22567? Have you verified this? I certainly don't want to spend a ton of time investigating this if Microsoft is already in the process of releasing a fix… (I would certainly like to check for this bug in dev build 22567, but like you I don't want to move my main machine to the dev channel. My plan is to try to come up with reliable steps to reproduce based on traces, and then try these steps in a VM running build 22567 and see what happens.) |
I couldn't tried it because I read the changelog some minutes ago and I am already laying in bed. The thing with bitdefender I misunderstood. If my English as student in Germany would be better... |
|
Sorry... |
|
I found reliable steps to reproduce! 🎉🎉🎉
Here's a video (Streamable) of when I first captured this failure mode. The trigger is at 00:06.028 where I click the "File" menu at the exact same time the taskbar finishes hiding. Later at 00:16 I discover that the taskbar is gone. Here's how I managed to figure this out: I correlated the video with a trace. The taskbar goes to band 6 → 1 at the exact moment the taskbar finishes its hiding animation. (Presumably the taskbar was in band 6 because the start menu was open. It's difficult to tell though, because my trace also had issues with missing data. Anyway, this doesn't seem to matter for now.) From that trace I found the stack that actually caused topmost to be dropped: (Side note: according to reverse engineering, the window message that causes I worked backwards to figure out which thread sent the message that triggered the above stack. Here's the message sender stack:
Now, the next step is to reproduce this in a VM and see if Insider Dev build 22567 fixes it. Progress! |
dechamps
changed the title
|
Experimenting with a VM revealed interesting findings: At first I was confused as to why I couldn't reproduce this in my normal (non-insider) Windows 11 VM. Turns out that's because it was out of date, which led me directly to the conclusion that this bug is a regression that was introduced in build 22000.556 (KB5010414) and is not present in build 22000.493. That also explains why I only noticed it fairly recently (the update is from ~1 month ago). The bug is fully reproducible in a fresh 22000.556 Windows 11 VM with nothing installed. No sneaky full screen windows this time - it's truly Microsoft's mess. Now the good news is, I tried it on Insider Dev Channel build 22579.1 and couldn't reproduce it there. So it looks like Microsoft is aware of the issue and in fact that's probably the one they're referring to in that Feedback Hub entry where they said they fixed it. Since this is clearly something Microsoft is aware of and in the process of fixing, I don't think it's worth it to investigate this any further. I will, however, document this in the README so that people are aware. |
|
Thanks @dechamps for the big effort and the time... I am happy that MS fixed it in insider with an build which is hopefully released soon in non insider systems. It is very annoying when developing bigger Websites/Projectes with Python, Java/ or JS/CSS/HTML and every 5 minutes the taskbar is gone behind windows and so I can't switch to the Browser to preview the Website or start the project in cmd in this very bugged system Win 11 (I have also other bugs like the taskbar goes out of auto hide mode after waking up from standby or the clock ... goes away on both monitors, until next toggling auto hide off and on, at a "random" time while working in the startmenu and much more when two screns are connected.) |
|
FYI, it would appear Microsoft finally fixed this particular issue in the latest Windows 11 update (22H2 22621.1105). The usual reproducer doesn't trigger it anymore, it seems. |
Thanks for an answer! |
Or is this the case for what RudeWindowsFixer was original developed (I saw that it isn't in my autostart anymore.)? |
Wow you're right, I can trivially reproduce that one… it really feels like Microsoft is playing a game of whack-a-mole with us, and we're losing 😭
No, I can reproduce the fullscreen notepad issue even with RudeWindowFixer in place. It looks like it's another issue entirely. Sigh… filed #10 to track. |
The text was updated successfully, but these errors were encountered: