Repeated Bell (eg. end of line in Vim) Causes Reproducible Crash

[comerford]

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

[comerford]

I will just add that this has persisted through:

• sfc /scannow
• downgrade to release (non-preview) version
• complete delete and reinstall of terminal

[zadjii-msft]

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.

[comerford]

More information after seeing this a few more times:

• Sometimes this happens after as little as 2 or 3 bells (tab completion), sometimes it takes a lot (10-15)
• There is a hang where it freezes for a couple of seconds before it crashes
• It is mostly seen with MMDevAPI.DLL but I have seen at least one reported from ntdll.dll

I'm going to have to switch to a new terminal for a while, the instability this introduces is extremely disruptive, but I am happy to test as needed.

[DHowett]

@comerford you may, as a workaround, want to switch to visual belling only. It's at the bottom of the profile settings' first page. If you're on Preview, you can set it for all profiles at once in the "Defaults" section. That is, unless you really like having audible bells. 😄

[comerford]

You know, I recall that I previously had the sound disabled, but that may have gotten reset previously, and certainly once I deleted and reinstalled.

I played with some of the combinations, and enabling a screen flash in addition to the audible bell still caused the crash to occur but it took a lot longer to happen. It's as if the flash slows things down enough to make the crash less likely (the flash causes the audible bells to be slower, I think).

If I enable just the window flash there seems to be no crash, though I will have to do some extended testing to be sure. Sometimes the audible bell can take some time to cause a crash too.

[j4james]

This may be a long shot, but have a look at the settings for your audio output device, and see if you've got any advanced options enabled (e.g. something like surround sound, or bass boost) and try turning those off. I remember having a problem in the past when triggering a lot of PlaySound operations, and it ended up being the result of a bug in the audio driver, which was resolved by disabling some or other option.