starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal is crashing when closing tabs with no error message #18489

New Issue
Closed
opened 2026-01-31 06:15:38 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 06:15:38 +00:00
Owner
Copy Link

Originally created by @benapetr on GitHub (Sep 17, 2022).

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

Originally created by @benapetr on GitHub (Sep 17, 2022). ### 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
claunia commented 2026-01-31 06:15:40 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Oct 19, 2022):

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

@carlos-zamora commented on GitHub (Oct 19, 2022): 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`
claunia commented 2026-01-31 06:15:40 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 20, 2022):

Windows Terminal version

1.16.2641.0

Windows build number

10.0.19044.2006

Other Software

WSL2 with Ubuntu 22.04

Steps to reproduce

  1. Start Windows Terminal.
  2. Maximize the window.
  3. Open a new tab with Ubuntu.
  4. Exit the shell inside the tab (Ctrl+d or logout or exit)
  5. 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.dll shows a valid Microsoft's signature, file version: 10.0.19041.1949

This 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)

@DHowett commented on GitHub (Oct 20, 2022): > ### Windows Terminal version > 1.16.2641.0 > > ### Windows build number > 10.0.19044.2006 > > ### Other Software > WSL2 with Ubuntu 22.04 > > ### Steps to reproduce > 1. Start Windows Terminal. > 2. Maximize the window. > 3. Open a new tab with Ubuntu. > 4. Exit the shell inside the tab (Ctrl+d or logout or exit) > 5. 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](https://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.dll` shows a valid Microsoft's signature, file version: `10.0.19041.1949` > > This 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)
claunia commented 2026-01-31 06:15:40 +00:00
Author
Owner
Copy Link

@vbrozik commented on GitHub (Oct 21, 2022):

  • 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)
@vbrozik commented on GitHub (Oct 21, 2022): > * 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)
claunia commented 2026-01-31 06:15:40 +00:00
Author
Owner
Copy Link

@austin-beer commented on GitHub (Oct 21, 2022):

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
@austin-beer commented on GitHub (Oct 21, 2022): 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 ```
claunia commented 2026-01-31 06:15:41 +00:00
Author
Owner
Copy Link

@ffes commented on GitHub (Nov 23, 2022):

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
@ffes commented on GitHub (Nov 23, 2022): 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 ```
claunia commented 2026-01-31 06:15:41 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 5, 2023):

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.

image

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!

@zadjii-msft commented on GitHub (Jan 5, 2023): 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](https://www.meziantou.net/tip-automatically-create-a-crash-dump-file-on-error.htm) to set up automatic crash dumps? (For more info, see [this link](https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps)) 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. ![image](https://user-images.githubusercontent.com/18356694/185668675-22a98b4f-1ea7-4079-be35-d9597ad77285.png) 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!
claunia commented 2026-01-31 06:15:41 +00:00
Author
Owner
Copy Link

@austin-beer commented on GitHub (Jan 6, 2023):

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.

@austin-beer commented on GitHub (Jan 6, 2023): 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.
claunia commented 2026-01-31 06:15:41 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 6, 2023):

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.

@zadjii-msft commented on GitHub (Jan 6, 2023): 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.
claunia commented 2026-01-31 06:15:42 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 6, 2023):

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?

@zadjii-msft commented on GitHub (Jan 6, 2023): <details> <summary>Interesting part of the stack </summary> ``` 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 ``` </details> 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?
claunia commented 2026-01-31 06:15:42 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 10, 2023):

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.

@ghost commented on GitHub (Jan 10, 2023): 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**.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-TerminalControl Issue-Bug Needs-Author-Feedback No-Recent-Activity Priority-1 Product-Terminal Severity-Crash
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#18489
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?