terminal

terminal copied to clipboard

Windows Terminal version

1.21.1272.0

Windows build number

10.0.22631.3527 x64

Other Software

Just Terminal Preview, crashes with any shell (tested cmd.exe, bash in Ubuntu in WSL2).

Steps to reproduce

1. Open Windows Terminal Preview with your default shell
2. Click the [v] menu, and select Settings to display the settings page
3. Tear-off the Settings panel into its own window, making both settings and your shell visible
4. Select any shell profile, click [Appearance >]
5. Close the Settings tab, which closes its individual window.
6. Wait ~30 seconds (could be longer apparently if focus is changed)
7. Give the focus to some other app, then click on your shell panel to give it the focus again
8. ?
9. Profit!

I've crashed it 10 times using these steps, it works every single time.

Edit: I'm still trying to reduce the steps to the minimum required.

Expected Behavior

Windows Terminal should keep running

Actual Behavior

Windows Terminal freezes, its client area gets ghosty transparent, it receives the dreaded (Not Responding) suffix, and Dr. Watson comes along to put it out if its misery.

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.

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.

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.

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.

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

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.

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.

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.

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

@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.

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?

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.

@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.

Are you giving up on this one?

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

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