MEGATHREAD: Crashes in 1.8.1444 and 1.9.1445

[zadjii-msft]

Hey all,

We've been seeing an enormous amount of crashes in the initial 1.8 and 1.9 releases - far more than usual. Hopefully this thread will try and clear up some of the root causes, and provide workarounds while we're working on shipping the hotfix release.

This thread is a work-in-progress as we track the latest state of these crashes.

Crashes on launch

Root cause: There are two possible root causes here. They are fundamentally caused by the MSIX update leaving our package in a torn state, see #10243.

• Cause 1 (WAY more common): The Cascadia.ttf file is locked during the upgrade, but never properly updated to the newest version. On startup, we try to open the locked font file to establish how large the Terminal window should be. The error to load the font file causes the Terminal to crash entirely, instead of falling back to Consolas.
  • This will be any crash where the crash is in a ucrtbase.dll stack frame north of user32!CreateWindowInternal
  • This is tracked in Startup Crash in _HandleCreateWindow on 1.8 Stable #10211
  • This is fixed in Don't throw in GetProposedDimensions #10260
• Cause 2 (only reported once): the Terminal fails to establish itself as the default terminal handler, because it's trying to load the 1.8 TerminalApp.dll, instead of the 1.9 one. We're working with the COM team to try and find out why this is, but if you're reading this, chances are this isn't what you're seeing.
  • This is being tracked in MSIX version tearing causes instability and crashes #10243, and previously Crash on startup, related to defterm #10233.
  • This should be fixed in Switch FAIL_FAST to LOG for starting inbound connection server on monarch startup #10261

Mitigation

• If you've set the Terminal as the Default Terminal application, revert that setting to the vintage Console Host. You can do this by clearing the registry entries in HKCU\Console\%%Startup.
• First try "Repairing" the Terminal app, by going to "Settings > Apps > {whatever Terminal Install you have} > Advanced Options > Repair". This shouldn't delete your settings. (But "Reset" will, so be careful!)
• If that doesn't work, try adding "fontFace": "Consolas" to your defaults under profiles in your settings.json file.

Window appears briefly, then closes immediately

READ: This might also just look like a crash! "Appears briefly" might just look like "closes instantaneously"

Root cause: In #10045, we thought it was a good idea to stop validating your startingDirectory's before spawning processes. In prior releases, we'd check that path exists, and fall back to %USERPROFILE% if it didn't. Turns out, WSL can take a excessive amount of time to report if a path exists or not.
As it also turns out, more people were relying on that silent fallback to %USERPROFILE% than we were expecting.

Now, if you've got "closeOnExit": "always" in your settings, the Terminal will close instantly when it determines that it couldn't launch your commandline in the given startingDirectory.

• This is tracked in error when launching..Could not access starting directory #10245
• We've got a "fix" in Ignore closeOnExit when a conn. moves from Connecting to Failed #10263

Mitigation

• Change closeOnExit to "closeOnExit": "graceful".
• Update the startingDirectory of your profile to an actual Windows path. Remember, it MUST be a Windows path, even for WSL profiles. ~ is not a Windows path, even if PowerShell uses it as a shorthand for %USERPROFILE%. WSL paths will need to use the //wsl$/{distro}/home/{wsl username} format.

Crashes when opening SUI

If you click on the "Settings" entry in the Terminal, and it crashes, this is the section for you.

Root cause: Some of the "default terminal emulator" code checks which packages are available to set as the default terminal. When it can't find any, it returns a default entry of just the vintage console host (which will always exist). We'll do this even the defterm setting isn't enabled on your build of Windows. Turns out that the API to get that list of packages doesn't entirely work right on older versions of Windows, so we'd fail early, and not even return conhost.

• This is tracked in [1.9] Crash opening Settings UI #10106
• This is fixed in Prevent crashes in Settings UI launch on OS versions before package management extensions #10238

Mitigation

• Don't click on "Settings"
• Use the settings.json file to edit your settings temporarily.

Something else?

Seeing a crash that doesn't look like the above? Make sure to search for open issues that sound like what you're seeing, then feel free to open a new one.

• A dump would be the MOST useful thing you could possibly add to your report.
• Baring that, a stack trace would be just about as helpful.
• At the very least, we're going to need a Feedback Hub trace of the crash, and a link to the feedback, so we can look it up in the backend.

Issues without any of the above will likely get closed with prejudice, as we're trying to deal with an exceptionally more active backlog this week. Thanks!

[Chris-Johnston]

Thanks for this post! On 1.8.1444.0 I had a similar issue and mitigation: my default profile used the consolas font, and so wt would load fine, but one of my profiles would crash the whole window. This profile was using Cascadia Mono.
The mitigation was to change this profile's font face back to consolas, now it works fine (just without the nice font).

Would be happy to share logs/stack trace if it would help, seems to repro consistently. Edit: Once I launched into the crashing profile with the consolas font, I changed my config back to Cascadia Mono. The font loaded just fine, and now I can't repro. Good, I guess?

[aaaronic]

+1 Repairing my install fixed the issue for me. (v1.8.1444.0)

[jayjlow]

I having an issue with opening additional terminals. WSL terminal and 2 ssh terminals. Crashed on load. I repaired the install through "Windows Terminal App Settings". Fixed issue. (1.8.1444.0)

[SpitFire-666]

Apologies, are there instructions on how to create/retrieve a dump/trace/feedback hub trace?

I'm seeing regular crashes but they fall into the "Something Else" category. Cheers

[hameno]

#10302 seems related, got a lot of crashes due to this

[DHowett]

ALL: 1.8.152 and 1.9.152 are rolling out through the store with some very pointed crash fixes for the common cases we've observed. We are hitting a huge issue in the MSIX distribution platform that messes up files in our package, but the changes we implemented in #10260 and #10238 should make this much more pleasant.

If you continue to have issues, please please please keep filing feedback. It's so helpful because it's also the currency we can use to get other teams to fix their crap. 😄

@campbellkerr Sure, thanks for sticking with us! If you submit a feedback hub entry in the "Apps > Windows Terminal" category, then cause the crash while it is "Recording", then share the feedback link with us we'll get all the diagnostic info we can 😄

@hameno We're looking at that one; thanks for surfacing it!

[hameno]

@DHowett I've started using the preview version (1.9) today and haven't had any crashes during my work day. Maybe it's already fixed in 1.9 - I'll keep monitoring

[DHowett]

@campbellkerr If you're more inclined to capture traces and dumps locally, grab the src\Terminal.wprp document from our repo, run it using Windows Performance Recorder, and then send us the ETL document or look at it locally. The feedback hub node for "Windows Terminal" almost literally uses that file plus collects dumps.

[SpitFire-666]

@DHowett I managed to record an ETL of it crashing (let me know if you want me to create a new issue?). ETL is here:
https://1drv.ms/u/s!AlE-uu5DK9rJgc4tQuZ-qfRxNKyrzA?e=WBlxI3

I don't have Feedback Hub on this PC (work laptop)

[olegtk]

Was there another update of Windows Terminal around 10/5/2021? We are seeing large volume of feedback tickets about Visual Studio not able to use Cascadia font since 10/5.

[zadjii-msft]

Yep

[olegtk]

I see. Does Windows Terminal still update Cascadia.ttf?

[DHowett]

Terminal still contains Cascadia.ttf, but it does not update it. We have an internal thread going on this -- we should converge there 😄

[olegtk]

never mind then 👍