Terminal shows an empty window and then crashes #1809

@yodurr commented on GitHub (Jun 22, 2019):

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

@yodurr commented on GitHub (Jun 22, 2019): I think the Terminal was so impressed with your desktop image it didn't want to render on top of it.

claunia commented

@ShadowEO commented on GitHub (Jun 22, 2019):

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

@ShadowEO commented on GitHub (Jun 22, 2019): 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 ```

claunia commented

@magiblot commented on GitHub (Jun 22, 2019):

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)

@magiblot commented on GitHub (Jun 22, 2019): 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`)

claunia commented

@ShadowEO commented on GitHub (Jun 23, 2019):

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

@ShadowEO commented on GitHub (Jun 23, 2019): 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..

claunia commented

2026-01-30 22:37:01 +00:00

@tanayagar commented on GitHub (Jun 23, 2019):

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

@tanayagar commented on GitHub (Jun 23, 2019): I'm facing the same issue, don't think that there is any compatibility issues here

claunia commented

@Byloth commented on GitHub (Jun 23, 2019):

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?

@Byloth commented on GitHub (Jun 23, 2019): 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](https://www.dell.com/en-us/shop/dell-universal-dock-d6000/apd/452-bcyt/pc-accessories). These kind of devices ([DisplayLink](https://www.displaylink.com/) 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?*

claunia commented

2026-01-30 22:37:01 +00:00

@gfbearsfan commented on GitHub (Jun 23, 2019):

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

@gfbearsfan commented on GitHub (Jun 23, 2019): I have similar issue. After installing the Terminal, selecting the top pane dropdown, then <Settings> (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

claunia commented

2026-01-30 22:37:01 +00:00

@magiblot commented on GitHub (Jun 23, 2019):

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

@magiblot commented on GitHub (Jun 23, 2019): @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.

claunia commented

@ShadowEO commented on GitHub (Jun 23, 2019):

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.

@ShadowEO commented on GitHub (Jun 23, 2019): 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.

claunia commented

@andreili commented on GitHub (Jun 23, 2019):

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

@andreili commented on GitHub (Jun 23, 2019): > * 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<winrt::Windows::Foundation::IActivationFactory>(const winrt::param::hstring & name)Line 5222 C++ WindowsTerminal.exe!winrt::impl::factory_cache_entry<winrt::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++

claunia commented

@corganfuzz commented on GitHub (Jun 23, 2019):

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

@corganfuzz commented on GitHub (Jun 23, 2019): crashing here , I also have a displaylink device 4k, hooked up to a mini displayport port. and getting this error: ```powershell 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 ```

claunia commented

@tanayagar commented on GitHub (Jun 24, 2019):

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

@tanayagar commented on GitHub (Jun 24, 2019): > @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?

claunia commented

@vRITHNER commented on GitHub (Jun 24, 2019):

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

@vRITHNER commented on GitHub (Jun 24, 2019): Hi, I have the same issue and my graphic card is a NVIDIA GeForce GTX 1060

claunia commented

@MrR0bert commented on GitHub (Jun 25, 2019):

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.

@MrR0bert commented on GitHub (Jun 25, 2019): 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.

claunia commented

@vRITHNER commented on GitHub (Jun 25, 2019):

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

@vRITHNER commented on GitHub (Jun 25, 2019): Thanks for the tip. May I ask you how you did that ?

claunia commented

@Byloth commented on GitHub (Jun 25, 2019):

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

@Byloth commented on GitHub (Jun 25, 2019): > 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! 😅 ![image](https://user-images.githubusercontent.com/14953974/60086068-b90c5000-973a-11e9-8368-ce621e97fe10.png) > 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 ```

claunia commented

@MrR0bert commented on GitHub (Jun 25, 2019):

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 :)):

@MrR0bert commented on GitHub (Jun 25, 2019): > > > 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 :)): ![afbeelding](https://user-images.githubusercontent.com/20636874/60087344-215c3100-973d-11e9-8ac2-a563ed9819a2.png)

claunia commented

@8thHalfHour commented on GitHub (Jun 25, 2019):

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.

@8thHalfHour commented on GitHub (Jun 25, 2019): 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.

claunia commented

@miniksa commented on GitHub (Jun 25, 2019):

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 commented on GitHub (Jun 25, 2019): 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.

claunia commented

@ShadowEO commented on GitHub (Jun 25, 2019):

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

@ShadowEO commented on GitHub (Jun 25, 2019): @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.

claunia commented

@cpbotha commented on GitHub (Jun 28, 2019):

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

@cpbotha commented on GitHub (Jun 28, 2019): 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.)

claunia commented

WindowsTerminal.exe.12900.zip

@cpbotha commented on GitHub (Jun 28, 2019):

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

@cpbotha commented on GitHub (Jun 28, 2019): @miniksa here is a crash dump of the #1436 PR Azure Pipelines build crashing. [WindowsTerminal.exe.12900.zip](https://github.com/microsoft/terminal/files/3338327/WindowsTerminal.exe.12900.zip)

claunia commented

@DHowett-MSFT commented on GitHub (Jun 28, 2019):

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

@DHowett-MSFT commented on GitHub (Jun 28, 2019): 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:

claunia commented

@miniksa commented on GitHub (Jun 28, 2019):

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

@miniksa commented on GitHub (Jun 28, 2019): > @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.

claunia commented

@ShadowEO commented on GitHub (Jun 28, 2019):

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!)

@ShadowEO commented on GitHub (Jun 28, 2019): > 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!)

claunia commented

@Byloth commented on GitHub (Jul 1, 2019):

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

@Byloth commented on GitHub (Jul 1, 2019): > [...] 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](https://github.com/microsoft/terminal/files/3344460/Windows.Terminal.crash.zip)

claunia commented

@ShadowEO commented on GitHub (Jul 4, 2019):

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

@ShadowEO commented on GitHub (Jul 4, 2019): Saw the store version was updated recently. Let the affected PC update and am still experiencing the issue.

claunia commented

@metathinker commented on GitHub (Jul 4, 2019):

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

@metathinker commented on GitHub (Jul 4, 2019): 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

claunia commented

@DHowett-MSFT commented on GitHub (Jul 4, 2019):

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

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

@DHowett-MSFT commented on GitHub (Jul 4, 2019): 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.

claunia commented

@metathinker commented on GitHub (Jul 4, 2019):

@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: eae920e5f9

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?

@metathinker commented on GitHub (Jul 4, 2019): @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?

claunia commented

@DHowett-MSFT commented on GitHub (Jul 4, 2019):

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!

@DHowett-MSFT commented on GitHub (Jul 4, 2019): 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!

claunia commented

@DHowett-MSFT commented on GitHub (Jul 4, 2019):

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

@DHowett-MSFT commented on GitHub (Jul 4, 2019): 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:

claunia commented

@metathinker commented on GitHub (Jul 4, 2019):

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

@metathinker commented on GitHub (Jul 4, 2019): > 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!!!!](https://gist.github.com/metathinker/0b33595ee60a6a9fa303fc2d3c4b6945) 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()](https://docs.microsoft.com/en-us/uwp/api/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](https://github.com/microsoft/terminal/blob/eae920e5f931d7efd33cc3e1bfb12f8c683b001b/src/cascadia/TerminalApp/App.cpp#L144). 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`.

claunia commented

@DHowett-MSFT commented on GitHub (Jul 4, 2019):

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.

@DHowett-MSFT commented on GitHub (Jul 4, 2019): 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`.

claunia commented

@metathinker commented on GitHub (Jul 4, 2019):

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.

@metathinker commented on GitHub (Jul 4, 2019): > 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.

claunia commented

@oclockvn commented on GitHub (Jul 5, 2019):

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

@oclockvn commented on GitHub (Jul 5, 2019): I got this issue and after uncheck `Use legacy console` option, my terminal show up ![image](https://user-images.githubusercontent.com/3783976/60732611-b6003380-9f74-11e9-8fa6-63caa802b4b2.png)

claunia commented

@miniksa commented on GitHub (Jul 5, 2019):

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.

@miniksa commented on GitHub (Jul 5, 2019): > > > I got this issue and after uncheck `Use legacy console` option, my terminal show up > > ![image](https://user-images.githubusercontent.com/3783976/60732611-b6003380-9f74-11e9-8fa6-63caa802b4b2.png) This is probably different. I forked it to another issue.

claunia commented

@magiblot commented on GitHub (Jul 6, 2019):

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

Thanks, this was exactly my situation.

@magiblot commented on GitHub (Jul 6, 2019): > I got this issue and after uncheck `Use legacy console` option, my terminal show up Thanks, this was exactly my situation.

claunia commented

@corganfuzz commented on GitHub (Jul 6, 2019):

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

@corganfuzz commented on GitHub (Jul 6, 2019): I can confirm this works. My terminal shows up. However, the settings option is unresponsive after I select it.

claunia commented

@ShadowEO commented on GitHub (Jul 7, 2019):

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)

@ShadowEO commented on GitHub (Jul 7, 2019): 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)

claunia commented

@flcdrg commented on GitHub (Jul 8, 2019):

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 commented on GitHub (Jul 8, 2019): 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](https://github.com/dotnet/roslyn/wiki/Reporting-Visual-Studio-crashes-and-performance-issues) for WindowsTerminal.exe) and attached that to the report.

claunia commented

@flcdrg commented on GitHub (Jul 15, 2019):

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 😃

@flcdrg commented on GitHub (Jul 15, 2019): 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 😃

claunia commented

@miniksa commented on GitHub (Jul 15, 2019):

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.

@miniksa commented on GitHub (Jul 15, 2019): > 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.

claunia commented

@imaandrew commented on GitHub (Jul 15, 2019):

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.

@imaandrew commented on GitHub (Jul 15, 2019): > 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.

claunia commented

@ShadowEO commented on GitHub (Jul 16, 2019):

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

@ShadowEO commented on GitHub (Jul 16, 2019): Was hoping it would work in my case, but sadly not. Still receiving the problem on my x86 device after installing pwsh-core.

claunia commented

@tksunw commented on GitHub (Jul 19, 2019):

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
}

@tksunw commented on GitHub (Jul 19, 2019): 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 } ```

claunia commented

@cayv commented on GitHub (Jul 19, 2019):

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.

@cayv commented on GitHub (Jul 19, 2019): 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.

claunia commented

@tslytsly commented on GitHub (Jul 24, 2019):

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.

@tslytsly commented on GitHub (Jul 24, 2019): > 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](https://www.dell.com/en-us/shop/dell-universal-dock-d6000/apd/452-bcyt/pc-accessories). > > These kind of devices ([DisplayLink](https://www.displaylink.com/) 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.

claunia commented

@ShadowEO commented on GitHub (Jul 24, 2019):

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)

@ShadowEO commented on GitHub (Jul 24, 2019): 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)

claunia commented

@tslytsly commented on GitHub (Jul 25, 2019):

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 commented on GitHub (Jul 25, 2019): > 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?

claunia commented