W11DADTTF shows up in taskbar after hibernation

[cakeforcat]

Pretty insignificant, but after waking up from hibernation an alerting icon shows up in the taskbar, but this is easily fixed by restarting the program.

[HerMajestyDrMona]

What alerting icon do you mean? Which version do you use?

Maybe this: https://github.com/HerMajestyDrMona/Windows11DragAndDropToTaskbarFix/blob/main/CONFIGURATION.md#should-the-program-use-a-fix-for-an-issue-where-sometimes-incorrect-icons-are-hovered-on-the-taskbar-this-bug-usually-occurs-after-the-computer-wakes-up-from-sleep-mode-connecting-or-disconnecting-secondary-screens-or-plugging-out-the-laptop-charger-the-fix-opens-the-self-created-window-for-around-100-milliseconds-forcing-the-taskbar-window-to-update-and-return-the-correct-rect

?

But it should disappear after 100 milliseconds.

[cakeforcat]

it doesn't happen 100% of the time so I can't reproduce it right now, but it looks as if a new window opened, but you can't open it so it's just shown on the taskbar next to other open programs and it flashes red as if it had o new notification or needed action.

[HerMajestyDrMona]

Which version are you using? I remember fixing some issues with it in the newest version.

Does this window auto close after some time?

[cakeforcat]

I'm on the latest version 2.1.0.0, I didn't wait to see if it disappears, but it stays for at least 2-4 minutes. I'll definitely give you some more precise details once I manage to reproduce it.

[HerMajestyDrMona]

Oh, 2+ minutes is too long. 1-5 seconds would be fine.

Generally what you're experiencing is change in ver. 1.7.0.0:

• Added additional checks if the Windows 11 taskbar bug occurred, as discussed in issue #10. The bug causes window MSTaskSwWClass to return an incorrect RECT. Windows11DragAndDropToTaskbarFix now opens a small self-created window, for ~100 milliseconds in order to force the taskbar update. Please note that this is a Windows 11 bug, not caused by this program.

The code is here:

Windows11DragAndDropToTaskbarFix/Windows11DragAndDropToTaskbarFix/Windows11DragAndDropToTaskbarFix.cpp

Lines 1684 to 1723 in 562be30

	bool Fix_Taskbar_Size_Bug(HWND Moomintrollen) {
	RECT SleepModeFix_rect;
	GetWindowRect(Moomintrollen, &SleepModeFix_rect);
	int SleepModeFixTaskbarHeight = SleepModeFix_rect.bottom - SleepModeFix_rect.top;
	if (SleepModeFixTaskbarHeight < 44) { //48 is normal height, 40 when bug occurs, so lets make it 44.
	//Bug occurred
	TaskbarSizeBugDetectedTimes++;
	if (TimeNow.count() > LastTimeFixedTaskbarSizeBug.count() + 5000) {//We can have 5 secs here because it counts real time, not GetTickCount() which would not differ much after the sleep mode.
	if (Hwnd) {
	if (PrintDebugInfo) {
	std::wcout << L"MSTaskSwWClass size bug detected. The current height is: " << SleepModeFixTaskbarHeight << L" (and should be 48). Opening an empty Windows11DragAndDropToTaskbarFix window to fix it...\n";
	}
	if (ShowConsoleWindowOnStartup) {
	ShowWindow(GetConsoleWindow(), SW_HIDE);
	}
	ShowWindow(Hwnd, SW_HIDE);
	Sleep(5);
	ShowWindow(Hwnd, SW_SHOW);
	Sleep(100);
	ShowWindow(Hwnd, SW_HIDE);
	if (ShowConsoleWindowOnStartup) {
	ShowWindow(GetConsoleWindow(), SW_SHOW);
	}
	LastTimeFixedTaskbarSizeBug = TimeNow;//was missing before ver 1.10
	}
	else {
	if (PrintDebugInfo) {
	std::wcout << L"MSTaskSwWClass size bug detected. The current height is: " << SleepModeFixTaskbarHeight << L" (and should be 48). Starting a new CMD window to fix it...\n";
	}
	wstring EmptyWindowCommand = L"start cmd.exe /C \"echo Windows11DragAndDropToTaskbarFix.exe & echo https://github.com/HerMajestyDrMona/Windows11DragAndDropToTaskbarFix & echo A bug after the Sleep Mode has been detected. The MSTaskSwWClass window size returns incorrect RECT, therefore a new CMD window was open in order to force the taskbar window update. & echo Please read the GitHub page for more details. & timeout 1 & exit\"";
	_wsystem(EmptyWindowCommand.c_str());
	LastTimeFixedTaskbarSizeBug = TimeNow;
	}
	return true;
	}
	}
	return false;
	}

So it should not open for longer than 100 milliseconds, and there is a security that prevents opening this window more than 1 time per 5 seconds.

I wonder if the drag-and-drop actually works when this window is flashing / visible on the taskbar? Could you please next time try to drag and drop something and see if the program continues to work normally?

[cakeforcat]

Finally managed to catch it, the program works fine, here are some screenshots

[HerMajestyDrMona]

Hmm... Thanks for posting it.

For me it seems like another Windows 11 bug. The window is supposed to disappear after 100 milliseconds. Maybe in the next version I'll change it from 100 ms to 500 ms, so it will have more time to show up before being hidden again... Hard to say.

Could you please for now insert this to your config file:
UseFixForBugAfterSleepMode=0

Then test if this window ever shows again. You might experience problems after the sleep mode when this fix is not activating, but that's just for testing purposes, to make sure this is the window that I'm thinking about.

[HerMajestyDrMona]

@cakeforcat I added some longer timeout for that fix window in ver. 2.2.0.0.

Please update the program and observe for some days/weeks if it's any better. Thank you.

[cakeforcat]

I did not experience the original bug for a few days now so it might have fixed it, but the update introduced a new one. From time to time the window will show up for a split second on the taskbar, behaving like the fix should after waking from sleep, but instead doing it randomly.

[HerMajestyDrMona]

This is correct. The configuration variable name is a bit confusing, because that's the first thing that made me able to reproduce this bug. With time I noticed that it also occurs

after the computer wakes up from Sleep Mode, connecting or disconnecting secondary screens, or plugging out the laptop charger.

But in reality there are many strange / unknown triggers of it. So Windows 11 generally has a buggy taskbar. I believe you've noticed that sometimes the tooltips of WiFi / keyboard settings are displayed in wrong / random places after hovering the mouse over the taskbar. Sometimes I can see the "refreshing" effect of the taskbar icons (hard to describe now from memory) which I believe are triggering the positions bug.

So whenever the bug is detected (Windows11DragAndDropToTaskbarFix is checking if the taskbar window height is incorrect) then a program window is open for 0.5 second in order to force Windows to "refresh" the taskbar. I think it's the safest solution for it, better than sending some commands to the explorer.exe process in the background that could cause dozens of other problems or unexpected behaviours.

I believe this program window was appearing before too, but it was almost never noticeable, because 100 milliseconds was a really short time. When it's 500 milliseconds there is more time for the icon to show up and to generally notice it. In case you experience the same problem as before again, we will revert the 100 milliseconds time, as the recent fix might be simply pointless. Thinking about it now, I should have simply added a configuration variable for this time instead of changing it with the update...

[cakeforcat]

Yeah, the taskbar has been buggy since release, showing tooltips randomly, showing the wrong volume indicator, loading generally slower etc. Unfortunately, you were right and the bug does still happen, although I did catch the window close once on its own, no idea what caused it though. In any case implementing the time to close as a variable is probably a better idea, even if it doesn't help here. As a potential workaround, maybe add a configuration to have it restart after waking up from sleep/hibernation? (maybe even multiple times, if necessary)

[HerMajestyDrMona]

Strange that it never "froze" this window for me. I wonder if it could be related to your AV software. Are you using Windows Defender or something else?

Restarting the program would not solve the bug. If a process restarts it doesn't show any icon on the taskbar, so Windows doesn't reload the correct width/height of the taskbar. Alternatively, I could add a switch to the old method that creates an empty cmd.exe process that auto-closes after X milliseconds. The method of working is the same, just that the visible CMD window flashes. The good thing is that the process of cmd.exe gets killed, so it's less chance that it would be continuously visible.

[cakeforcat]

Just Windows Defender, nothing else. I'm open to beta testing if you want to send some experimental builds.

[HerMajestyDrMona]

Oh, that's cool. I'll send you something next days with more configuration variables, and we will see how it's going.

[HerMajestyDrMona]

@cakeforcat Could you please test the following file? https://we.tl/t-Pcw4tgZkcf

Please only extract the .exe file from the .zip archive, unless you want to compile it yourself.

Please add the following line or lines to your configuration file:

FixForBugAfterSleepModeUseOldMethod=1
FixForBugAfterSleepModeWindowDisplayTimeMilliseconds=100

This will disable W11DADTTF window and use the old CMD.exe method. There seem to be 1 second timeout which can't be reduced. Anyway, it's just to confirm that this strange window "freeze" won't occur when it's switched to the old method. So please leave it this way for a few days (after you insert these configuration options), and let's see what happens :)

[cakeforcat]

so far this is working as expected, with a terminal window popping every now and then, with the drawback being that it takes priority and minimizes any application that is in full screen (learned about it while playing a game). I will update you on how's it behaving in a few days.

[HerMajestyDrMona]

How often do you mean by "now and then"? I think you're getting this taskbar bug unexpectedly frequently. I normally see it like once per week. Did you maybe find out how to "trigger" it manually, or still it appears randomly?

Good catch with it minimizing windows. I think it should be moved below, to make sure that the taskbar window is currently visible. The only problem is that it might then interrupt correct detection of the taskbar window visibility... I'll test and let you know.

[cakeforcat]

I'd say at least every 1-2h, definitely a few times a day (my laptop is running usually ~7h per day). I always hibernate and restart 2-3 times a month. I think it happens randomly. I'll try to isolate it, but don't expect anything. I can provide you more details about my setup or maybe even run some debug version to try and find out why it happens so frequently? either way I think the non-cmd fix was better since it didn't interrupt my work and only required a restart of the program for the frozen window to disappear.

[HerMajestyDrMona]

I think with these mysterious Windows bugs, the debug log won't help much there, as it's more focused on what the program is currently doing.

One thing is sure: The program's fix should not interrupt users work at any stage, so the "fix" window should not appear if there's a fullscreen app running. I'll focus a bit on it now and send you a test version. Please then continue using the CMD.exe method to make sure it won't appear while you're in the full-screen program. It's important, because even if the program's window doesn't minimize other fullscreen programs for us - it might do it for others, so it's better to be 100% sure.

[HerMajestyDrMona]

Please try this version: https://we.tl/t-SjguklrnFl

I moved the "bug check" function to be executed when the window under mouse is the taskbar window (well, practically speaking: one of these windows, because the taskbar is built from many of them). This way, the fix won't execute from the full-screen programs, just as the other drag-and-drop behavuour.

I think it should also reduce the number of times you see this fix window, because the program won't attempt to fix it if you're currently not dragging any element. It might be a good solution, but might also be a bad one. Maybe this fix, executed whenever the taskbar size bug was detected helped us not to experience some other taskbar-related problems for the past few months? Who knows :)

[HerMajestyDrMona]

Hey @cakeforcat
Any update on the newest test version?

[cakeforcat]

It's hard to compare with the older version, but I think the window does pop up less frequently (that may also be due to a recent windows update that fixed some taskbar bugs) and I haven't experienced any minimization of full-screen apps, so that's a good thing.

[HerMajestyDrMona]

With the newest "test version" the fix window was supposed not to pop up at all, except when you're currently drag-and-dropping a file. So I suppose you didn't have a problem seeing this window anymore?

[cakeforcat]

now that you mention it, it does pop up only when dragging, a bit distracting, but works.

[HerMajestyDrMona]

It pops up one time, or multiple times? Does it pop-up each time you're dragging something?

[cakeforcat]

I'm not dragging things enough to trigger it frequently, but it definitely does not pop up each time, and at most once while dragging.

[HerMajestyDrMona]

Great. Thanks for the confirmation and all the time spent on this discussion. I guess this solution will be the best in next version.

[cakeforcat]

do you mean this exact solution with the cmd window or do you want to check for the bug while dragging but use the newer non-cmd window?

[HerMajestyDrMona]

No, no. The CMD window was only used in tests to make it easier to detect. You can try with the normal window, but I believe it won't change anything.

[cakeforcat]

I just noticed that while dragging a scrollbar the window popped up. My cursor was over the taskbar as well. Is this intended?

[HerMajestyDrMona]

I think yes, since it detected the click "before" the taskbar, and then mouse movement to the taskbar area. The program is generally predicting user's action based on the mouse clicks, so it thought that the item was being dragged, but it wouldn't continue further, because the "error icon" was not displayed on the taskbar. However, the "after sleep mode" fix was moved there, so it executed at that time.

It's still strange that you're getting this bug so often. As I mentioned earlier, for me it appears very rarely. I wonder if you're getting some devices disconnected / reconnected often? Like speakers going to the standby mode and then getting connected again? Either way, I don't think we should even waste time to analyze bugs in Windows 11. Let's just hope it won't take them too long to fix them :/

[HerMajestyDrMona]

Hi again.

The fixes we discussed & tested are now officially available in ver. ver. 2.3.0.0 :)