microsoft
Terminal is crashing when closing tabs with no error message
Windows Terminal version
1.14.2281.0
Windows build number
10.0.19043.1889
Other Software
n/a
Steps to reproduce
When I have many tabs open (sometimes multiple windows in one tab) and I close them (usually ctrl+d I am in linux subsystem), there is this closing animation where tab disappears and during this Windows Terminal is randomly crashing. It only happens like in 1 out of 10 close operations, not always.
It's only happening when closing tabs (or parts of tabs) and it's really annoying. I stopped closing tabs for this reason only, which leads to massive clutter.
When it crashes it doesn't say anything, just whole app closes with all its tabs.
Expected Behavior
Not crash when closing tabs, or at least show some error message that helps to debug the problem
Actual Behavior
The program is crashing when I am closing tabs
After taking a closer look, it looks like there's a few crashes from this. Here's our hypothesis:
- you close the shell (underlying app)
- this ends up clearing the display (or adding more output that's causing us to scroll)
- when the UI is closed, it's trying to access the scrollbar for a terminal control that is being torn down
- crash!
a note for the team:
This looks like watson failure hash ae105b00-f5ac-8f42-4dd9-a9e54049d8a0
Windows Terminal version
1.16.2641.0
Windows build number
10.0.19044.2006
Other Software
WSL2 with Ubuntu 22.04
Steps to reproduce
- Start Windows Terminal.
- Maximize the window.
- Open a new tab with Ubuntu.
- Exit the shell inside the tab (Ctrl+d or logout or exit)
- Terminal closes the tab, switches back to the first tab and after a while it crashes.
Sometimes you have to repeat from the step 3 few times. I was unable to reproduce the crash by exiting a tab with Windows PowerShell or Command Prompt.
Expected Behavior
Windows Terminal continuing running without a crash.
Actual Behavior
Windows Terminal crashes.
Feedback Hub: aka.ms/AAignhy
I have found this in Event Viewer > Windows Logs > Application:
Faulting application name: WindowsTerminal.exe, version: 1.16.2209.21001, time stamp: 0x632b96ad Faulting module name: ntdll.dll, version: 10.0.19041.1949, time stamp: 0xfe96c48e Exception code: 0xc000000d Fault offset: 0x0000000000112664 Faulting process id: 0x744 Faulting application start time: 0x01d8e2edb0ba0364 Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.16.2641.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll Report Id: c6955e69-d4ae-47a8-9faa-6762570e8f90 Faulting package full name: Microsoft.WindowsTerminalPreview_1.16.2641.0_x64__8wekyb3d8bbwe Faulting package-relative application ID: App
C:\WINDOWS\SYSTEM32\ntdll.dllshows a valid Microsoft's signature, file version:10.0.19041.1949This bug might be the same problem: #14025
In fact I am almost sure that I encountered the crashes in one or two previous versions.
(Copied from #14247)
- this ends up clearing the display (or adding more output that's causing us to scroll)
No, it does not depend on any scrolling. The crash happens also when the terminal is empty (with just the command prompt and nothing else). Also exit or logout in bash does not clear screen.
I was unable to reproduce the crash using Close pane (Ctrl+Shift+w) but in both the cases the visible content of the terminal is the same at the time of closing the pane. So the crash seems to depend on a difference between those two ways of closing a pane.
After I disabled Use the new text renderer ("AtlasEngine") I was unable to reproduce the crash. I have a workaround!!! 😂 It looks like the bug is related to the AtlasEngine renderer!
During experimentation I also discovered that I was wrong: The window does not need to be maximized to be able to make it crash. The probability of the crash depends on the window size. In my case it crashes in about this percentage of cases based on the window size:
- 1920 x 1000: 80 %
- 1100 x 630: 10 %
- 460 x 200: < 3 % (unable to make it crash)
I'm also able to get Windows Terminal to crash fairly consistently when I close my Ubuntu 20.04 WSL2 session using "exit". It's more frequent if I've previously opened and closed vim, and even more frequent if vim connects to my VcXsrv instance on my Windows host when it's opened. It's very annoying.
Is there any diagnostic information that I can provide to help troubleshoot and resolve this issue? Here's an example of the Event Viewer entry.
My Windows 10 version is 21H2 Build 19044.2130.
Faulting application name: WindowsTerminal.exe, version: 1.16.2209.21001, time stamp: 0x632b96ad
Faulting module name: Microsoft.Terminal.Control.dll, version: 1.16.2209.21001, time stamp: 0x632b94c6
Exception code: 0xc0000005
Fault offset: 0x0000000000008435
Faulting process id: 0x5b64
Faulting application start time: 0x01d8e55748954b22
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.16.2641.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.16.2641.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Control.dll
Report Id: 66f5dc69-9473-466d-b371-2857aaaaa7de
Faulting package full name: Microsoft.WindowsTerminalPreview_1.16.2641.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App
I think I run into this as well.
I often have one of more Docker containers running (with for instance a local test db) for a major part of the day and I have other WSL2 Ubuntu 20.04.5 tabs open as well for other stuff. When at the end of the day I close one Ubuntu tab (usually with Ctrl+D) Terminal almost always crashes.
For me I only see this behavior with Ubuntu tabs that are running for a longer period, at least a couple of hours.
Not sure if it is related, but I have the global setting to close a tab even when it fails.
I run Windows Terminal-preview 1.16.2641.0 on Windows 10 22H2 19045.2251
I get events in the Event Viewer as well like this:
Naam van toepassing met fout: WindowsTerminal.exe, versie: 1.16.2209.21001, tijdstempel: 0x632b96ad
Naam van module met fout: ntdll.dll, versie: 10.0.19041.2130, tijdstempel: 0xb5ced1c6
Uitzonderingscode: 0xc000000d
Foutmarge: 0x0000000000112684
Id van proces met fout: 0x3768
Starttijd van toepassing met fout: 0x01d8fe470457b374
Pad naar toepassing met fout: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.16.2641.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Pad naar module met fout: C:\Windows\SYSTEM32\ntdll.dll
Rapport-id: 6158075b-1ba7-496e-820a-f779e7174613
Volledige pakketnaam met fout: Microsoft.WindowsTerminalPreview_1.16.2641.0_x64__8wekyb3d8bbwe
Relatieve toepassings-id van pakket met fout: App
Shoot. I think we're gonna need an updated ~feedback hub~ dump here. Though, if this isn't readily reproducible, then we'll need to try something else.
Can you try following the steps in this post to set up automatic crash dumps? (For more info, see this link) If that works, then you should be able to automatically get a .dmp of the terminal when it crashes.
As far as sending it to us, that depends how you're comfortable sharing the dump. It might have PII in it, definitely including whatever output was in the Terminal at the time. So there's a little tradeoff between "how easy it is to share" vs "how private I want to be"
You can email it to me (my email address is in my profile), with the usual caveats of security that accompany email. If you're cool with that, ping me here when you send it. A OneDrive (or similar) link would also work about the same.
For the more secure option: you can upload a .dmp to Feedback Hub, without making FH try to take the dump itself. If you just drag/drop the dmp to the "Attached" section of FH, it should upload it.
Make sure to share the aka.ms link that Feedback Hub generates with the "Share" button - it's impossible to find without that.
Admittedly, I've never had anyone try the "manually attach to feedback hub" option yet, so idk if that'll actually work 😅 Pick your poison!
FYI, I was also able to work around this issue by disabling "Use the new text renderer", so it's definitely an issue with the AtlasEngine.
Derp, I missed the link to the failure hash. MSFT:35902956.
Microsoft.Terminal.Control.dll!ThrottledFunc_0,winrt::Microsoft::Terminal::Control::ScrollPositionChangedArgs_::Run_winrt::Microsoft::Terminal::Control::ScrollPositionChangedArgs &_
Curious that this would go away after disabling Atlas engine. In fact, OP's crash was on 1.14, which predated the atlas engine entirely, so I'd reckon that's a different crash.
Interesting part of the stack
0b 0000009c`9efff230 00007ffa`7fee4b87 ntdll!TppRaiseInvalidParameter+0x48 [minkernel\threadpool\ntdll\tp.c @ 191]
0c 0000009c`9efff310 00007ffa`7fee2de9 ntdll!TppTimerpValidateTimer+0x6f [minkernel\threadpool\ntdll\timer.c @ 290]
0d 0000009c`9efff340 00007ff9`d2c75a9f ntdll!TpSetTimerEx+0x39 [minkernel\threadpool\ntdll\timer.c @ 1782]
0e (Inline Function) --------`-------- Microsoft_Terminal_Control!ThrottledFunc<0,winrt::Microsoft::Terminal::Control::ScrollPositionChangedArgs>::_leading_edge+0x14 [C:\a\_work\1\s\src\cascadia\WinRTUtils\inc\ThrottledFunc.h @ 99]
0f 0000009c`9efff3a0 00007ff9`d2c74922 Microsoft_Terminal_Control!ThrottledFunc<0,winrt::Microsoft::Terminal::Control::ScrollPositionChangedArgs>::Run<winrt::Microsoft::Terminal::Control::ScrollPositionChangedArgs &>+0xab [C:\a\_work\1\s\src\cascadia\WinRTUtils\inc\ThrottledFunc.h @ 59]
10 0000009c`9efff3f0 00007ff9`d2c8ce31 Microsoft_Terminal_Control!winrt::Microsoft::Terminal::Control::implementation::ControlCore::_terminalScrollPositionChanged+0x72 [C:\a\_work\1\s\src\cascadia\TerminalControl\ControlCore.cpp @ 1376]
11 (Inline Function) --------`-------- Microsoft_Terminal_Control!std::invoke+0x1d [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\include\type_traits @ 1564]
12 (Inline Function) --------`-------- Microsoft_Terminal_Control!std::_Invoker_ret<std::_Unforced>::_Call+0x1d [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\include\functional @ 681]
13 (Inline Function) --------`-------- Microsoft_Terminal_Control!std::_Call_binder+0x1d [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\include\functional @ 1973]
14 (Inline Function) --------`-------- Microsoft_Terminal_Control!std::_Binder<std::_Unforced,void (__cdecl winrt::Microsoft::Terminal::Control::implementation::ControlCore::*)(int,int,int),winrt::Microsoft::Terminal::Control::implementation::ControlCore *,std::_Ph<1> const &,std::_Ph<2> const &,std::_Ph<3> const &>::operator()+0x1d [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\include\functional @ 2010]
15 (Inline Function) --------`-------- Microsoft_Terminal_Control!std::invoke+0x1d [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\include\type_traits @ 1558]
16 (Inline Function) --------`-------- Microsoft_Terminal_Control!std::_Invoker_ret<void>::_Call+0x1d [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\include\functional @ 668]
17 0000009c`9efff430 00007ff9`d2c75f98 Microsoft_Terminal_Control!std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,void (__cdecl winrt::Microsoft::Terminal::Control::implementation::ControlCore::*)(int,int,int),winrt::Microsoft::Terminal::Control::implementation::ControlCore *,std::_Ph<1> const &,std::_Ph<2> const &,std::_Ph<3> const &>,void,int,int,int>::_Do_call+0x21 [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\include\functional @ 832]
18 (Inline Function) --------`-------- Microsoft_Terminal_Control!std::_Func_class<void,int,int,int>::operator()+0x28 [C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\include\functional @ 878]
19 0000009c`9efff470 00007ff9`d2ce0895 Microsoft_Terminal_Control!Microsoft::Terminal::Core::Terminal::_NotifyScrollEvent+0x84 [C:\a\_work\1\s\src\cascadia\TerminalCore\Terminal.cpp @ 1318]
1a 0000009c`9efff4e0 00007ff9`d2c92854 Microsoft_Terminal_Control!Microsoft::Console::VirtualTerminal::AdaptDispatch::_EraseScrollback+0x119 [C:\a\_work\1\s\src\terminal\adapter\adaptDispatch.cpp @ 1944]
1b 0000009c`9efff590 00007ff9`d2c6b000
Oh hey that's #13880 which should be fixed in the latest builds of 1.15 / 1.16.
@austin-beer whatever you're seeing is a different root cause from the issue in this thread, can you file a new issue?
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.
