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

MEGATHREAD: Crashes in 1.8.1444 and 1.9.1445 #14078

New Issue
Open
opened 2026-01-31 04:00:18 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 04:00:18 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Jun 1, 2021).

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.
  • 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.

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.

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.

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!

Originally created by @zadjii-msft on GitHub (Jun 1, 2021). 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 #10211 * This is fixed in #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 #10243, and previously #10233. * This should be fixed in #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`](https://github.com/microsoft/terminal/wiki/Frequently-Asked-Questions-(FAQ)#where-can-i-find-the-settings-file) 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 #10245 * We've got a "fix" in #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 #10106 * This is fixed in #10238 ### Mitigation * Don't click on "Settings" * Use the [`settings.json`](https://github.com/microsoft/terminal/wiki/Frequently-Asked-Questions-(FAQ)#where-can-i-find-the-settings-file) 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!
claunia added the Needs-Tag-FixProduct-TerminalPriority-0Severity-Crash labels 2026-01-31 04:00:18 +00:00
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 Needs-Tag-Fix Priority-0 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#14078
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?