Startup Crash in _HandleCreateWindow on 1.8 Stable #13954

@DHowett commented on GitHub (May 26, 2021):

The crash is at AppHost.cpp:373:

    auto initialSize = _logic.GetLaunchDimensions(dpix);

@DHowett commented on GitHub (May 26, 2021): The crash is at AppHost.cpp:373: ``` auto initialSize = _logic.GetLaunchDimensions(dpix); ```

claunia commented

@mhutch commented on GitHub (May 26, 2021):

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 commented on GitHub (May 26, 2021): 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?

claunia commented

@DHowett commented on GitHub (May 26, 2021):

@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 😄

@DHowett commented on GitHub (May 26, 2021): @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 😄

claunia commented

@skyclamp commented on GitHub (May 27, 2021):

I have got consistent crashes on my box.
Removed everything in Microsoft.WindowsTerminal_8wekyb3d8bbwe fixed these crashes.
My tweaks are "initialCols","initialRows","fontSize" and "antialiasingMode"

--updates--
After started terminal, I edited settings.json using sublime, added my changes back, terminal works like before again with no crash

@skyclamp commented on GitHub (May 27, 2021): I have got consistent crashes on my box. Removed everything in Microsoft.WindowsTerminal_8wekyb3d8bbwe fixed these crashes. My tweaks are "initialCols","initialRows","fontSize" and "antialiasingMode" --updates-- After started terminal, I edited settings.json using sublime, added my changes back, terminal works like before again with no crash

claunia commented

@Ai-Himmel commented on GitHub (May 27, 2021):

@DHowett Same issue .
A dump here
WindowsTerminal.exe.26552.zip

@Ai-Himmel commented on GitHub (May 27, 2021): @DHowett Same issue . A dump here [WindowsTerminal.exe.26552.zip](https://github.com/microsoft/terminal/files/6551164/WindowsTerminal.exe.26552.zip)

claunia commented

@mitchellrj commented on GitHub (May 27, 2021):

Not sure if this is the same error, but WT 1.8.1444 is crashing on startup for me, unless launched with the --help flag.

Event Viewer shows:

Faulting application name: WindowsTerminal.exe, version: 1.8.2105.24004, time stamp: 0x60ac2e94
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process ID: 0x6bc4
Faulting application start time: 0x01d752da2dd0acd4
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report ID: 7f624378-e80d-463a-9934-5274c0e3a95b
Faulting package full name: Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

@mitchellrj commented on GitHub (May 27, 2021): Not sure if this is the same error, but WT 1.8.1444 is crashing on startup for me, unless launched with the `--help` flag. Event Viewer shows: > Faulting application name: WindowsTerminal.exe, version: 1.8.2105.24004, time stamp: 0x60ac2e94 > Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf > Exception code: 0xc0000409 > Fault offset: 0x000000000007286e > Faulting process ID: 0x6bc4 > Faulting application start time: 0x01d752da2dd0acd4 > Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe > Faulting module path: C:\WINDOWS\System32\ucrtbase.dll > Report ID: 7f624378-e80d-463a-9934-5274c0e3a95b > Faulting package full name: Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe > Faulting package-relative application ID: App

claunia commented

@Bigpet commented on GitHub (May 27, 2021):

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

@Bigpet commented on GitHub (May 27, 2021): 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

claunia commented

@kevingosse commented on GitHub (May 27, 2021):

Not sure if this is the same error, but WT 1.8.1444 is crashing on startup for me, unless launched with the --help flag.

Event Viewer shows:

Faulting application name: WindowsTerminal.exe, version: 1.8.2105.24004, time stamp: 0x60ac2e94
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process ID: 0x6bc4
Faulting application start time: 0x01d752da2dd0acd4
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report ID: 7f624378-e80d-463a-9934-5274c0e3a95b
Faulting package full name: Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

Same one here. It's worth nothing that it happened right after rebooting to install KB5000736, but it could be unrelated.

@kevingosse commented on GitHub (May 27, 2021): > Not sure if this is the same error, but WT 1.8.1444 is crashing on startup for me, unless launched with the `--help` flag. > > Event Viewer shows: > > > Faulting application name: WindowsTerminal.exe, version: 1.8.2105.24004, time stamp: 0x60ac2e94 > > Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf > > Exception code: 0xc0000409 > > Fault offset: 0x000000000007286e > > Faulting process ID: 0x6bc4 > > Faulting application start time: 0x01d752da2dd0acd4 > > Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe > > Faulting module path: C:\WINDOWS\System32\ucrtbase.dll > > Report ID: 7f624378-e80d-463a-9934-5274c0e3a95b > > Faulting package full name: Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe > > Faulting package-relative application ID: App Same one here. It's worth nothing that it happened right after rebooting to install KB5000736, but it could be unrelated.

claunia commented

@kevingosse commented on GitHub (May 27, 2021):

So that's a bit crazy. I did a first session with Windbg:

(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
E:\BA\90\s\src\renderer\dx\DxFontRenderData.cpp(756)\Microsoft.Terminal.Control.dll!00007FFD7A651FAF: (caller: 00007FFD7A651918) Exception(1) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error.
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
E:\BA\90\s\src\renderer\dx\DxFontRenderData.cpp(378)\Microsoft.Terminal.Control.dll!00007FFD7A681401: (caller: 00007FFD7A64A892) ReturnHr(1) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error.
    Msg:[E:\BA\90\s\src\renderer\dx\DxFontRenderData.cpp(756)\Microsoft.Terminal.Control.dll!00007FFD7A651FAF: (caller: 00007FFD7A651918) Exception(1) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error.
] 
E:\BA\90\s\src\renderer\dx\DxRenderer.cpp(1956)\Microsoft.Terminal.Control.dll!00007FFD7A64A8B1: (caller: 00007FFD7A5E3CCF) ReturnHr(2) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error.
E:\BA\90\s\src\cascadia\TerminalControl\TermControl.cpp(2808)\Microsoft.Terminal.Control.dll!00007FFD7A5E3DFD: (caller: 00007FFD7A5E3A0E) Exception(2) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error.
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
Microsoft.Terminal.Control.dll!00007FFD7A67A116: ReturnHr(3) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error.
    Msg:[E:\BA\90\s\src\cascadia\TerminalControl\TermControl.cpp(2808)\Microsoft.Terminal.Control.dll!00007FFD7A5E3DFD: (caller: 00007FFD7A5E3A0E) Exception(2) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error.
] 
(33c4.6a70): Windows Runtime Originate Error - code 40080201 (first chance)
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
TerminalApp.dll!00007FFD1832D0D6: ReturnHr(1) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error.
    Msg:[winrt::hresult_error: A font file exists but could not be opened due to access denied, sharing violation, or similar error.] 
(33c4.6a70): C++ EH exception - code e06d7363 (first chance)
(33c4.6a70): Security check failure or stack buffer overrun - code c0000409 (!!! second chance !!!)
Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT 
ucrtbase!abort+0x4e:
00007ffd`aff6286e cd29            int     29h

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.

@kevingosse commented on GitHub (May 27, 2021): So that's a bit crazy. I did a first session with Windbg: ``` (33c4.6a70): C++ EH exception - code e06d7363 (first chance) (33c4.6a70): C++ EH exception - code e06d7363 (first chance) (33c4.6a70): C++ EH exception - code e06d7363 (first chance) (33c4.6a70): C++ EH exception - code e06d7363 (first chance) E:\BA\90\s\src\renderer\dx\DxFontRenderData.cpp(756)\Microsoft.Terminal.Control.dll!00007FFD7A651FAF: (caller: 00007FFD7A651918) Exception(1) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error. (33c4.6a70): C++ EH exception - code e06d7363 (first chance) (33c4.6a70): C++ EH exception - code e06d7363 (first chance) E:\BA\90\s\src\renderer\dx\DxFontRenderData.cpp(378)\Microsoft.Terminal.Control.dll!00007FFD7A681401: (caller: 00007FFD7A64A892) ReturnHr(1) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error. Msg:[E:\BA\90\s\src\renderer\dx\DxFontRenderData.cpp(756)\Microsoft.Terminal.Control.dll!00007FFD7A651FAF: (caller: 00007FFD7A651918) Exception(1) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error. ] E:\BA\90\s\src\renderer\dx\DxRenderer.cpp(1956)\Microsoft.Terminal.Control.dll!00007FFD7A64A8B1: (caller: 00007FFD7A5E3CCF) ReturnHr(2) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error. E:\BA\90\s\src\cascadia\TerminalControl\TermControl.cpp(2808)\Microsoft.Terminal.Control.dll!00007FFD7A5E3DFD: (caller: 00007FFD7A5E3A0E) Exception(2) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error. (33c4.6a70): C++ EH exception - code e06d7363 (first chance) (33c4.6a70): C++ EH exception - code e06d7363 (first chance) Microsoft.Terminal.Control.dll!00007FFD7A67A116: ReturnHr(3) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error. Msg:[E:\BA\90\s\src\cascadia\TerminalControl\TermControl.cpp(2808)\Microsoft.Terminal.Control.dll!00007FFD7A5E3DFD: (caller: 00007FFD7A5E3A0E) Exception(2) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error. ] (33c4.6a70): Windows Runtime Originate Error - code 40080201 (first chance) (33c4.6a70): C++ EH exception - code e06d7363 (first chance) (33c4.6a70): C++ EH exception - code e06d7363 (first chance) TerminalApp.dll!00007FFD1832D0D6: ReturnHr(1) tid(6a70) 88985004 A font file exists but could not be opened due to access denied, sharing violation, or similar error. Msg:[winrt::hresult_error: A font file exists but could not be opened due to access denied, sharing violation, or similar error.] (33c4.6a70): C++ EH exception - code e06d7363 (first chance) (33c4.6a70): Security check failure or stack buffer overrun - code c0000409 (!!! second chance !!!) Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT ucrtbase!abort+0x4e: 00007ffd`aff6286e cd29 int 29h ``` 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.

claunia commented

@Rhipeus commented on GitHub (May 27, 2021):

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

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.

@Rhipeus commented on GitHub (May 27, 2021): > 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 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.

claunia commented

@zadjii-msft commented on GitHub (May 27, 2021):

Oh no

Line 2808:

TermControl::GetProposedDimensions
->        THROW_IF_FAILED(dxEngine->UpdateFont(desiredFont, actualFont));

But in general, the Terminal usually updates the font via Renderer::TriggerFontChange, which does this as a LOG_IF_FAILED.

@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 LOG_IF_FAILED seems reasonable for a fix. We won't crash in startup, we just (likely) will load with the wrong size.

@zadjii-msft commented on GitHub (May 27, 2021): Oh no Line 2808: ``` TermControl::GetProposedDimensions -> THROW_IF_FAILED(dxEngine->UpdateFont(desiredFont, actualFont)); ``` But in general, the Terminal usually updates the font via `Renderer::TriggerFontChange`, which does this as a `LOG_IF_FAILED`. @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 `LOG_IF_FAILED` seems reasonable for a fix. We won't crash in startup, we just (likely) will load with the wrong size.

claunia commented

@DHowett commented on GitHub (May 27, 2021):

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?

@DHowett commented on GitHub (May 27, 2021): 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?

claunia commented

@zadjii-msft commented on GitHub (May 27, 2021):

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 "fontFace": "garbage"

EDIT: shoot, I couldn't. hmmmm.

@zadjii-msft commented on GitHub (May 27, 2021): 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 `"fontFace": "garbage"` EDIT: shoot, I couldn't. hmmmm.

claunia commented

@DHowett commented on GitHub (May 27, 2021):

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.

@DHowett commented on GitHub (May 27, 2021): 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.

claunia commented

@zadjii-msft commented on GitHub (May 27, 2021):

I wonder if I copy-pasta cascadia.ttf to garbage.ttf, and lock that file, if that'll work...

@zadjii-msft commented on GitHub (May 27, 2021): I wonder if I copy-pasta `cascadia.ttf` to `garbage.ttf`, and lock that file, if that'll work...

claunia commented

@jimmylewis commented on GitHub (May 27, 2021):

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").

@jimmylewis commented on GitHub (May 27, 2021): 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").

claunia commented

@HowardWolosky commented on GitHub (May 28, 2021):

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?

@HowardWolosky commented on GitHub (May 28, 2021): 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?

claunia commented

@miniksa commented on GitHub (May 28, 2021):

Related #10243

@miniksa commented on GitHub (May 28, 2021): Related #10243

claunia commented

@vivlimmsft commented on GitHub (May 28, 2021):

I'm getting crashes which fall into this bucket too.

In addition, I'm seeing an issue which seems related in Visual Studio (which I work on). After taking the update, I was unable to open any text buffers in VS until I switched VS to use a different font-- a System.UnauthorizedAccessException was being thrown from the editor.

Any ideas how the font deployment could have gotten into this state?

@vivlimmsft commented on GitHub (May 28, 2021): I'm getting crashes which fall into this bucket too. In addition, I'm seeing an issue which seems related in Visual Studio (which I work on). After taking the update, I was **unable to open any text buffers in VS** until I switched VS to use a different font-- a System.UnauthorizedAccessException was being thrown from the editor. Any ideas how the font deployment could have gotten into this state?

claunia commented

@zadjii-msft commented on GitHub (May 28, 2021):

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.

@zadjii-msft commented on GitHub (May 28, 2021): 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.

claunia commented

@mccormick-wooden commented on GitHub (May 28, 2021):

I'm receiving the same issues described here. Deleting %localappdata% did not seem to help for me.

Faulting application name: WindowsTerminal.exe, version: 1.8.2105.24004, time stamp: 0x60ac2e94
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process id: 0x23f4
Faulting application start time: 0x01d753cf27ae2aad
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Windows\System32\ucrtbase.dll
Report Id: 6ee7e449-331a-4597-95e0-a39ab3165ffa
Faulting package full name: Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

@mccormick-wooden commented on GitHub (May 28, 2021): I'm receiving the same issues described here. Deleting `%localappdata%` did not seem to help for me. > Faulting application name: WindowsTerminal.exe, version: 1.8.2105.24004, time stamp: 0x60ac2e94 > Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf > Exception code: 0xc0000409 > Fault offset: 0x000000000007286e > Faulting process id: 0x23f4 > Faulting application start time: 0x01d753cf27ae2aad > Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe > Faulting module path: C:\Windows\System32\ucrtbase.dll > Report Id: 6ee7e449-331a-4597-95e0-a39ab3165ffa > Faulting package full name: Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe > Faulting package-relative application ID: App

claunia commented

@DHowett commented on GitHub (May 28, 2021):

So, there are a couple root causes to this recent startup crash regression.

During an upgrade, our font file is somehow both (1) locked and (2) not registered with the system [likely because of (1)]. We added code to try to fall back to the font file on disk in case (2), which is now failing because of case (1).
The same problem, but for one of the DLLs in our package (which should just not be possible) 😬

@DHowett commented on GitHub (May 28, 2021): So, there are a couple root causes to this recent startup crash regression. 1. During an upgrade, our font file is somehow both (1) locked and (2) not registered with the system [likely because of (1)]. We added code to try to fall back to the font file on disk in case (2), which is now failing because of case (1). 2. The same problem, but for _one of the DLLs in our package_ (which should just not be possible) 😬

claunia commented

@MalcolmEvershed commented on GitHub (May 28, 2021):

I ran Process Monitor during the crash and saw this event:

High Resolution Date & Time: ...
Event Class: File System
Operation: CreateFile
Result: DELETE PENDING
Path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.7.1033.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf
TID: ...
Duration: ...
Desired Access: Generic Read
Disposition: Open
Options: Synchronous IO Non-Alert, Non-Directory File, Random Access
Attributes: n/a
ShareMode: Read, Write, Delete
AllocationSize: n/a

Note the DELETE PENDING. I guess that explains how the font open fails.

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:

C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe

But the font file being accessed is from version 1.7.1033.0:

C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.7.1033.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf

Why is the new version of Windows Terminal accessing the old font file (which is DELETE PENDING probably because of some auto-upgrade process)?

@MalcolmEvershed commented on GitHub (May 28, 2021): I ran Process Monitor during the crash and saw this event: > High Resolution Date & Time: ... > Event Class: File System > Operation: CreateFile > Result: **DELETE PENDING** > Path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.7.1033.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf > TID: ... > Duration: ... > Desired Access: Generic Read > Disposition: Open > Options: Synchronous IO Non-Alert, Non-Directory File, Random Access > Attributes: n/a > ShareMode: Read, Write, Delete > AllocationSize: n/a Note the `DELETE PENDING`. I guess that explains how the font open fails. 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: > C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe But the font file being accessed is from version 1.7.1033.0: > C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.7.1033.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf Why is the new version of Windows Terminal accessing the old font file (which is `DELETE PENDING` probably because of some auto-upgrade process)?

claunia commented

@DHowett commented on GitHub (May 28, 2021):

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

@DHowett commented on GitHub (May 28, 2021): @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.

claunia commented

@jcmrva commented on GitHub (May 29, 2021):

I'm experiencing this (same bucket ID), as of today. None of the following make any difference:

repair
deleting everything in Microsoft.WindowsTerminal_8wekyb3d8bbwe
launching different profiles
running as admin

Faulting application name: WindowsTerminal.exe, version: 1.8.2105.24004, time stamp: 0x60ac2e94
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process id: 0x9560
Faulting application start time: 0x01d754bf8ba26bae
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\windows\System32\ucrtbase.dll
Report Id: 4128a31e-fefb-499d-a042-d05cf8fd8baa
Faulting package full name: Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

@jcmrva commented on GitHub (May 29, 2021): I'm experiencing this (same bucket ID), as of today. None of the following make any difference: - repair - deleting everything in Microsoft.WindowsTerminal_8wekyb3d8bbwe - launching different profiles - running as admin > Faulting application name: WindowsTerminal.exe, version: 1.8.2105.24004, time stamp: 0x60ac2e94 Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf Exception code: 0xc0000409 Fault offset: 0x000000000007286e Faulting process id: 0x9560 Faulting application start time: 0x01d754bf8ba26bae Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Faulting module path: C:\windows\System32\ucrtbase.dll Report Id: 4128a31e-fefb-499d-a042-d05cf8fd8baa Faulting package full name: Microsoft.WindowsTerminal_1.8.1444.0_x64__8wekyb3d8bbwe Faulting package-relative application ID: App

claunia commented

@MalcolmEvershed commented on GitHub (May 29, 2021):

What fixed the issue for me was logging out of Windows and logging in again. No need to reboot.

@MalcolmEvershed commented on GitHub (May 29, 2021): What fixed the issue for me was logging out of Windows and logging in again. No need to reboot.

claunia commented

@tr3pan commented on GitHub (May 31, 2021):

I can confirm log out and log in again fixed the issue for me too.

@tr3pan commented on GitHub (May 31, 2021): I can confirm log out and log in again fixed the issue for me too.

claunia commented