Crash while holding a key

[iamevn]

Windows Terminal version

1.13.11432.0

Windows build number

10.0.22621.1

Other Software

in WSL I'm running

• Debian 11 on kernel 5.10.102.1-microsoft-standard-WSL2
• fish shell (version 3.4.1)
• vim (version 8.2)

Steps to reproduce

I'm not sure what the exact steps to reproduce are, I've seen this crash a few times in the last couple days while holding a key in vim. Trying to find a more reliable way to reproduce but here's what is common across the crashes:

• terminal session was running for at least 1 hour (although one session lasted ~18 hours)
• terminal window contained multiple tabs with separate sessions on the same WSL2 vm
• when it crashes it takes every tab in the terminal window and the underlying WSL2 session with it
• a separate terminal window running an elevated powershell session survives the other window crashing
• crash occurs less than a second after I begin to hold a navigation key in vim (in debian on a WSL2 vm)
• before the crash, I'm able to hold navigation keys without issue
• I don't think it's related to Repeated Bell (eg. end of line in Vim) Causes Reproducible Crash #10957, fairly sure the motion I was performing in vim would not cause a bell. Also I'm able to run tput bel in a loop for at least 10 minutes without any issues (stopped at 10 mins for my ears' sake).

Expected Behavior

Terminal window doesn't crash from underneath me while editing in vim.

Actual Behavior

After a long time with no issues, terminal crashes less than a second after pressing and holding a navigation key (e.g. j, h) in vim. The crash takes out every terminal tab in the window and kills the WSL2 vm so I can't reattach and recover my state.

Event viewer report blames Microsoft.Terminal.Control.dll in each of the crashes that it has events logged for:

Logged at 6/21/2022 1:23:57 PM:

Faulting application name: WindowsTerminal.exe, version: 1.13.2205.23002, time stamp: 0x628bd6e5
Faulting module name: Microsoft.Terminal.Control.dll, version: 1.13.2205.23002, time stamp: 0x628bd501
Exception code: 0xc0000005
Fault offset: 0x00000000000a7031
Faulting process id: 0x0x81D0
Faulting application start time: 0x0x1D885A331CB7DF5
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Control.dll
Report Id: 231fb379-0618-424f-b270-4abcd9c76e91
Faulting package full name: Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

Logged at 6/21/2022 12:14:47 PM:

Faulting application name: WindowsTerminal.exe, version: 1.13.2205.23002, time stamp: 0x628bd6e5
Faulting module name: Microsoft.Terminal.Control.dll, version: 1.13.2205.23002, time stamp: 0x628bd501
Exception code: 0xc0000005
Fault offset: 0x00000000000a7031
Faulting process id: 0x0x2E18
Faulting application start time: 0x0x1D8850DAF2A21D3
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Control.dll
Report Id: 16e18e82-72ce-4917-b27c-ad1086de5754
Faulting package full name: Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

Logged at 6/20/2022 6:24:36 PM:

Faulting application name: WindowsTerminal.exe, version: 1.13.2205.23002, time stamp: 0x628bd6e5
Faulting module name: Microsoft.Terminal.Control.dll, version: 1.13.2205.23002, time stamp: 0x628bd501
Exception code: 0xc0000005
Fault offset: 0x00000000000a7031
Faulting process id: 0x0x7B30
Faulting application start time: 0x0x1D884FA55D2CF69
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Control.dll
Report Id: 5e7df318-5652-4433-8a12-0537323b2c06
Faulting package full name: Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

Logged at 6/20/2022 4:05:15 PM:

Faulting application name: WindowsTerminal.exe, version: 1.13.2205.23002, time stamp: 0x628bd6e5
Faulting module name: Microsoft.Terminal.Control.dll, version: 1.13.2205.23002, time stamp: 0x628bd501
Exception code: 0xc0000005
Fault offset: 0x00000000000a5999
Faulting process id: 0x0x63FC
Faulting application start time: 0x0x1D880EA93FD3C3A
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Control.dll
Report Id: 157dd4ea-2879-4dd5-92bf-41d9449cc517
Faulting package full name: Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

[zadjii-msft]

Hmm. This is 1.13 so it's not the alt buffer crash.

and kills the WSL2 vm

Well, now, that certainly sounds like a bigger issue than just us. Though, maybe if all the WSL sessions go away, it exits itself? I'm less familiar with the machinations of WSL2.

[DHowett]

Nah this definitely is us. Right now the top 5 crashes in TerminalControl are code c0000005...

[iamevn]

maybe if all the WSL sessions go away, it exits itself?

Not sure but I've had WSL2 survive the Windows Store closing my terminal windows on me to update terminal and was able to reattach to the shell processes in a new terminal window.

[zadjii-msft]

c0000005 is meaningless though 🙃 I wish we could get something useful there

[DHowett]

Those addresses point into...

% & llvm-symbolizer.exe --obj=microsoft.terminal.control.dll "CODE 0x00000000000a7031" "CODE 0xa5999" --basenames
int (__cdecl *`bool __cdecl winrt::impl::invoke<struct winrt::Windows::Foundation::TypedEventHandler<struct winrt::Windows::Foundation::IInspectable, struct winrt::hstring>, struct winrt::Microsoft::Terminal::Control::implementation::InteractivityAutomationPeer, struct winrt::hstring>(struct winrt::Windows::Foundation::TypedEventHandler<struct winrt::Windows::Foundation::IInspectable, struct winrt::hstring> const &, struct winrt::Microsoft::Terminal::Control::implementation::InteractivityAutomationPeer const &, struct winrt::hstring const &)'::`4'::handler)(int, int, void *) noexcept
int (__cdecl *`bool __cdecl winrt::impl::invoke<struct winrt::Windows::Foundation::TypedEventHandler<struct winrt::Windows::Foundation::IInspectable, struct winrt::hstring>, struct winrt::Microsoft::Terminal::Control::implementation::InteractivityAutomationPeer, struct winrt::hstring>(struct winrt::Windows::Foundation::TypedEventHandler<struct winrt::Windows::Foundation::IInspectable, struct winrt::hstring> const &, struct winrt::Microsoft::Terminal::Control::implementation::InteractivityAutomationPeer const &, struct winrt::hstring const &)'::`4'::handler)(int, int, void *) noexcept

which are invokers for events coming out of InteractivityAutomationPeer with this signature:

event Windows.Foundation.TypedEventHandler<Object, String> NewOutput;
TYPED_EVENT(NewOutput, IInspectable, hstring);

Which is likely to be failure hash 3f46a289-653a-34ba-9a2a-379ba23358cd (our highest hitter, at 89% of all TermControl crashes!)

[iamevn]

Found one more error event from WindowsTerminal.exe that I accidentally filtered out in the first post. Not sure if it's relevant since it's the only event I see with this exception code and only occurred after the one crash.

It was logged 33 seconds after the oldest event at the bottom of the first post. Its contents exactly match the preceding event except that it has Exception code: 0xc000041d and Report Id: d8bf9507-2bc6-4258-9a8e-3f00959f94e6:

Logged at 6/20/2022 4:05:48 PM:

Faulting application name: WindowsTerminal.exe, version: 1.13.2205.23002, time stamp: 0x628bd6e5
Faulting module name: Microsoft.Terminal.Control.dll, version: 1.13.2205.23002, time stamp: 0x628bd501
Exception code: 0xc000041d
Fault offset: 0x00000000000a5999
Faulting process id: 0x0x63FC
Faulting application start time: 0x0x1D880EA93FD3C3A
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe\Microsoft.Terminal.Control.dll
Report Id: d8bf9507-2bc6-4258-9a8e-3f00959f94e6
Faulting package full name: Microsoft.WindowsTerminal_1.13.11432.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

[zadjii-msft]

I'll stick this in 1.15 for now. We've got a live report of this crash, we should take a closer look. MSFT:39994969 is the internal bug.

The blame on the failure has the following stack:

  DirectUI::AutomationPeer::RaiseAutomationEventImpl
  DirectUI::AutomationPeerGenerated::RaiseAutomationEvent
  TermControlAutomationPeer_::RaiseAutomationEvent
> TermControlAutomationPeer::SignalTextChanged

Which is definitely different than the NotifyNewOutput frame. The notify new output code was in Preview v1.13.1073 & Stable v1.12.1073, in #12358, so that's definitely in this build.

Ironically, I can't open any dumps from that failure without breaking into the post-moretem debugger for windbg itself, spiderman.png.