Freeze & crash Windows Terminal Preview 1.21.1272.0 with these few simple steps, you'll never guess what the 3rd one is! #21637

New Issue

@github-actions[bot] commented on GitHub (May 7, 2024):

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

[Preview] Windows Terminal crashes if settings tab is the last to be closed (#13695), similarity score: 0.76
[1.9] Crash opening Settings UI (#10106), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@github-actions[bot] commented on GitHub (May 7, 2024): Hi I'm an AI powered bot that finds similar issues based off the issue title. Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you! ### Closed similar issues: - [[Preview] Windows Terminal crashes if settings tab is the last to be closed (#13695)](https://github.com/microsoft/terminal/issues/13695), similarity score: 0.76 - [[1.9] Crash opening Settings UI (#10106)](https://github.com/microsoft/terminal/issues/10106), similarity score: 0.75 > Note: You can give me feedback by thumbs upping or thumbs downing this comment.

claunia commented

@DHowett commented on GitHub (May 7, 2024):

Dr. Watson as the grimmest reaper. I love it.

Would you be able to file feedback and reproduce the crash in the Apps > Terminal node and share the link with us?

I can't get this to happen locally . . . and I want to see if it's the same bug we just fixed with #17199.

@DHowett commented on GitHub (May 7, 2024): Dr. Watson as the grimmest reaper. I love it. Would you be able to file feedback and reproduce the crash in the Apps > Terminal node and share the link with us? I can't get this to happen locally . . . and I want to see if it's the same bug we just fixed with #17199.

claunia commented

@PhMajerus commented on GitHub (May 7, 2024):

Feedback Hub: https://aka.ms/AAqbvpz
I'm not sure it captured the proper dump though, only Windows Terminal shows in the apps list, no separate entry for Windows Terminal Preview.
Let me know.

@PhMajerus commented on GitHub (May 7, 2024): Feedback Hub: https://aka.ms/AAqbvpz I'm not sure it captured the proper dump though, only `Windows Terminal` shows in the apps list, no separate entry for `Windows Terminal Preview`. Let me know.

claunia commented

@PhMajerus commented on GitHub (May 7, 2024):

I can get it to freeze every single time on a Surface Book 2 15", but cannot reproduce on an Intel NUC (NUC13ANKI50WC).

Could it be something GPU-related? The Surface Book 2 has always been a bit unreliable, even Edge sometimes restarts its rendering engine.

@PhMajerus commented on GitHub (May 7, 2024): I can get it to freeze every single time on a Surface Book 2 15", but cannot reproduce on an Intel NUC (NUC13ANKI50WC). Could it be something GPU-related? The Surface Book 2 has always been a bit unreliable, even Edge sometimes restarts its rendering engine.

claunia commented

@DHowett commented on GitHub (May 8, 2024):

I'm seeing a thread tearing down a TSF::Implementation for a shell handwriting input method, a couple shell worker threads also stuck tearing down, and a window trying to update its acrylic background policy hanging also waiting for a shell worker thread. That's weird.

Watson cab 97512468-57cc-48ca-97d5-9721b4e3ec53

@DHowett commented on GitHub (May 8, 2024): I'm seeing a thread tearing down a `TSF::Implementation` for a shell handwriting input method, a couple shell worker threads also stuck tearing down, and a window trying to update its acrylic background policy hanging _also_ waiting for a shell worker thread. That's weird. Watson cab `97512468-57cc-48ca-97d5-9721b4e3ec53`

claunia commented

@PhMajerus commented on GitHub (May 8, 2024):

It's really weird, I could narrow it down to showing the appearance page for any shell, not necessarily the one being used in the other window.
But the settings has to be the tab tore off, if it's another shell window and then that window is used to show the settings and do everything similarly, then it won't crash.

So it has to be the settings page that is tore off to create a new window, and it has to show the appearance with the preview. You can navigate to another setting page again, as long as the preview has been displayed, it will crash.
If the settings is shown in the primary window or in a window created by tearing off another shell tab, it doesn't crash.

Is there some Atlas resources that are shared with the preview and may be freed when Settings is closed? Why would it only happen when the settings is tore off?

It is pretty easy to avoid the bug, and I cannot reproduce it on another system, so it's not a blocking issue by any means, but I feel like there must be some underlying issue that just happens to get less noticeable on other systems.

@PhMajerus commented on GitHub (May 8, 2024): It's really weird, I could narrow it down to showing the appearance page for any shell, not necessarily the one being used in the other window. But the settings has to be the tab tore off, if it's another shell window and then that window is used to show the settings and do everything similarly, then it won't crash. So it has to be the settings page that is tore off to create a new window, and it has to show the appearance with the preview. You can navigate to another setting page again, as long as the preview has been displayed, it will crash. If the settings is shown in the primary window or in a window created by tearing off another shell tab, it doesn't crash. Is there some Atlas resources that are shared with the preview and may be freed when Settings is closed? Why would it only happen when the settings is tore off? It is pretty easy to avoid the bug, and I cannot reproduce it on another system, so it's not a blocking issue by any means, but I feel like there must be some underlying issue that just happens to get less noticeable on other systems.

claunia commented

@PhMajerus commented on GitHub (May 9, 2024):

Could this be related?

I know Microsoft Surface Book 2 display drivers are somewhat unreliable, and Microsoft's Surface team never fixed the issue, Edge also sometimes has to restart its rendering, blacking out all rendering windows and recovering.

@PhMajerus commented on GitHub (May 9, 2024): Could this be related? ![image](https://github.com/microsoft/terminal/assets/25664275/9aa0fc85-009a-4cf6-8373-88a1d5a82cb9) I know Microsoft Surface Book 2 display drivers are somewhat unreliable, and Microsoft's Surface team never fixed the issue, Edge also sometimes has to restart its rendering, blacking out all rendering windows and recovering.

claunia commented

@PhMajerus commented on GitHub (May 10, 2024):

Attached another crash dump to the Feedback Hub report.
This one does not even freeze, it crashes directly, and doesn't involve the Settings page, it's just opening an Ubuntu WSL2 tab, doing apt update/upgrade/autoremove/autoclean, then exit to close the tab. Terminal shows the original cmd tab again and crashes immediately.
Again, this could be replicated every single time on my Surface Book 2.

@PhMajerus commented on GitHub (May 10, 2024): Attached another crash dump to the Feedback Hub report. This one does not even freeze, it crashes directly, and doesn't involve the Settings page, it's just opening an Ubuntu WSL2 tab, doing `apt update/upgrade/autoremove/autoclean`, then `exit` to close the tab. Terminal shows the original cmd tab again and crashes immediately. Again, this could be replicated every single time on my Surface Book 2.

claunia commented

@ghost commented on GitHub (May 13, 2024):

try to disable "Shell handwriting" option in Windows Settings...

@ghost commented on GitHub (May 13, 2024): try to disable "Shell handwriting" option in Windows Settings...

claunia commented

@PhMajerus commented on GitHub (May 13, 2024):

@scc23456 Good catch!
Indeed disabling the Shell handwriting feature seems to fix both crashes, and that would explain the shell handwriting input method that DHowett saw in the crash dump.

So there seems to be a problem between Terminal and "write anywhere", and this shows why it is important to try to test software on some devices with 👆 touch and 🖊️ pen, not only on typical workstations.

@PhMajerus commented on GitHub (May 13, 2024): @scc23456 Good catch! Indeed disabling the `Shell handwriting` feature seems to fix both crashes, and that would explain the shell handwriting input method that DHowett saw in the crash dump. So there seems to be a problem between Terminal and "write anywhere", and this shows why it is important to try to test software on some devices with 👆 touch and 🖊️ pen, not only on typical workstations.

claunia commented

@lhecker commented on GitHub (May 17, 2024):

I've got a laptop with touchscreen, I'm on 22635.3575, and I don't have a Shell Handwriting setting:

Does this only work with pens?

@lhecker commented on GitHub (May 17, 2024): I've got a laptop with touchscreen, I'm on 22635.3575, and I don't have a Shell Handwriting setting: ![image](https://github.com/microsoft/terminal/assets/2256941/76a3e24c-1cc2-4656-8b6f-1f408f4e60d6) Does this only work with pens?

claunia commented

@PhMajerus commented on GitHub (May 17, 2024):

Does this only work with pens?

Yeah, it's a recent feature the shell team introduced to write directly in many common controls. For example we can ink directly inside a textbox or address bar using the pen.

This is intended to be a faster way to input text without having to display the tablet input panel (TabTip).
You'll need a device with a pen digitizer to test it out.

I suspect you're using or subclassing some common control, the shell attaches some overlay inking panel on top of it, and you destroy it without going through the original code that ensures the attached inking panel is properly disposed of, then it crashes when trying to access its parent HWND or something. This is just a wild guess though, I haven't checked how they implemented the Ink Anywere feature yet.

@PhMajerus commented on GitHub (May 17, 2024): > Does this only work with pens? Yeah, it's a recent feature the shell team introduced to write directly in many common controls. For example we can ink directly inside a textbox or address bar using the pen. ![image](https://github.com/microsoft/terminal/assets/25664275/4e9daeed-0d13-411c-8324-9c93535d305a) This is intended to be a faster way to input text without having to display the tablet input panel (TabTip). You'll need a device with a pen digitizer to test it out. I suspect you're using or subclassing some common control, the shell attaches some overlay inking panel on top of it, and you destroy it without going through the original code that ensures the attached inking panel is properly disposed of, then it crashes when trying to access its parent HWND or something. This is just a wild guess though, I haven't checked how they implemented the Ink Anywere feature yet.

claunia commented

@PhMajerus commented on GitHub (May 17, 2024):

@lhecker Are you giving up on this one? I didn't see any similar crash with that feature in other apps, there is probably something Terminal does that makes it crash when that feature extends its controls.

@PhMajerus commented on GitHub (May 17, 2024): @lhecker Are you giving up on this one? I didn't see any similar crash with that feature in other apps, there is probably something Terminal does that makes it crash when that feature extends its controls.

claunia commented

@DHowett commented on GitHub (May 17, 2024):

Are you giving up on this one?

Please don't read too much into how we manage our issue assignments. 😅

@DHowett commented on GitHub (May 17, 2024): > Are you giving up on this one? Please don't read too much into how we manage our issue assignments. 😅

claunia commented

@DHowett commented on GitHub (Jun 25, 2024):

Good news! We couldn't reproduce this because it's fixed in Windows 11 Build 26100 (24H2 release). It still reproduces in the previous release.

Tracking - MSFT:46832480

@DHowett commented on GitHub (Jun 25, 2024): Good news! We couldn't reproduce this because it's fixed in Windows 11 Build 26100 (24H2 release). It still reproduces in the previous release. Tracking - MSFT:46832480

claunia commented