terminal: Repeated Bell (eg. end of line in Vim) Causes Reproducible Crash
Windows Terminal version (or Windows build number)
1.10.1933.0
Other Software
Windows 10 (19043.1165) vim 8.1.2269 inside WSL Ubuntu 20.04.2 LTS (GNU/Linux 5.10.16.3-microsoft-standard-WSL2 x86_64) Solarized Dark Theme applied
(Note: have reproduced on non-preview version also)
Steps to reproduce
Start vim, repeatedly press arrow keys to trigger bell, crash varies on which bell but usually takes less than 5/6 tries. This is not specific to Vim, just an easy way to reproduce, I have seen crashes from the bell with bash completion for example also.
Expected Behavior
Not crashing when bell occurs
Actual Behavior
Crash, reported as in MMDevAPI.DLL per the event viewer:
Faulting application name: WindowsTerminal.exe, version: 1.10.2107.12003, time stamp: 0x60ecd68c
Faulting module name: MMDevAPI.DLL, version: 10.0.19041.1023, time stamp: 0x00c1ffe2
Exception code: 0xc0000005
Fault offset: 0x000000000001b33b
Faulting process ID: 0x2b0c
Faulting application start time: 0x01d79298aae18b20
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.10.1933.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\WINDOWS\SYSTEM32\MMDevAPI.DLL
Report ID: e2bccc73-42d1-412c-8e97-45c3e19e5303
Faulting package full name: Microsoft.WindowsTerminalPreview_1.10.1933.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App
Attaching a gif showing this happening, and what it looks like in the event viewer
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 21 (10 by maintainers)
Honestly, that sounds pretty reasonable, I think you have done all that can be done on this one. I’ve also written this up on SuperUser for visibility with workarounds:
https://superuser.com/q/1671049/113572
I am happy with closing this as external.
The MmDevApi team has promised to reach out to the manufacturer of Sonic Studio 3 to help them resolve this issue and prevent the crashing across the board.
However, on the Terminal side, I also have an idea to make
PlaySoundrun through an out-of-proc COM or WinRT server such that if this happens, the MmDevApi callback thread crashes my sacrificial out-of-proc sound playing server and not the entire Terminal process. I don’t feel a bell noise failing to play should be a circumstance that takes down your entire workstream.I’m can repro this 100%. Let me know how I can help (I already gave you dumps)
I’ve contacted the team that owns the MmDevApi.dll internally. I found an entire class of crashes reported to our crash analysis with similar stacks. I browsed the code for this particular callback DLL and it has a lot of locking and threading going on… so some sort of race isn’t totally out of the question especially if we’ve changed our behavior in how we’re calling it recently. Hopefully the owning team gets back to us soon and gives us the assist in understanding how we can fix the issue in Windows and work around it here to make it less impactful.
Hmm. ~We’ve seen this before in #9776, which should have been fixed in #9812 in
1.9.1445.0.~Actually, no, this is different than that. This is overloaded belling leading to a crash, not just chaos. I bet we did something dumb with the throttling recently.