Terminal: Terminal shows an empty window and then crashes

From another comment on the same issue,

if you are seeing a blank screen, make sure you are targeting the right architecture. you cannot run windows terminal x86 on an x64 machine.

Admittedly, I could have read "built and deployed for x64 architecture" and figured that out.
Can you share the build log?

I think the Terminal was so impressed with your desktop image it didn't want to render on top of it.

FWIW, I'm receiving the same behavior on my x86 tablet after installing the MS Store version. Previous copies compiled by me worked, so I'm left scratching my head as to why this is occurring now. I hadn't yet tested on my x64 laptop however, so I am unsure if it's the same there..

Update: After looking at event viewer, I'm receiving an appcrash. I have pulled the events into an evtx if needed.

Faulting application name: WindowsTerminal.exe, version: 1.0.1906.20005, time stamp: 0x5d0c1506
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18922.1000, time stamp: 0xf1c7f3c3
Exception code: 0xc0000005
Fault offset: 0x007d208e
Faulting process id: 0x2238
Faulting application start time: 0x01d528c0b2bc30da
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1715.0_x86__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: 61ba7cc9-da7a-4bfb-8a43-b375251ebb66
Faulting package full name: Microsoft.WindowsTerminal_0.2.1715.0_x86__8wekyb3d8bbwe
Faulting package-relative application ID: App

I just installed from MS Store and experience the same issue. 64-bit OS here.

Nombre de la aplicación con errores: WindowsTerminal.exe, versión: 1.0.1906.20005, marca de tiempo: 0x5d0c1459
Nombre del módulo con errores: TerminalApp.dll, versión: 1.0.1906.20005, marca de tiempo: 0x5d0c140d
Código de excepción: 0xc0000005
Desplazamiento de errores: 0x000000000003a539
Identificador del proceso con errores: 0x1d48
Hora de inicio de la aplicación con errores: 0x01d52949ad9a3604
Ruta de acceso de la aplicación con errores: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1715.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Ruta de acceso del módulo con errores: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1715.0_x64__8wekyb3d8bbwe\TerminalApp.dll
Identificador del informe: a7d6acc0-650b-40e3-a36b-2280d62e8ea9
Nombre completo del paquete con errores: Microsoft.WindowsTerminal_0.2.1715.0_x64__8wekyb3d8bbwe
Identificador de aplicación relativa del paquete con errores: App

I wonder if it can be ran from the command line and see if it prints any error messages.
EDIT: No, it doesn't. (wt.exe)

So I attempted to build it on my own, and I am receiving the same behavior on my latest build. I did happen to try the x64 version on my laptop and it worked fine, but x86 is still not working. Sadly my x86 tablet doesn't have enough storage to be able to install VS onto it and VS won't let me set up a remote debugging profile for x86 (says Debug|x86 is missing from the project manifest when I even attempt to open the properties) so at the moment, my attempts to get to the bottom of why have stalled...

I may need to set up a x86 VM just to debug with :/ assuming the behavior persists there as well.

Now I'm just trying to grab myself an older copy of my build, just so I can at least use the new Terminal, even if it isn't as up to date..

I'm facing the same issue, don't think that there is any compatibility issues here

Ok...
I think I found out why this is happening... 🤔

A couple of minutes ago I tried to run again the Terminal on my PC to log any errors to attach here...
Well... It runs (and it's great)! 🤩

«So? Why now runs? What's the difference?»

Today I was using my notebook on my legs (without any devices connected).
Usually, I use my notebook connected to this Universal Dock.

These kind of devices (DisplayLink docks) are seen by the OS as external video cards without extended support for hardware acceleration...
In facts, you can't run video games or 3D graphics in general even if your GPU is the best one you can buy!

So, I think, if the video card you're trying to render the Terminal on isn't compatible with hardware acceleration (or something like that) it, simply, crashes badly.

It could be also your case @ShadowEO, @magiblot and @tanayagar?
Maybe something like:

• Cheap hardware?
• Integrated video cards?
• Virtual machines?
• ... and so on?

I have similar issue. After installing the Terminal, selecting the top pane dropdown, then (while the Widows Powershell is auto-selected), the terminal loads Visual Studio blank page & crashes.
I also have my (Lenovo W541) notebook on a docking station and am using Win 10 Pro x64b, Nightly, vers 1903, OS Build 18922.1000

@Byloth

So, I think, if the video card you're trying to render the Terminal on isn't compatible with hardware acceleration (or something like that) it, simply, crashes badly.

It could be also your case @ShadowEO, @magiblot and @tanayagar?
Maybe something like:

* Cheap hardware?

* Integrated video cards?

* Virtual machines?

* _... and so on?_

Yes, I do have an Intel GPU (HD Graphics 520) but drivers and harware acceleration are in order. I don't use a docking station or VM, altough I do have this laptop connected to an external display through VGA/DP. But unplugging it changed nothing.

That's a novel idea, but previous builds worked fine, for instance, I can reinstall one of my older dev builds and it opens and runs fine.

Yes, I am on cheap hardware for this device, it's a TMAX TM101W635L. Using an Intel HD Graphics (I am unsure of the exact model atm, as I am away from the machine.)

Virtual Machines work fine on the device, but they aren't in active use (on 2 GBs of non-expandable RAM, you can see why).

My tests are all done on device itself, so no docking stations, no external hardware at all.

I'm planning on setting up a 32-bit VS2019 VM on my main laptop tonight to see if the issue occurs there, and if so, to debug it as well.

• Cheap hardware?
• Integrated video cards?
• Virtual machines?
• _... and so on?_

i5-9600K, RTX-2070, 32Gb RAM, Host OS - blank window and crash.
Into debug, crash here:

WindowsTerminal.exe!winrt::get_activation_factory(const winrt::param::hstring & name)Line 5222 C++
WindowsTerminal.exe!winrt::impl::factory_cache_entry::call< &>(winrt::TerminalApp::App:: & callback)Line 5420 C++
WindowsTerminal.exe!winrt::impl::call_factory >(winrt::TerminalApp::App:: && callback)Line 5501 C++
WindowsTerminal.exe!winrt::TerminalApp::App::App()Line 952 C++
WindowsTerminal.exe!AppHost::AppHost()Line 30 C++
WindowsTerminal.exe!wWinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, wchar_t * __formal, int __formal)Line 35 C++

crashing here , I also have a displaylink device 4k, hooked up to a mini displayport port. and getting this error:

Faulting application name: WindowsTerminal.exe, version: 1.0.1906.20005, time stamp: 0x5d0c1459
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000000000000
Faulting process id: 0x2ee4
Faulting application start time: 0x01d52a090c39d27d
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1715.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: unknown
Report Id: 51227091-efa4-43dc-bc7a-61696a519a8f
Faulting package full name: Microsoft.WindowsTerminal_0.2.1715.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

@Byloth

So, I think, if the video card you're trying to render the Terminal on isn't compatible with hardware acceleration (or something like that) it, simply, crashes badly.
It could be also your case @ShadowEO, @magiblot and @tanayagar?
Maybe something like:

* Cheap hardware?

* Integrated video cards?

* Virtual machines?

* _... and so on?_

Yes, I do have an Intel GPU (HD Graphics 520) but drivers and harware acceleration are in order. I don't use a docking station or VM, altough I do have this laptop connected to an external display through VGA/DP. But unplugging it changed nothing.

I have an integrated Intel card ( Intel HD graphics 620). As for cheap hardware and vms, my answer would be no. Any way to fix?

Hi, I have the same issue and my graphic card is a NVIDIA GeForce GTX 1060

In my case, I was able to fix it by forcing the app to use the Intel HD Graphics 630 graphics card instead of the GTX 1050 card in the NVIDIA control panel.

Thanks for the tip. May I ask you how you did that ?

In my case, I was able to fix it by forcing the app to use the Intel HD Graphics 630 graphics card instead of the GTX 1050 card in the NVIDIA control panel.

Mmmh... Strange! 🤔
I tried it too but, actually, it continues to run on the integrated video card (even if I choose the dedicated video card).

But, yeah... Probably, I did something wrong! 😅

I dragged the Terminal around the screen

I also tried on another computer equipped with an NVidia GTX 970 and it worked well.

I did some other tests and, for some reason, when I run the Terminal on the external monitor connected through the docking station in crashes (as I said before)...
But, if I run it on the internal monitor (works fine, of course) and then I drag the window onto the external monitor, it continues to run without any problems. 😵

Here is my event log (I hope it can be useful):

Nome dell'applicazione che ha generato l'errore: WindowsTerminal.exe, versione: 1.0.1906.20005, timestamp: 0x5d0c1459
Nome del modulo che ha generato l'errore: ucrtbase.dll, versione: 10.0.18362.1, timestamp: 0x5cbddb81
Codice eccezione: 0xc0000409
Offset errore 0x000000000006d3be
ID processo che ha generato l'errore: 0x4208
Ora di avvio dell'applicazione che ha generato l'errore: 0x01d52b2e6735c3fe
Percorso dell'applicazione che ha generato l'errore: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1715.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Percorso del modulo che ha generato l'errore: C:\WINDOWS\System32\ucrtbase.dll
ID segnalazione: e5cd7755-bd3d-487c-a658-fbce95b3f982
Nome completo pacchetto che ha generato l'errore: Microsoft.WindowsTerminal_0.2.1715.0_x64__8wekyb3d8bbwe
ID applicazione relativo al pacchetto che ha generato l'errore: App

Thanks for the tip. May I ask you how you did that ?

I opened the NVIDIA Control Panel, under Manage 3D Settings select the Program Settings tab. At step one, the Windows Terminal is listed as "microsoft.windowsterminal_[id]". At step two I selected the integrated graphics (sorry for the poor drawing skills :)):

I have an NVIDIA GeForce GTX 1080 Ti card here with onboard Intel UHD 630, though somehow, suddenly, today the app is working again. I have no idea why or how.

From anyone in this thread, I need a crash dump. I tried searching every Report ID you all posted, and none of them are coming through.

I suspect that the issues related to not being able to use hardware rendering might be solved with #1263.

There's probably also some robustness to be added to the DX renderer so it sets itself up correctly. If any of you are building from source, it would be nice to have you check if conhost.exe built from the same sources crashes when the key at HKCU\Console UseDx REG_DWORD 0x1 is set (create it if it isn't there.) That will confirm if a crash is isolated to the DX renderer or Terminal startup specific.

I also have the theory that you are all experiencing like 4 different issues here, so we might have to split them up if I try to fix one and it isn't fixed for all of you.

Lastly, we don't readily have access to this type of hardware around here. I'll see what we can do, but if I can get some close assistance, that's the best.

@miniksa Certainly! How can I go about getting a crash dump of it from the affected machine?

I also went to my development station (x64) and attempted the UseDx change you requested. I can confirm that conhost fails to start with UseDx set to 0x1 on a machine where the same source build does work properly. Toggling UseDx back off results in a working console again.

Interestingly, I did this test on the affected tablet (once again with same sources), and conhost works in both scenarios on it, I get a command prompt as normal.. however Cascadia still fails.

I tried out eight of the Azure Pipelines master builds from here: https://dev.azure.com/ms/Terminal/_build?definitionId=136&_a=summary to try and determine where things started breaking.

In reverse chronological sequence, i.e. newest build last:

• #1374 update link to public preview: WORKS
• #1512 fix punct readme: WORKS
• #1452 about dialog contents selectable: WORKS
• #1314 set default startup proj: WINDOW STAYS BLANK
• #1263 fallback swren: WINDOW STAYS BLANK
• #1093 connect clipboard func to keybindings: WINDOW STAYS BLANK
• #929 Apply a GDI region to the top level Island window to allow dragging with a single Island: BLANK THEN CRASH
• #1436 altgr: BLANK THEN CRASH

In other words, between the subsequent merges of #1452 and #1314 (both on 2019-06-24) terminal went from working to blank window at startup (but no crash), and then between the subsequent merges of #1093 and #929 (both on 2019-06-25), terminal went from blank window no crash to blank window and then crash.

(How #1314, which seems to be only a re-ordering in the OpenConsole solution file, can break terminal like this is surprising. However, uninstalling-reinstalling the builds here only confirms the working / non-working status.)

@miniksa here is a crash dump of the #1436 PR Azure Pipelines build crashing.

WindowsTerminal.exe.12900.zip

Thanks for doing a rough bisect for us!

This doesn't look safe _at all_.

.  0  Id: 3264.2748 Suspend: 0 Teb: 0000001b`495e5000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 0000001b`496fe530 00007ffd`df6acaff ucrtbase!abort+0x4e
01 0000001b`496fe560 00007ff6`2e9a952b ucrtbase!terminate+0x1f
02 0000001b`496fe590 00000000`00002000 WindowsTerminal!__scrt_unhandled_exception_filter+0x37 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\utility\utility_desktop.cpp @ 91] 
03 0000001b`496fe598 00000020`00001000 0x2000
04 0000001b`496fe5a0 00000000`01000000 0x00000020`00001000
05 0000001b`496fe5a8 00000000`00000000 0x1000000  

I'm really glad our build pipelines hold on to symbols. :smile:

@miniksa Michael Niksa FTE Certainly! How can I go about getting a crash dump of it from the affected machine?

I also went to my development station (x64) and attempted the UseDx change you requested. I can confirm that conhost fails to start with UseDx set to 0x1 on a machine where the same source build does work properly. Toggling UseDx back off results in a working console again.

Interestingly, I did this test on the affected tablet (once again with same sources), and conhost works in both scenarios on it, I get a command prompt as normal.. however Cascadia still fails.

You can technically right click a process in the Details page of Task Manager and create a dump and attach it somewhere online, but be warned, it may contain personally identifiable information as it dumps the entire memory space.

You can also try using the Feedback Hub and choosing the Windows Terminal app and submitting that way.

Or if it crashes, you can try getting the Windows Error Reporting information from the event viewer and give me all of that so I can try to look up the IDs with the WER service.

it may contain personally identifiable information

That's fine, the tablet it's on gets very light usage. The only real identifiable information on the device may be my real name (which is fine) or the user profile directory, which only contains part of my Github username.

Here is a OneDrive shared folder containing the evtx file (with both Windows Error Reporting event and Application Crash event) and for extra measure, a process dump for you! https://1drv.ms/u/s!AqACoL07fxpWoOIwO6InGCb8fvsZJg?e=ot9XoI

Let me know if you can't get that, and I'll upload it somewhere else, that process dump was larger than I expected for something taking only 5MB of RAM at that time lol.

(TIL I can easily create process dumps, that's a cool feature!)

[...] if it crashes, you can try getting the Windows Error Reporting information from the event viewer and give me all of that so I can try to look up the IDs with the WER service.

Here's a ZIP with some files extracted directly from the Event Viewer...
I hope this is what you're looking for, @miniksa... 😅

📦 Windows Terminal crash.zip

Saw the store version was updated recently. Let the affected PC update and am still experiencing the issue.

As it happens, I also have the problem of recent versions of Windows Terminal crashing on startup with an empty window - and I too have an interesting crash dump! I also got a Time Travel Debugging trace in case that proves useful.

Link - sorry, it's Microsoft-internal-only because of my concerns re my private information:
https://aka.ms/AA5ix7s

Hey @metathinker,
Thanks for sharing this dump! I don't know what build of WT this maps to, since we're not keeping CI build symbols around, and this looks like one of those. :smile:

I'm going to try with the most recent CI build.

@DHowett-MSFT it might have gotten lost in the notes file I wrote, but this is:
https://dev.azure.com/ms/Terminal/_build/results?buildId=23399
building the current master: https://github.com/microsoft/Terminal/commit/eae920e5f931d7efd33cc3e1bfb12f8c683b001b

If I build the same commit on my own box, same problem occurs.

And as far as I could tell, the Azure DevOps CI builds _do_ have symbols - there are .msix and .appxsym files in the build artifacts, and the latter unzips to a bunch of .pdb files. Or is that not the symbols you're looking for?

They do, but we're not archiving them anywhere _durable_ (like the symbol server) because these builds are not intended to be used. I did end up digging up the right symbols for your build. Here's where we're failing out:

02 000000ed`75d0f380 00007fff`0020613e VCRUNTIME140!_CxxThrowException+0xad [d:\agent\_work\5\s\src\vctools\crt\vcruntime\src\eh\throw.cpp @ 133] 
03 000000ed`75d0f3f0 00007fff`00205891 TerminalApp!winrt::throw_hresult+0x1de [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\base.h @ 4320] 
04 (Inline Function) --------`-------- TerminalApp!winrt::check_hresult+0x4c [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\base.h @ 4370] 
05 (Inline Function) --------`-------- TerminalApp!winrt::impl::consume_Windows_UI_Xaml_IApplicationStatics<winrt::Windows::UI::Xaml::IApplicationStatics>::LoadComponent+0x66 [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\Windows.UI.Xaml.h @ 264] 
06 (Inline Function) --------`-------- TerminalApp!winrt::Windows::UI::Xaml::Application::LoadComponent::__l2::<lambda_4c8bf9903964916c8ede32d2039e9272>::operator()+0x71 [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\Windows.UI.Xaml.h @ 11819] 
07 000000ed`75d0f440 00007fff`002021c0 TerminalApp!winrt::impl::factory_cache_entry<winrt::Windows::UI::Xaml::Application,winrt::Windows::UI::Xaml::IApplicationStatics>::call<<lambda_4c8bf9903964916c8ede32d2039e9272> &>+0x231 [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\base.h @ 5440] 
08 (Inline Function) --------`-------- TerminalApp!winrt::impl::call_factory+0x9 [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\base.h @ 5501] 
09 (Inline Function) --------`-------- TerminalApp!winrt::Windows::UI::Xaml::Application::LoadComponent+0x21 [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\Windows.UI.Xaml.h @ 11819] 
0a 000000ed`75d0f4e0 00007fff`002314d0 TerminalApp!winrt::TerminalApp::implementation::MinMaxCloseControl::MinMaxCloseControl+0x190 [d:\a\1\s\src\cascadia\TerminalApp\MinMaxCloseControl.cpp @ 18] 
0b (Inline Function) --------`-------- TerminalApp!winrt::make+0x1b [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\base.h @ 6877] 
0c (Inline Function) --------`-------- TerminalApp!winrt::TerminalApp::MinMaxCloseControl::{ctor}+0x1b [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\MinMaxCloseControl.g.cpp @ 10] 
0d 000000ed`75d0f580 00007fff`0023920a TerminalApp!winrt::TerminalApp::implementation::App::_Create+0xba0 [d:\a\1\s\src\cascadia\TerminalApp\App.cpp @ 144] 
0e (Inline Function) --------`-------- TerminalApp!winrt::TerminalApp::implementation::App::Create+0x74 [d:\a\1\s\src\cascadia\TerminalApp\App.cpp @ 69] 
0f 000000ed`75d0f6e0 00007ff6`4f914df6 TerminalApp!winrt::impl::produce<winrt::TerminalApp::implementation::App,winrt::TerminalApp::IApp>::Create+0x9a [d:\a\1\s\src\cascadia\TerminalApp\Generated Files\winrt\TerminalApp.h @ 647] 
10 (Inline Function) --------`-------- WindowsTerminal!winrt::impl::consume_TerminalApp_IApp<winrt::TerminalApp::IApp>::Create+0xa [d:\a\1\s\src\cascadia\WindowsTerminal\x64\Release\Generated Files\winrt\TerminalApp.h @ 25] 
11 000000ed`75d0f740 00007ff6`4f91412d WindowsTerminal!AppHost::Initialize+0x46 [d:\a\1\s\src\cascadia\WindowsTerminal\AppHost.cpp @ 65] 
12 000000ed`75d0f7a0 00007ff6`4f9190e2 WindowsTerminal!wWinMain+0x4d [d:\a\1\s\src\cascadia\WindowsTerminal\main.cpp @ 43] 
13 (Inline Function) --------`-------- WindowsTerminal!invoke_main+0x21 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
14 000000ed`75d0f830 00007fff`211b7bd4 WindowsTerminal!__scrt_common_main_seh+0x106 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
15 000000ed`75d0f870 00007fff`215cce71 KERNEL32!BaseThreadInitThunk+0x14
16 000000ed`75d0f8a0 00000000`00000000 ntdll!RtlUserThreadStart+0x21

I don't believe this is the same issue as #1364, so I'm going to fork this into another issue. Thanks!

Yeah, your issue is that MinMaxCloseControl isn't ending up in the right place (possibly -- maybe refuted by evidence) _only for CI builds_. Thanks Xaml pipeline! :smile:

Yeah, your issue is that MinMaxCloseControl isn't ending up in the right place (possibly -- maybe refuted by evidence) _only for CI builds_. Thanks Xaml pipeline! 😄

That sure, are you? Well better get that separate issue open, because clicking this link will BLOW YOUR MIND!!!!!!111111!!!!

As I said in passing above, building https://github.com/microsoft/terminal/commit/eae920e5f931d7efd33cc3e1bfb12f8c683b001b on my own computer and running the resulting debug build Terminal app produces the same crash as I got from the Azure DevOps CI release build. Like in the CI release build, the problem's proximate cause is that ms-appx:///MinMaxCloseControl.xaml was not found during a call to Windows.UI.Xaml.Application.LoadComponent(). That call in turn comes from C++/WinRT generated code starting with this call from winrt::TerminalApp::implementation::App::_Create() to the generated constructor for winrt::TerminalApp::MinMaxCloseControl.

Now I'm assuming something peculiar is going on in the Azure DevOps CI build and the build on my own box. Either that, or I could just be deploying the app improperly - I unzip the CI build .appx/.msix or find the folder of loose files I personally built that already has an AppXManifest.xml in it, and then run powershell.exe -command Add-AppXPackage -Register X:\wherever\it\is\AppXManifest.xml.

Now, are you building with MSBuild or with VS? I can reproduce the broken package layout with MSBuild but not with Visual Studio.

On my machine, when VS builds the project, it ends up laying a copy of MinMaxCloseControl.xbf down in the appx package root, where the resource locator suggests it will be. A copy also ends up in TerminalApp.pri. The appx you're pulling from CI and the appx _layout_ you're producing on your machine probably don't have the first copy (.xbf) and only have the second copy (verified in the .msix from the CI artifacts.)

There's probably a couple issues here. One, I have no idea why it's being copied in by VS but not MSBuild; Two, It should be getting rolled up into resources.pri with the other Xaml resources; Three, I have no idea why this works properly for the very similar App.xbf.

Now, are you building with MSBuild or with VS? I can reproduce the broken package layout with MSBuild but not with Visual Studio.

MSBuild - well, precisely, I'm doing this: cd/d [repo root] & .\tools\razzle.cmd dbg & bcz dbg
and the bcz.cmd batch file runs MSBuild as you know.

The app then crashes when I deploy the loose-file folder through either PowerShell or Visual Studio.

I can verify that after scorching the repo with git clean -dxf, opening the solution in Visual Studio, and building, the resulting app runs fine. The loose file folder with AppXManifest.xml also has both App.xbf and MinMaxCloseControl.xbf; both are missing from my MSBuild build and the AzDO CI build.

Perhaps we really do need to fork that separate issue now - this is a pretty bad problem in my opinion, but probably not the one this issue was originally about.

I got this issue and after uncheck Use legacy console option, my terminal show up

I got this issue and after uncheck Use legacy console option, my terminal show up

This is probably different. I forked it to another issue.

I got this issue and after uncheck Use legacy console option, my terminal show up

Thanks, this was exactly my situation.

I can confirm this works. My terminal shows up. However, the settings option is unresponsive after I select it.

As @miniksa said, that's probably a separate issue. My machines don't have that "Use legacy console" feature turned on, and it doesn't work even with them on.

It seems there could be multiple factors to cause this specific response.

That said, I updated Terminal to the latest version in the store and it no longer even fails to this point, opens, shows the titlebar/border (like the previous behavior) and then crashes before the window finishes rendering. (Unlike before, the UWP window titlebar and border are destroyed)

I've submitted an issue using the Feedback Hub - https://aka.ms/AA5jk66

Even though I have Windows Terminal (Preview) listed in Settings | Apps, it didn't come up in the list of Apps in the Feedback Hub, so I just had to choose "All other apps".

I also created a crash dump (applying the same settings as documented here for WindowsTerminal.exe) and attached that to the report.

I did not have PowerShell Core installed on the machine that was showing this crash (but on another device, Terminal was starting without error and it did have PowerShell Core).

Out of curiosity, I installed Core on the failing machine, and now Terminal starts correctly!

choco install powershell-core FTW 😃

I did not have PowerShell Core installed on the machine that was showing this crash (but on another device, Terminal was starting without error and it did have PowerShell Core).

Out of curiosity, I installed Core on the failing machine, and now Terminal starts correctly!

choco install powershell-core FTW 😃

OK, thanks for the data point. On the back end, these crashes are ending up bucketed in the same giant issue, so it's been difficult for me to tease apart the different scenarios here. Every report like this helps me identify another case more easily than rummaging through stack dumps.

I did not have PowerShell Core installed on the machine that was showing this crash (but on another device, Terminal was starting without error and it did have PowerShell Core).

Out of curiosity, I installed Core on the failing machine, and now Terminal starts correctly!

choco install powershell-core FTW 😃

I can confirm, I had the problem and installing powershell core solved it.

Was hoping it would work in my case, but sadly not. Still receiving the problem on my x86 device after installing pwsh-core.

I have this same issue on 2 computers out of 4.

Faulting application name: WindowsTerminal.exe, version: 1.0.1907.2001, time stamp: 0x5d1bd2d0
Faulting module name: TerminalApp.dll, version: 1.0.1907.2001, time stamp: 0x5d1bd294
Exception code: 0xc0000005
Fault offset: 0x000000000003a999
Faulting process id: 0x2e34
Faulting application start time: 0x01d53e5224063e84
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe\TerminalApp.dll
Report Id: c77e9bc2-46ae-4287-804a-e9cb776cf844
Faulting package full name: Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

The two computers have have the issue have powershell-core (6) on them, and one of those also has the powershell 7 preview. The default profiles.json doesn't include entries for those, and it seems to make wt.exe unhappy. The issue also seems to re-appear periodically, perhaps when the updates are automatically applied.

I've found that removing the profiles.json altogether fixes the issue, and Windows Terminal will create a new profiles.json file that includes entries for the additional versions of powershell.

I added a little function to my powershell profile.ps1 that will allow me to reset it, and that always fixes the launch problem on both of the problematic computers.

function Reset-WindowsTerminal {
    [cmdletbinding()]
    Param()

    $pjson = "${env:LOCALAPPDATA}\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\RoamingState\profiles.json"
    Remove-Item -Path $pjson
    Start-Process wt.exe
}

I had this same issue right now after installing the Terminal via Store for the first time in my Surface Book with dGPU. I had just updated Windows to 1903 and installed PowerShell Core using Scoop. After removing the profiles.json file as @tksunw said, it's working. I did not have these problems when doing the same thing with my desktop a few weeks ago.

Ok...
I think I found out why this is happening... 🤔

A couple of minutes ago I tried to run again the Terminal on my PC to log any errors to attach here...
Well... It runs (and it's great)! 🤩

«So? Why now runs? What's the difference?»

Today I was using my notebook on my legs (without any devices connected).
Usually, I use my notebook connected to this Universal Dock.

These kind of devices (DisplayLink docks) are seen by the OS as external video cards without extended support for hardware acceleration...
In facts, you can't run video games or 3D graphics in general even if your GPU is the best one you can buy!

So, I think, if the video card you're trying to render the Terminal on isn't compatible with hardware acceleration (or something like that) it, simply, crashes badly.

It could be also your case @ShadowEO, @magiblot and @tanayagar?
Maybe something like:

• Cheap hardware?
• Integrated video cards?
• Virtual machines?
• _... and so on?_

I'm having the same issue.
I have a Dell USB 3 Displaylink dock.
If I try to start wt.exe while it's connected it wont run, event log:

Faulting application name: WindowsTerminal.exe, version: 1.0.1907.2001, time stamp: 0x5d1bd2d0
Faulting module name: ucrtbase.dll, version: 10.0.18362.1, time stamp: 0x5cbddb81
Exception code: 0xc0000409
Fault offset: 0x000000000006d3be
Faulting process ID: 0x51d8
Faulting application start time: 0x01d541f87a016afd
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report ID: f22bf8c4-d0dc-4991-a79b-f5327bf68a35
Faulting package full name: Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

But, if I disconnect the Dock it will run on my laptop integrated graphics.

I have the latest drivers.

No dock, as stated in my earlier response to someone else who suggested the same thing, previous builds ran perfectly, store build and current tree build does not.

Intel HD Graphics, all internal. No VM, running Windows 10 Pro Latest skip ahead.
TMAX TM101W638L tablet. (Once again, earlier builds ran perfectly, so it doesn't seem to be an issue with the graphics, and the DxRenderer conhost works fine as well)

No dock, as stated in my earlier response to someone else who suggested the same thing, previous builds ran perfectly, store build and current tree build does not.

Intel HD Graphics, all internal. No VM, running Windows 10 Pro Latest skip ahead.
TMAX TM101W638L tablet. (Once again, earlier builds ran perfectly, so it doesn't seem to be an issue with the graphics, and the DxRenderer conhost works fine as well)

Sorry, I wasn't trying to suggest that the solution was to disconnect a Dock if you have one. :)

Although, I also have Intel HD graphics, it could be something to do with that?
Different trigger?

Hi,

Again, not saying this is the reason/fix for everyone, but I think I found the root cause on my PC.

I integrated Intel HD graphics plus an AMD Radeon 530 graphics card on my laptop.
I think that a recent driver update has caused some sort of issue.

This may not be limited to AMD graphics, but I've found that when my Dock is connected and I'm usign Displaylink, the laptop prefers to run most programs using the 530 discreet GPU.
When this is the case, Windows Terminal and mstsc.exe both crash on start.
When I check AppCrashView both crashes involve a dll with crt in the name, ucrtbase.dll for Terminal and msvcrt.dll for mstsc.exe.

I have now found a way to tell Windows not to use the Radeon 530 for both mstsc.exe and wt.exe. Both programs run fine now.

So I think that a recent graphics driver and/or Windows update has cause some sort of problem with the graphics drivers.

This conversation is now locked because people are using it as a dumping ground for literally any crash on start.

I've identified a ton of issues in this thread:

• Launching with Legacy Console selected
  
  
  
  • This was fixed in #1935
  
  
• Launching with an Invalid font
  
  
  
  • This was fixed in #2153
  
  
• Launching without Powershell Core 6
  
  
  
  • This is #1348 and #1458 and #982
  
  
• Launching with Powershell Core 7
  
  
  
  • The scenario as described in #1399 is the same thing that #982 would address
  
  
• Launching on a portable device that uses switchable GPUs or an external dock GPU
  
  
  
  • @DHowett-MSFT has a Surface Book with the switchable GPU thing and hasn't seen this. I totally believe it's a thing and it might even be a mishandling in the DirectX renderer, but we should extract this problem to another issue AND we need to get someone comfortable with debugging this who owns this hardware.
  
  
  • This is now moved to #2183
  
  
• The MinMaxControl wasn't stable yet
  
  
  
  • It's stable-er now. This should be fine.
  
  
• I use the wrong architecture for my machine
  
  
  
  • #1648 blocks you from doing this now
  
  

I will edit this with the resolutions. But no more piling on here. If you have any of these 7 things, follow up on the individual threads or wait for the update if its already fixed.

Note, I'm not saying don't report things. I just need to break this out into individual threads because it's too much to handle all in one place. Let's break the conversations into correlated threads.

OK. All of the issues above as isolated from various discussions in this thread appear to have a follow-on ID number (except MinMaxControl which was only mentioned once while it was still fresh). Please direct conversation about ongoing "empty window and crashes" issues to those specific threads if they're relevant to you.

If they're not relevant, please open a new bug and describe how yours is different from one of those above. Thanks!