Terminal shows an empty window and then crashes

[Byloth]

Hi!
I'm trying to run this new Windows Terminal.

After some difficulties and a few attempts I was able to build and deploy the project locally.
«Great! Finally!» I said to myself, just before clicking on the Windows Terminal (Dev Build) in the Start menu...

This was the result: an empty window.

After a few seconds, it simply disappeared and then...
Well... Nothing more!

---

Here are some useful (hopefully) information about my current system:

Windows 10 1903 Build 18362.175
x64 architecture
Developer mode enabled
Repo version built: v0.2.1715.0 (66cb7c4)
Build with Visual Studio 2019
Built and deployed for x64 architecture

---

Some time ago, I commented already here (#489 (comment)) explaining the same issue...
But, nobody could help me.

Maybe opening a Issue I will be luckier...

Sorry for the "duplicate"... 😔

[DHowett-MSFT]

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.

[DHowett-MSFT]

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

[yodurr]

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

[ShadowEO]

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

[magiblot]

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)

[ShadowEO]

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

[tanayagar]

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

[Byloth]

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?

[gfbearsfan]

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

[magiblot]

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

[ShadowEO]

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.

[andreili]

• 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_factorywinrt::Windows::Foundation::IActivationFactory(const winrt::param::hstring & name)Line 5222 C++
WindowsTerminal.exe!winrt::impl::factory_cache_entrywinrt::TerminalApp::App,winrt::Windows::Foundation::IActivationFactory::call<<lambda_7763f00f6aca3060375b844bec98aa5c> &>(winrt::TerminalApp::App::<lambda_7763f00f6aca3060375b844bec98aa5c> & callback)Line 5420 C++
WindowsTerminal.exe!winrt::impl::call_factory<winrt::TerminalApp::App,winrt::Windows::Foundation::IActivationFactory,<lambda_7763f00f6aca3060375b844bec98aa5c> >(winrt::TerminalApp::App::<lambda_7763f00f6aca3060375b844bec98aa5c> && 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++

[corganfuzz]

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

[tanayagar]

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

[vRITHNER]

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

[MrR0bert]

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.

[vRITHNER]

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

[Byloth]

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

[DHowett-MSFT]

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.

[metathinker]

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.

[oclockvn]

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

[miniksa]

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.

[magiblot]

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

Thanks, this was exactly my situation.

[corganfuzz]

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

[ShadowEO]

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)

[flcdrg]

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.

[flcdrg]

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 😃

[miniksa]

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.

[imaandrew]

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.

[ShadowEO]

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

[tksunw]

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
}

[cayv]

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.

[tslytsly]

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.

[ShadowEO]

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)

[tslytsly]

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?

[tslytsly]

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.

[miniksa]

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 Force the use of v2 (non-legacy) conhost when in ConPTY mode #1935
• Launching with an Invalid font
  • This was fixed in Fixes crash when specifying invalid font #2153
• Launching without Powershell Core 6
  • This is Display a specific error for not finding the default profile #1348 and Bug Report: Terminal won't start if profile's commandline points to non-existing exe #1458 and Needs to show an error (rather than just a blank tab) if a shell is missing #982
• Launching with Powershell Core 7
  • The scenario as described in Windows Terminal crashes with Powershell 7 #1399 is the same thing that Needs to show an error (rather than just a blank tab) if a shell is missing #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 Terminal Crashes when used with switchable GPU scenario #2183
• The MinMaxControl wasn't stable yet
  • It's stable-er now. This should be fine.
• I use the wrong architecture for my machine
  • Obstruct the user when they try to run WT under WOW #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.

[miniksa]

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.

[miniksa]

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!