[BUG] Task View causes Explorer restart when SystemTrayMenu is open

[chip33]

Description, Steps to reproduce, Expected behavior, Screenshots
Hi, maybe you can reproduce this.

Just have SystemTrayMenu open and in use for a while on the taskbar and just maximise it and minimize now and then like you would , When you click Task View often but not always there is a freeze and explorer restarts, once it starts happening trying to open Task View will just keep restarting Explorer.

It seems to be caused by SystemTrayMenu as closing STM immediately fixes the issue and Task View works again.

It may have something to do with the way the STM taskbar thumbnail is drawn as when it is working Task View looks like this., rather than showing a preview of SystemTayMenu.

I could also make a Feature Request for SystemTaskMenu to display a thumbnail preview correctly in Task View as this may be the cause of this issue.

• OS: Win 11 22000.469

[Hofknecht]

@chip33
Thank you for reporting that issue!

I can't reproduce it on windows 10 right now.

it obviously has to do with the form in the taskbar, as a workaround you can switch it off here:

(Maybe you can confirm to us here that if the taskbar form is off, whether it really no longer occurs)

With windows 11 you have a revised version of windows explorer or even a newly created one, I don't know exactly
https://www.windowscentral.com/whats-new-file-explorer-windows-11

What would be very interesting if it also happens when the STM taskbar form is not active. E.g. another program in the foreground and activated.
and also whether it occurs when windows explorer is not started at all.

With this taskbar form, we only listen to the events that the form was activated and then do the same as if the hotkey was pressed, so basically we then show the menu. Therefore, you could check whether something like this also occurs if you e.g. presses the hotkey and task view repeatedly very quickly.

Showing the menu has no special implementation except that we use SetForegroundWindow from user32.dll.

It's probably not the thumbnail, which we only read once when at start.

We intentionally do not show the preview because if you turn off the taskbar form, then you want to select nothing with alt+tab and so that we could do that we had to switch off the preview. But we could take a closer look to see if showing preview is possible in an other way. But that shouldn't be the root cause here.

Definitely very interesting. If others can reproduce it please post it here, even if you can't reproduce it to classify how critical that is.

The most important info is that the task view works again when the STM is restarted at the point.
I just can't imagine how the STM can block something from windows.
We'll leave that open and look at it again later.

[chip33]

Hi, thanks for looking at this.
As you could not reproduce this and other people have not reported this as well it seems it is a windows 11 thing or maybe an issue with my setup.

The only major modification I have made to Win 11 is Explorer Patcher to bring back the Windows 10 taskbar functionality.
At first I though it could be due to Explorer Patcher but I do not think EP really changes Task View.
To check I uninstalled Explorer Patcher and could still easily reproduce the explorer restart by rapidly clicking the SMT icon in the taskbar (say 10 times) and then trying to open Task View.
It is always fixed by restarting STM.

Even when Task View is broken Alt+Tab works fine.

Maybe you can confirm to us here that if the taskbar form is off, whether it really no longer occurs

If I run STM without the taskbar form and rapidly tap the STM icon in the system tray I cannot reproduce the error at all.
Also I cannot reproduce it by rapidly using Ctrl+LWin hotkey.

What would be very interesting if it also happens when the STM taskbar form is not active. E.g. another program in the foreground and activated.

Yes, it does happen when the STM taskbar form is not active.
That is how I discovered it. Often when I tried to open Task View while any other program was active it would be frozen for a fraction of a second and then restart explorer each time it is selected.
Then after a while i realised that restarting STM in the taskbar always fixes the issue.

and also whether it occurs when windows explorer is not started at all.

If i run "taskkill /F /IM explorer.exe" Ctrl+LWin opens STM and Task View is fine after an explorer restart but I couldn't find another way to test this.

It would be nice if at some point if STM is in the taskbar Task View could show a preview of STM or even better just nothing at all as it does when in the system tray.

I have happily gone back to having STM only in the system tray and it all works great.

[Hofknecht]

tried with win 11 but can only reproduce that windows explorer crashes but it is restarting itself (you know the behavior when taskbar short time invisble), without any restart of STM. But maybe probably a rare side effect of using the taskbarform, because when disable it i could not reproduce any windows explorer crash.

So let's set 'Show in Taskbar' as default false in #304

But we're leaving the option there because there are users who don't have this problem and we marking this as an FAQ, then it should be fine

[chip33]

Hi, after explorer restarts itself I find that the Task View button still does not work until STM is restarted.
I am glad you are leaving the option there but not as default as it is a good feature (apart from the win 11 bug) and faster than the shortcut in taskbar method.

[Hofknecht]

we made now this option -h as default in #305
yes i agree taskbarform is faster than shortcutoption which is now default without arg (own autohotkey script Send, {CTRLDOWN}{LWin down}{LWin up}{CTRLUP} might be slightly faster)
but hotkey is fastest : )
maybe we find better ways in the future

but if you use the taskbar view, let's say it's normal, so click once, then everything works, right?

[chip33]

but if you use the taskbar view, let's say it's normal, so click once, then everything works, right?

When STM is in the taskbar form and has not been clicked on much , clicking on Task View in taskbar will sometimes make Task View work but often it just stops working and restarts explorer.

Even if Task View is broken , clicking STM in the taskbar always works great, Windows seems fine, only Task View is broken.

[Hofknecht]

I tried it again several times on a windows 11, I can't reproduce it. Windows explorer didn't crash again. On that very weak test hardware everything runs correctly. If you want to you can debug deeper in the code and see if the situation doesn't occur when you change certain things,

Maybe you have the possibility to try the whole thing on a fresh installation of win 11 and see if it also occurs there
or a virtual machine

[chip33]

Hi, yes I will try it on a clean win 11.

[Hofknecht]

I summarize here again:
There is obviously a rare error (it does not occur on all systems) in connection with the windows 11 new windows explorer triggered when using STM with 'Show in Taskbar' true (now default false) and windows feature 'Task View' clicking more often (I just think it would be a good idea we could document the behavior with a video) where windows explorer freezes and which is resolved by restarting the STM. (we haven't been able to reproduce that yet)

This is how our taskbar form works:

if someone has the error and could try a little bit here to improve the behavior of the taskbar form, then let us know.
It is very probably that it is due to the native user32 call, but this is how the behavior is generated, so we don't know a solution now.

We look forward to hearing whether a fresh installation of Windows 11 might also solve the problem for you

[chip33]

Yes, could you reproduce it in some way? I will try it on a new windows 11 as soon as I can.
If it works on a clean windows I will try to find out what causes it on my machine.
I did get a windbg log output for the explorer crash, would that be helpful to you?

[Hofknecht]

No, unfortunately I couldn't reproduce it at all, just that the windows explorer crashed once and restarted, but regardless of the STM, it only happened once when I switched very quickly and very often between task view and windows explorer.

currently i don't know what we could change, we need more data or a reproducible case, for example in a virtual machine which we can copy or similar.

Thank you for sticking with this for so long, it helps us a lot to improve the STM

[chip33]

Yes, It may be due to me using ExplorerPatcher as that is quite a big patch on windows 11 , maybe even when I uninstalled EP there was something left.
I also could not reproduce it on a clean windows 11 on VM.
I have set up a new windows 11 on ssd and will try it soon.
Hopefully it is my system not STM.

[chip33]

Here is the windbg output from an explorer crash when clicking STM in taskbar about 5 times and then clicking Task View. This is with ExplorerPatcher uninstalled but not on a clean Windows 11.
Windbg.txt
ExceptionCode: c0000409

[chip33]

Here is a video.

screengrab.mp4

Thanks

[chip33]

I can also reproduce this on a clean install on ssd of windows 11.
Here is my STM user.config in case that will help reproduce this.
user.zip

[Hofknecht]

I made a bit code beauty to reduce the related code, it can only be related to the selected code in the screenshot

@chip33
Thank you for the video and the user.config. That's very good, so we can imagine it better.

In the video I see ShowInTaskbar is true, in the user.config it is set to false.
Does it work with 'Show in Taskbar' false (default false)?

If we are sure that it is only related to the taskbar form, then it would be good to distinguish where exactly it comes from in the lines. We need to check some szenarios:
Can you comment out the lines with Deactivate (line 36) and Resize (line 37). Does it still occur?
then comment out SetStateNormal Activate and Focus (lines 41, 42, 43). . Does it still occur?
Last test (reset all previous changes), only comment out SwitchOpenClose (line 44). Does it still occur?
Maybe you find also better combination

(I also noticed that it doesn't work like it did in windows 10, so the show taskbar form doesn't respond anymore if it's already activated.)
Maybe you find a better behavior for the taskbarform which works correctly and does not cause that side effect #299

(on the one windows 11 system we have we can't reproduce it, otherwise we would try it there a bit)

Would be cool if you like to continue trying to fix it on that lines

[chip33]

In the video I see ShowInTaskbar is true, in the user.config it is set to false.
Does it work with 'Show in Taskbar' false (default false)?

It works fine until ShowInTaskbar is true, user.config shows false because I have to disable it in everyday usage to make Task View work.

Using your latest commit ,commenting out any of the lines you referenced in App.cs did not stop the crash.
Disabling line 48 with all the other lines uncommented does stop the crash.

// DllImports.NativeMethods.User32ShowInactiveTopmost(taskbarForm);

If you have any ideas for other lines to change please let me know.
There was a stack-based buffer overrun error in the Windbg.txt I posted above.

[Hofknecht]

Maybe replace
DllImports.NativeMethods.User32ShowInactiveTopmost(taskbarForm);
with
taskbarForm.Show();

then we would just have

taskbarForm = new TaskbarForm();
taskbarForm.Show();

the class taskbarform has almost no logic

but maybe comment out 15-18 and 23

[chip33]

Good morning :)
It seems we have found it.

The only line that needs commenting out is line 17 in TaskbarForm.cs
// Opacity = 0.01f;

App.cs is unchanged from commit.

This also has the very good effect of making the STM window in Task View a reasonable size instead of the huge one shown before.
Will test it out in general use but it does seem to have stopped the Task View freeze and explorer crash.

Before:

After:

[Hofknecht]

@chip33
That's fantastic.
Many thanks for your intensive commitment

I agree with you, we should then remove the line with opacity and the side effect is also great.

Do you like to commit it yourself since it is also your merit, you will be displayed on the main page as a contributor.

If it behaved the same when we replace this:
DllImports.NativeMethods.User32ShowInactiveTopmost(taskbarForm);
with
taskbarForm.Show();
then would be great if you can also commit that.

[Hofknecht]

@chip33
Should I make 'Show in Taskbar' default true again (revert #304)?

[chip33]

If it behaved the same when we replace this:
DllImports.NativeMethods.User32ShowInactiveTopmost(taskbarForm);
with
taskbarForm.Show();
then would be great if you can also commit that.

It is working with DllImports.NativeMethods.User32ShowInactiveTopmost(taskbarForm); unchanged but replacing DllImports.NativeMethods.User32ShowInactiveTopmost(taskbarForm);
with
taskbarForm.Show();

Creates a BugSplat when run.

Shall I commit it with only // Opacity = 0.01f; ?

[Hofknecht]

@chip33
perfect!

ok very good, then you found the reason why we use the native function there.
Yes, then just commit the remove of complete line with set opacity

That's brilliant that you found that out

[chip33]

Now that the over large STM window in Task View is gone Show in Taskbar is a good default rather than the shortcut method.
This is much quicker and does not have the two click focus issue when active that the shortcut has.

[Hofknecht]

@chip33
next step is to do commit a PR and then we can do a merge to master. Here is the way described how to commit the PR
https://docs.github.com/en/get-started/quickstart/hello-world#opening-a-pull-request

[Hofknecht]

@chip33
Thank you for all your help! Great job!!!

now we see your account in contributors

i think we can finally close this issue.

I hope you find more!

[chip33]

Thanks, I appreciate your help in tracking down the issue.

[chip33]

Noticed this fix in Windows 11 Insider Preview Build 22598 which may be related to why this error was occurring.

Search for "Fixed an explorer.exe crash when invoking Task View."

https://blogs.windows.com/windows-insider/2022/04/13/announcing-windows-11-insider-preview-build-22598/

[Hofknecht]

@chip33 thanks for the hint!
great to hear you're still with us, we still have the filewatcher #330 on the list to do that next, no time found yet ; )