-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Startup Crash in _HandleCreateWindow on 1.8 Stable #10211
Comments
The crash is at AppHost.cpp:373:
|
I think I may be seeing this. I have a 100% reproducible crash on startup that started today and the bucket ID in the .wer file matches. Is there any additional information I could provide that would help? |
@mhutch ooh, excellent. A Time Travel trace from WinDbgX (if you have access to it) of starting the Microsoft.WindowsTerminal app package would be the most helpful thing! Or, any dumps from your machine for WindowsTerminal.exe before Watson gets hold of them. Or, your settings file from LOCALAPPDATA\Packages\Microsoft.WindowsTerminal_xyzxyxyzyxyzyx\LocalSettings might at least provide an interesting lead 😄 |
I have got consistent crashes on my box. --updates-- |
@DHowett Same issue . |
Not sure if this is the same error, but WT 1.8.1444 is crashing on startup for me, unless launched with the Event Viewer shows:
|
Had the same issue with the stack overflow Deleted local settings, still crashed Deleted %APPDATA%..\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalCache , then it worked again like nothing happened |
Same one here. It's worth nothing that it happened right after rebooting to install KB5000736, but it could be unrelated. |
So that's a bit crazy. I did a first session with Windbg:
Following that, I configured Windbg to break on first-chance exceptions and launched another session. The "A font file exists but could not be opened" error did not occur again, and... The app works now, with or without Windbg. I don't know what fixed it. I did delete the LocalCache folder at some point, but I'm fairly sure it was still crashing afterwards. |
I tried deleting both LocalCache and LocalState but no luck. I then deleted all of %APPDATA%..\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe and launched fine. Copied my old profile back in and it is running exactly as I want it to. |
Oh no Line 2808:
But in general, the Terminal usually updates the font via @DHowett did we update cascadia code in 1.8 stable as well? I wonder if that's what's causing these errors to crop up. Switching to a |
YES! I didn't realize that's why that was failing! Two things: 1. we should ABSOLUTELY just start with a best-guess character cell size scaled for DPI. 2. I bet this is failing to read Cascadia.ttf because ACCESS_DENIED on the app upgrade path somewhere in @miniksa's "manual font fallback" code. Can we fix both of these? |
Yea what I want to do is hopefully just fall back to consolas or whatever. I think in the rest of the TermControl, we just gracefully move on here, ignoring the error, and then looking up the font we fell back to. Methinks that'll work in this case too. Only thing is getting a repro on this. I don't really want to much with the permissions on a font file, so I'm wondering if I can repro this with EDIT: shoot, I couldn't. hmmmm. |
Yeah. This codepath is only hit when the OS fails to find Cascadia in the font cache and we manually load it from disk. This is a hard one to hit organically. |
I wonder if I copy-pasta |
FWIW, I ran into this when the Windows Store updated my Terminal to 1.8. Cascadia was not recognized in the Windows Settings -> Font Settings until I rebooted my machine, upon which Windows Terminal also started working again. Just wanted to post this in case others come across this thread ("try turning it off and on again"). |
On one of my machines after the update to 1.8.1444. it would open up fine to my default PowerShell tab, but any new tabs opened after that would crash it. On another machine, it crashed before showing any tabs. To temporarily stay unblocked, I installed Windows Windows Terminal Preview (1.9.1445) on those machines to use in the interim. In a completely unexpected turn of events, as soon as I installed Preview on each machine, stable (1.8.1444) started functioning just fine again. Is Preview registering Cascadia globally upon install? |
Related #10243 |
the underlying font bug was MSFT:32337657, which I think is fixed in 22380. That being said, this might also be a new underlying bug with the platform, hard to say for sure. |
I'm receiving the same issues described here. Deleting
|
So, there are a couple root causes to this recent startup crash regression.
|
I ran Process Monitor during the crash and saw this event:
Note the I don't know why it would be in that state. I just booted up my machine and ran Windows Terminal. What's interesting is that the WindowsTerminal.exe that is running is version 1.8.1444.0:
But the font file being accessed is from version 1.7.1033.0:
Why is the new version of Windows Terminal accessing the old font file (which is |
@MalcolmEvershed that's a mystery to us, which we're tracking over in #10243. We trusted the platform to provide a stable update experience and yet, we end up with PE files and fonts coming from the old version. It's a madhouse. |
I cannot for the life of me repro the original bug. I've got fonts with bad permissions SxS, I've tried installing a font twice, I've tried stopping the font cache service. No idea how to manually repro the original bug. BUT theoretically, this function should never throw. So lets just switch this to a `LOG_IF_FAILED`, and hope that this goes away? * [x] Fixes #10211? * [x] built & ran manually. Unclear if this can get cherry-picked trivially to 1.8. Code's pretty trivial though so if we need another PR for that, it can be arranged.
I'm experiencing this (same bucket ID), as of today. None of the following make any difference:
|
What fixed the issue for me was logging out of Windows and logging in again. No need to reboot. |
I can confirm log out and log in again fixed the issue for me too. |
I cannot for the life of me repro the original bug. I've got fonts with bad permissions SxS, I've tried installing a font twice, I've tried stopping the font cache service. No idea how to manually repro the original bug. BUT theoretically, this function should never throw. So lets just switch this to a `LOG_IF_FAILED`, and hope that this goes away? * [x] Fixes #10211? * [x] built & ran manually. Unclear if this can get cherry-picked trivially to 1.8. Code's pretty trivial though so if we need another PR for that, it can be arranged. (cherry picked from commit 89ca2ae)
I cannot for the life of me repro the original bug. I've got fonts with bad permissions SxS, I've tried installing a font twice, I've tried stopping the font cache service. No idea how to manually repro the original bug. BUT theoretically, this function should never throw. So lets just switch this to a `LOG_IF_FAILED`, and hope that this goes away? * [x] Fixes #10211? * [x] built & ran manually. Unclear if this can get cherry-picked trivially to 1.8. Code's pretty trivial though so if we need another PR for that, it can be arranged. (cherry picked from commit 89ca2ae)
🎉This issue was addressed in #10260, which has now been successfully released as Handy links: |
🎉This issue was addressed in #10260, which has now been successfully released as Handy links: |
Windows Terminal version (or Windows build number)
1.8.144444
Other Software
No response
Steps to reproduce
No idea.
Expected Behavior
No response
Actual Behavior
Look at Watson bucket
4ba5cd02-f285-99e4-6254-56f3218146c9
or failure ID5133fdab-7a9f-5853-f23d-43d441146a6c
. 3,000 hits in the last few days.The text was updated successfully, but these errors were encountered: