[BUG] DisplayPort Deep Sleep/Hot Plug Doesn't Restore Apps to Taskbar

[SSyl]

This issue is actually fixed in Windows 11 and was eventually fixed in a Windows 10 update, but ExplorerPatcher somewhat re-implements the bug in a different way.

You can read about the issue here: https://devblogs.microsoft.com/directx/avoid-unexpected-app-rearrangement/

The bug manifests itself in ExplorerPatcher a little differently. What happens is when you use a DisplayPort monitor in a multimonitor setup and the monitor goes to sleep, it'll wake up and the icons/tabs/programs won't display on the taskbar. That means the programs are just running in the background without you realizing it. You can press alt+tab and individually bring those programs back up and they'll then show themselves on the correct taskbar.

For reference, I'm using ExplorerPatcher 22000.348.39.1 with the Windows 10 taskbar option. I'm also using the option to only show apps on the taskbar where the window is open (which I'm assuming is part of the issue as well).

If you're using just the default Windows 11 taskbar, the apps restore themselves properly as expected.

If you're having trouble reproducing it or understanding, I could also make a screen recording to help.

[valinet]

Okay, so my 2 cents on this "problem". I have spent the past few hours looking into it.

First of all, ExplorerPatcher does not "re-implement" bugs. That's a stupid statement to make and I quite dislike it. With ExplorerPatcher, I try my best to make the experience better, not to implement problems.

With that aside, it's funny how this is totally a self-created problem of Microsoft, due to some stupid decisions that they took in the past and enforced on everybody. I will explain why I say this in a little while.

So yeah, this is a very very very specific quirk. This only happens in sleep, but not under traditional sleep (S3), but under the shitty new "modern" S0 low power idle sleep. It took me a while to realize that, as because of how shitty that is, I had that disabled in the registry, and because my laptop vendor has not bothered to ship a proper implementation of S3, I also have sleep disabled in the BIOS. Once I realized that and went back and reenabled S0 low-power idle just for the sake of testing, I was able to reproduce this. (Also, I should mention, my laptop's fan never stops spinning when "sleeping" in this mode, and sleeping fails 3/4 times with this, another testament of how stupid this functionality is; it's not just Dell, I have a Lenovo laptop as well which similarly behaves weird af with S0 low-power idle sleep; I hate this things so much that I have all my computers hibernate instead of sleep, as boots are nowadays instant anyway, plus hibernate is much better since it consumes no power).

So yeah, I reproduced it. The effect is that, as you said, on certain resumes from S0 low-power idle sleep, the windows are restored where they should have been, but the window buttons are not available in the taskbar anymore. Furthermore, another effect that you haven't noticed (probably becaue of your setup) is that the windows are sized wrongly if the monitors have different DPIs (for example, windows on my 150% DPI monitor were sized as if running on the laptop's 125% DPI monitor) - the title bar is also drawn wrong by dwm, corresponding to the DPI of the other screen. What I determined fixes this is moving the windows a bit. Once you do that, their taskbar buttons are restored and Windows takes care of properly sizing the window. Restarting explorer.exe probably fixes it as well, although I haven't got to actually trying that.

If you ask me, I think they never got to finishing work on this functionality ever, at least for the Windows 10 UI. I don't know. Maybe they just got to finishing the work in the Windows 11 UI mode, where they focused all their attention from some point on when they decided to move away from the legacy taskbar. All the legacy stuff is generally on life support, they never invest the time to fix them (for example, taskbar toolbars never update their size when the DPI changes, another stupid issue). I don't know if it's ever been backported to stable Windows 10's explorer either. It is here, albeit in this quirky state, where it does the job, but not fully. I don't understand why it has to behave so weirdly in the first place, as S3 resumes worked just fine since 1980 and still work today, but yeah, it is what it is.

What would be a solution to this? Idk, again, someone or me is expected to fix Microsoft's programs, because they can't do a proper job apparently. And this is not the single bug in Windows either; there are years old issues that Microsoft just ignores or provides half-baked fixes for them. Instead of fixing those, they bother offering a dumbed down "taskbar" and more ads in the OS.

So, we could hack away a solution on the lines of:

• After resuming from S0 low power idle, run some app/AHK script/whatever that moves every window (or, for testing, a window of a certain class, like "Notepad") by 1px in some direction and then back or just requests the window to repaint or something like that and see if this fixes it. It should, as that largely mimicks what you would do manually by moving the windows individually with the mouse.
• Then, if that works, find some way to get notified when "resuming" from S0 low power idle and triggering that automatically. That should be the fix. Idk how to be notified when resuming from S0 low power idle specifically, I am sure it will take at least half a day if not more to find out a way to do that, since everything ha to be especially convoluted in this OS, especially when it comes to newer functionality, because Microsoft.

So yeah, if I ever have some time and be in the mood, I will take a better look at this, maybe I manage something. For the moment, since I do not use S0 low power idle and do not have tablets or similar gadgets that would benefit from it, I don't experience this, so it does not bother me that much. It's pretty stupid this issue exists in the first place, but oh well...

And, again, it's not something done by ExplorerPatcher, and even if it were, it would not have been deliberate. A lot of people write all sorts of reports regarding EP, when in reality it's actually Windows' fault or behavior. Also, I am not Microsoft, I do not work for them and do not have access to their Windows source code, so every 'fix' and functionality takes ages to develop, test, implement and make sure works properly, because of the need to constantly disassemble and make sense of their undocumented binaries. I also don't know everything about Windows, so it's very hard to fix everything on demand. And as it seems, properly fixing some stuff is hard even for them as well. It feels to me at this point that this kind of project implies kind of working unofficially for Microsoft and fixing all their crap, with all the shitty parts that this implies, plus more, since I do not have the luxury they have, of actually looking on program source code, or discussing with whoever coded that or might have a better insight or some relevant information on why that happens at all... very frustrating.

[SSyl]

Sorry if I came off as arrogant or angry or demanding for reporting the bug. I didn't mean my message to sound that way if it did.

When I said ExplorerPatcher re-implemented the bug I didn't mean to imply that it was added on purpose. I just meant that it's a bug that popped up again after Microsoft fixed it in later Windows 10 builds (like it shows on the devblog) and one that isn't present when you use the default Windows 11 taskbar.

I wasn't sure if it was a difficult or easy fix, I just wanted to make you aware of an issue I came across. I know you're not the one that created the problem, it's an issue with Microsoft's ungraceful handling of DisplayPort standards.

I know you're not Microsoft and this isn't your full time job.

I apologize if I came across disrespectfully originally or in this message. I fully appreciate your work on this project and that you're doing it in your free time.

[valinet]

Thanks, as I said, I am not sure they properly fixed it in this code path ever. The linked blog post showed a Windows Insider version of Windows 10 as well. Plus, idk exactly on what code base Windows 11 is actually based on, I think there are some things in Windows 10 that maybe never made it to this code base, like News and Interests in the taskbar, for example… idk, really, I wish I had more insight.

[TheDarkerPhantom]

21287 is not WIndows 10. That is considered to be Windows 11. As the blog post indicates 21287 is required, which ultimately became Windows 11. This means this feature was never introduced in any Windows 10 build. Of course, the blog article is from before Windows 11 was announced, so the build they specified, already expired and cannon be used.

[valinet]

Such a big deal about this anyway. Expired... rollback the clock, install it, play with it, grab explorer.exe from there and compare it to the one in the current builds. That's the nature of Insider builds, that's why I hate them and never use them. And from what I see in the video in the devblog above, it seemed to still have this bug even there: if you look closely, only items on the taskbar of the Surface tablet's screen have underlines, despite windows being open on the external monitor as well. This looks an awful lot like how the bug described here, that's still happening in final Windows 11 with the Windows 10 taskbar. I don't think they ever finished the functionality for the Windows 10 interface anyway, and only got it done for the new taskbar. It certainly helps that they shoot that video with a potato, probably a phone made by that company they bought a few years ago and that they drove from being the largest manufacturer of phones in the world to being a total write off.