Terminal: Terminal menunjukkan jendela kosong dan kemudian macet

Dari komentar lain tentang masalah yang sama,

jika Anda melihat layar kosong, pastikan Anda menargetkan arsitektur yang benar. Anda tidak dapat menjalankan terminal windows x86 pada mesin x64.

Memang, saya bisa membaca "dibangun dan digunakan untuk arsitektur x64" dan menemukan jawabannya.
Bisakah Anda membagikan build log?

Saya pikir Terminal sangat terkesan dengan gambar desktop Anda sehingga tidak ingin ditampilkan di atasnya.

FWIW, saya menerima perilaku yang sama di tablet x86 saya setelah menginstal versi MS Store . Salinan sebelumnya yang saya kompilasi berhasil, jadi saya masih menggaruk-garuk kepala tentang mengapa ini terjadi sekarang. Namun, saya belum menguji laptop x64 saya, jadi saya tidak yakin apakah di sana sama ..

Pembaruan: Setelah melihat penampil acara, saya menerima appcrash. Saya telah menarik acara ke evtx jika diperlukan.

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

Saya baru saja menginstal dari MS Store dan mengalami masalah yang sama. OS 64-bit di sini.

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

Saya ingin tahu apakah itu dapat dijalankan dari baris perintah dan melihat apakah itu mencetak pesan kesalahan.
EDIT: Tidak, tidak. ( wt.exe )

Jadi saya mencoba untuk membangunnya sendiri, dan saya menerima perilaku yang sama pada bangunan terbaru saya. Saya kebetulan mencoba versi x64 di laptop saya dan berfungsi dengan baik, tetapi x86 masih tidak berfungsi. Sayangnya tablet x86 saya tidak memiliki cukup penyimpanan untuk dapat menginstal VS ke dalamnya dan VS tidak akan membiarkan saya mengatur profil debugging jarak jauh untuk x86 (mengatakan Debug | x86 hilang dari manifest proyek ketika saya bahkan mencoba untuk membuka properti) jadi saat ini, upaya saya untuk memahami mengapa terhenti ...

Saya mungkin perlu menyiapkan VM x86 hanya untuk men-debug dengan: / dengan asumsi perilaku tersebut tetap ada di sana juga.

Sekarang saya hanya mencoba untuk mendapatkan salinan lama dari bangunan saya, supaya saya setidaknya dapat menggunakan Terminal baru, meskipun tidak up-to-date ..

Saya menghadapi masalah yang sama, jangan berpikir bahwa ada masalah kompatibilitas di sini

Baik...
Saya pikir saya menemukan mengapa ini terjadi ... 🤔

Beberapa menit yang lalu saya mencoba menjalankan lagi Terminal di PC saya untuk mencatat kesalahan apa pun untuk dilampirkan di sini ...
Yah ... Ini berjalan (dan itu bagus )! 🤩

"Begitu? Kenapa sekarang lari? Apa bedanya?"

Hari ini saya menggunakan notebook saya di kaki saya (tanpa perangkat apa pun yang terhubung).
Biasanya, saya menggunakan notebook saya yang terhubung ke Universal Dock ini .

Perangkat semacam ini (dok DisplayLink ) dilihat oleh OS sebagai kartu video eksternal tanpa dukungan tambahan untuk akselerasi perangkat keras ...
Faktanya, Anda tidak dapat menjalankan video game atau grafik 3D secara umum meskipun GPU Anda adalah yang terbaik yang dapat Anda beli!

Jadi, saya pikir, jika kartu video yang Anda coba untuk membuat Terminal tidak kompatibel dengan akselerasi perangkat keras (atau sesuatu seperti itu), itu, cukup, macet parah.

Bisa juga kasus Anda @ShadowEO , @magiblot dan @tanayagar?
Mungkin sesuatu seperti:

• Perangkat keras murah?
• Kartu video terintegrasi?
• Mesin virtual?
• ... dan seterusnya?

Saya memiliki masalah serupa. Setelah menginstal Terminal, pilih dropdown panel atas, lalu(sementara Widows Powershell dipilih secara otomatis), terminal memuat halaman kosong Visual Studio & crash.
Saya juga memiliki notebook (Lenovo W541) saya di stasiun dok dan saya menggunakan Win 10 Pro x64b, Nightly, vers 1903, OS Build 18922.1000

@Bayu_joo

Jadi, saya pikir, jika kartu video yang Anda coba untuk membuat Terminal tidak kompatibel dengan akselerasi perangkat keras (atau sesuatu seperti itu), itu, cukup, macet parah.

Bisa juga kasus Anda @ShadowEO , @magiblot dan @tanayagar?
Mungkin sesuatu seperti:

* Cheap hardware?

* Integrated video cards?

* Virtual machines?

* _... and so on?_

Ya, saya memang memiliki GPU Intel (HD Graphics 520) tetapi driver dan akselerasi harware sudah siap. Saya tidak menggunakan docking station atau VM, meskipun laptop ini saya sambungkan ke layar eksternal melalui VGA / DP. Tapi mencabutnya tidak mengubah apa pun.

Itu ide baru, tetapi build sebelumnya berfungsi dengan baik, misalnya, saya dapat menginstal ulang salah satu build developer lama saya dan itu terbuka dan berfungsi dengan baik.

Ya, saya menggunakan perangkat keras murah untuk perangkat ini, ini adalah TMAX TM101W635L. Menggunakan Intel HD Graphics (Saya tidak yakin dengan model yang tepat, karena saya jauh dari mesin.)

Mesin Virtual berfungsi dengan baik pada perangkat, tetapi tidak digunakan secara aktif (pada 2 GB RAM yang tidak dapat diperluas, Anda dapat melihat alasannya).

Pengujian saya semuanya dilakukan pada perangkat itu sendiri, jadi tidak ada stasiun dok, tidak ada perangkat keras eksternal sama sekali.

Saya berencana menyiapkan VM VS2019 32-bit di laptop utama saya malam ini untuk melihat apakah masalah terjadi di sana, dan jika demikian, untuk men-debugnya juga.

• Perangkat keras murah?
• Kartu video terintegrasi?
• Mesin virtual?
• _... dan seterusnya?_

i5-9600K, RTX-2070, RAM 32Gb, OS Host - jendela kosong dan macet.
Ke debug, mogok di sini:

WindowsTerminal.exe! Winrt :: get_activation_factory <: windows :: foundation :: iactivationfactory i = "14"> (const winrt :: param :: hstring & nama) Baris 5222 C ++
WindowsTerminal.exe! Winrt :: impl :: factory_cache_entry <: terminalapp :: app i = "16"> :: call <&> (winrt :: TerminalApp :: App ::& callback) Jalur 5420 C ++
WindowsTerminal.exe! Winrt :: impl :: call_factory <: terminalapp :: app i = "20">> (winrt :: TerminalApp :: App ::&& callback) Jalur 5501 C ++
WindowsTerminal.exe! Winrt :: TerminalApp :: App :: App () Baris 952 C ++
WindowsTerminal.exe! AppHost :: AppHost () Baris 30 C ++
WindowsTerminal.exe! WWinMain (HINSTANCE__ * __formal, HINSTANCE__ * __formal, wchar_t * __formal, int __formal) Baris 35 C ++

macet di sini, saya juga memiliki perangkat displaylink 4k, terhubung ke port displayport mini. dan mendapatkan kesalahan ini:

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

@Bayu_joo

Jadi, saya pikir, jika kartu video yang Anda coba untuk membuat Terminal tidak kompatibel dengan akselerasi perangkat keras (atau sesuatu seperti itu), itu, cukup, macet parah.
Bisa juga kasus Anda @ShadowEO , @magiblot dan @tanayagar?
Mungkin sesuatu seperti:

* Cheap hardware?

* Integrated video cards?

* Virtual machines?

* _... and so on?_

Ya, saya memang memiliki GPU Intel (HD Graphics 520) tetapi driver dan akselerasi harware sudah siap. Saya tidak menggunakan docking station atau VM, meskipun laptop ini saya sambungkan ke layar eksternal melalui VGA / DP. Tapi mencabutnya tidak mengubah apa pun.

Saya memiliki kartu Intel terintegrasi (Intel HD graphics 620). Sedangkan untuk perangkat keras dan vms murah, jawaban saya adalah tidak. Ada cara untuk memperbaikinya?

Hai, saya memiliki masalah yang sama dan kartu grafis saya adalah NVIDIA GeForce GTX 1060

Dalam kasus saya, saya dapat memperbaikinya dengan memaksa aplikasi untuk menggunakan kartu grafis Intel HD Graphics 630 alih-alih kartu GTX 1050 di panel kontrol NVIDIA.

Terima kasih atas tipnya. Bolehkah saya bertanya bagaimana Anda melakukannya?

Dalam kasus saya, saya dapat memperbaikinya dengan memaksa aplikasi untuk menggunakan kartu grafis Intel HD Graphics 630 alih-alih kartu GTX 1050 di panel kontrol NVIDIA.

Mmmh ... Aneh! 🤔
Saya mencobanya juga tetapi, sebenarnya, itu terus berjalan pada kartu video terintegrasi (bahkan jika saya memilih kartu video khusus).

Tapi, ya ... Mungkin, saya melakukan sesuatu yang salah! 😅

Saya menyeret Terminal di sekitar layar

Saya juga mencoba di komputer lain yang dilengkapi dengan NVidia GTX 970 dan berfungsi dengan baik.

Saya melakukan beberapa tes lain dan, untuk beberapa alasan, ketika saya menjalankan Terminal pada monitor eksternal yang terhubung melalui stasiun dok dalam keadaan crash (seperti yang saya katakan sebelumnya) ...
Tapi, jika saya menjalankannya di monitor internal (berfungsi dengan baik, tentu saja) dan kemudian saya menyeret jendela ke monitor eksternal, itu terus berjalan tanpa masalah. 😵

Ini event log saya (semoga bermanfaat):

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

Terima kasih atas tipnya. Bolehkah saya bertanya bagaimana Anda melakukannya?

Saya membuka Panel Kontrol NVIDIA, di bawah Kelola Pengaturan 3D pilih tab Pengaturan Program. Pada langkah pertama, Terminal Windows terdaftar sebagai "microsoft.windowsterminal_ [id]". Pada langkah kedua saya memilih grafik terintegrasi (maaf untuk keterampilan menggambar yang buruk :)):

Saya memiliki kartu NVIDIA GeForce GTX 1080 Ti di sini dengan Intel UHD 630 onboard, meskipun entah bagaimana, tiba-tiba, hari ini aplikasi tersebut berfungsi kembali. Saya tidak tahu mengapa atau bagaimana.

Dari siapa pun di utas ini, saya perlu dump kecelakaan. Saya mencoba mencari setiap ID Laporan yang Anda semua posting, dan tidak ada yang masuk.

Saya menduga bahwa masalah yang terkait dengan tidak dapat menggunakan rendering perangkat keras mungkin diselesaikan dengan # 1263.

Mungkin juga ada beberapa ketahanan untuk ditambahkan ke penyaji DX sehingga mengatur dirinya sendiri dengan benar. Jika ada di antara Anda yang membangun dari sumber, alangkah baiknya jika Anda memeriksa apakah conhost.exe yang dibuat dari sumber yang sama macet ketika kunci di HKCU\Console UseDx REG_DWORD 0x1 diset (buat jika tidak ada.) Itu akan mengkonfirmasi jika crash diisolasi ke DX renderer atau khusus startup Terminal.

Saya juga memiliki teori bahwa Anda semua mengalami 4 masalah yang berbeda di sini, jadi kami mungkin harus membaginya jika saya mencoba memperbaikinya dan tidak diperbaiki untuk Anda semua.

Terakhir, kami tidak memiliki akses ke perangkat keras jenis ini di sekitar sini. Saya akan melihat apa yang bisa kami lakukan, tetapi jika saya bisa mendapatkan bantuan dari dekat, itulah yang terbaik.

@miniksa Pasti! Bagaimana cara saya mendapatkan crash dump dari mesin yang terpengaruh?

Saya juga pergi ke stasiun pengembangan saya (x64) dan mencoba perubahan UseDx Anda minta. Saya dapat mengonfirmasi bahwa conhost gagal dimulai dengan UseDx disetel ke 0x1 pada mesin di mana build sumber yang sama berfungsi dengan baik. Mengalihkan UseDx mundur hasil di konsol yang berfungsi lagi.

Menariknya, saya melakukan tes ini pada tablet yang terpengaruh (sekali lagi dengan sumber yang sama), dan conhost berfungsi di kedua skenario di atasnya, saya mendapatkan prompt perintah seperti biasa .. namun Cascadia masih gagal.

Saya mencoba delapan dari Azure Pipelines master build dari sini: https://dev.azure.com/ms/Terminal/_build?definitionId=136&_a=summary untuk mencoba dan menentukan di mana hal-hal mulai rusak.

Dalam urutan kronologis terbalik, yaitu build terbaru terakhir:

• # 1374 tautan pembaruan ke pratinjau publik: KARYA
• # 1512 perbaiki punct readme: WORKS
• # 1452 tentang konten dialog yang dapat dipilih: KARYA
• # 1314 mengatur proyek startup default: JENDELA TETAP KOSONG
• # 1263 fallback swren: JENDELA TETAP KOSONG
• # 1093 menghubungkan clipboard func ke keybindings: WINDOW STAYS BLANK
• # 929 Menerapkan wilayah GDI ke jendela Pulau tingkat atas untuk memungkinkan menyeret dengan satu Pulau: KOSONG LALU CRASH
• # 1436 altgr: BLANK THEN CRASH

Dengan kata lain, antara penggabungan berikutnya dari # 1452 dan # 1314 (keduanya pada 2019-06-24) terminal beralih dari bekerja ke jendela kosong saat startup (tapi tidak ada kerusakan), dan kemudian antara penggabungan # 1093 dan # 929 berikutnya (keduanya pada 2019-06-25), terminal beralih dari jendela kosong tanpa tabrakan ke jendela kosong lalu macet.

(Bagaimana # 1314, yang tampaknya hanya pengurutan ulang dalam file solusi OpenConsole, dapat merusak terminal seperti ini sungguh mengejutkan. Namun, mencopot-menginstal ulang bangunan di sini hanya mengkonfirmasi status bekerja / tidak berfungsi.)

@miniksa berikut ini adalah crash dump dari build Azure Pipelines # 1436 PR yang mengalami crash.

WindowsTerminal.exe.12900.zip

Terima kasih telah melakukan dua hal yang kasar untuk kami!

Ini tidak terlihat aman _ sama sekali_.

.  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  

Saya sangat senang pipeline build kami berpegang pada simbol. :tersenyum:

@miniksa Michael Niksa FTE Pasti! Bagaimana cara saya mendapatkan crash dump dari mesin yang terpengaruh?

Saya juga pergi ke stasiun pengembangan saya (x64) dan mencoba perubahan UseDx Anda minta. Saya dapat mengonfirmasi bahwa conhost gagal dimulai dengan UseDx disetel ke 0x1 pada mesin di mana build sumber yang sama berfungsi dengan baik. Mengalihkan UseDx mundur hasil di konsol yang berfungsi lagi.

Menariknya, saya melakukan tes ini pada tablet yang terpengaruh (sekali lagi dengan sumber yang sama), dan conhost berfungsi di kedua skenario di atasnya, saya mendapatkan prompt perintah seperti biasa .. namun Cascadia masih gagal.

Secara teknis Anda dapat mengklik kanan proses di halaman Detail dari Task Manager dan membuat dump dan melampirkannya di suatu tempat secara online, tetapi berhati-hatilah, ini mungkin berisi informasi yang dapat diidentifikasi secara pribadi karena membuang seluruh ruang memori.

Anda juga dapat mencoba menggunakan Hub Umpan Balik dan memilih aplikasi Terminal Windows dan mengirimkannya dengan cara itu.

Atau jika macet, Anda dapat mencoba mendapatkan informasi Pelaporan Kesalahan Windows dari penampil acara dan memberikan semua itu kepada saya sehingga saya dapat mencoba mencari ID dengan layanan WER.

itu mungkin berisi informasi pengenal pribadi

Tidak apa-apa, tablet yang digunakan sangat ringan penggunaannya. Satu-satunya informasi yang dapat diidentifikasi pada perangkat mungkin adalah nama asli saya (yang baik-baik saja) atau direktori profil pengguna, yang hanya berisi sebagian dari nama pengguna Github saya.

Berikut adalah folder bersama OneDrive yang berisi file evtx (dengan peristiwa Pelaporan Kesalahan Windows dan peristiwa Kerusakan Aplikasi) dan untuk tindakan ekstra, proses dump untuk Anda! https://1drv.ms/u/s!AqACoL07fxpWoOIwO6InGCb8fvsZJg ? e = ot9XoI

Beri tahu saya jika Anda tidak bisa mendapatkannya, dan saya akan mengunggahnya di tempat lain, dump proses itu lebih besar dari yang saya harapkan untuk sesuatu yang hanya mengambil 5MB RAM pada saat itu lol.

(TIL saya dapat dengan mudah membuat proses dump, itu fitur yang keren!)

[...] jika macet, Anda dapat mencoba mendapatkan informasi Pelaporan Kesalahan Windows dari penampil acara dan memberikan semua itu kepada saya sehingga saya dapat mencoba mencari ID dengan layanan WER.

Berikut adalah ZIP dengan beberapa file yang diekstrak langsung dari Event Viewer ...
Saya harap ini yang kamu cari, @miniksa ... 😅

📦 Terminal Windows crash.zip

Melihat versi toko diperbarui baru-baru ini. Biarkan pembaruan PC yang terpengaruh dan saya masih mengalami masalah.

Kebetulan, saya juga mengalami masalah pada versi terbaru dari Terminal Windows yang mogok saat startup dengan jendela kosong - dan saya juga memiliki crash dump yang menarik! Saya juga mendapat jejak Debugging Perjalanan Waktu jika terbukti berguna.

Tautan - maaf, ini hanya untuk internal Microsoft karena kekhawatiran saya adalah informasi pribadi saya:
https://aka.ms/AA5ix7s

Hai @metathinker ,
Terima kasih telah berbagi tempat sampah ini! Saya tidak tahu untuk apa build WT ini memetakan, karena kami tidak menyimpan simbol build CI, dan ini terlihat seperti salah satunya. :tersenyum:

Saya akan mencoba dengan build CI terbaru.

@ DHowett-MSFT mungkin tersesat di file catatan yang saya tulis, tetapi ini:
https://dev.azure.com/ms/Terminal/_build/results?buildId=23399
membangun master saat ini: https://github.com/microsoft/Terminal/commit/eae920e5f931d7efd33cc3e1bfb12f8c683b001b

Jika saya membuat komit yang sama di kotak saya sendiri, masalah yang sama terjadi.

Dan sejauh yang saya tahu, Azure DevOps CI build _do_ memiliki simbol - ada file .msix dan .appxsym di artefak build, dan yang terakhir membuka ritsleting ke sekumpulan file .pdb. Atau bukankah itu simbol yang Anda cari?

Ya, tetapi kami tidak mengarsipkannya di mana pun _durable_ (seperti server simbol) karena build ini tidak dimaksudkan untuk digunakan. Saya akhirnya menggali simbol yang tepat untuk bangunan Anda. Di sinilah kita gagal:

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

Saya tidak percaya ini adalah masalah yang sama dengan # 1364, jadi saya akan membagi ini ke masalah lain. Terima kasih!

Ya, masalah Anda adalah bahwa MinMaxCloseControl tidak berakhir di tempat yang tepat (mungkin - mungkin dibantah oleh bukti) _hanya untuk CI builds_. Terima kasih pipa Xaml! :tersenyum:

Ya, masalah Anda adalah bahwa MinMaxCloseControl tidak berakhir di tempat yang tepat (mungkin - mungkin dibantah oleh bukti) _hanya untuk CI builds_. Terima kasih pipa Xaml! 😄

Yakin, kan? Sebaiknya buka masalah terpisah itu, karena mengklik tautan ini akan MENGEMBANGKAN PIKIRAN ANDA !!!!!! 111111 !!!!

Seperti yang saya katakan di atas, membangun https://github.com/microsoft/terminal/commit/eae920e5f931d7efd33cc3e1bfb12f8c683b001b di komputer saya sendiri dan menjalankan aplikasi debug build Terminal menghasilkan kerusakan yang sama seperti yang saya dapatkan dari rilis rilis Azure DevOps CI. Seperti dalam build rilis CI, penyebab terdekat masalahnya adalah ms-appx:///MinMaxCloseControl.xaml tidak ditemukan selama panggilan ke Windows.UI.Xaml.Application.LoadComponent () . Panggilan itu pada gilirannya berasal dari kode yang dihasilkan C ++ / WinRT yang dimulai dengan panggilan ini dari winrt :: TerminalApp :: implementasi :: App :: _ Create () ke konstruktor yang dibuat untuk winrt :: TerminalApp :: MinMaxCloseControl .

Sekarang saya berasumsi ada sesuatu yang aneh sedang terjadi di Azure DevOps CI build dan build di kotak saya sendiri. Entah itu, atau saya bisa saja menerapkan aplikasi secara tidak benar - saya mengekstrak CI build .appx / .msix atau menemukan folder file lepas yang saya buat secara pribadi yang sudah memiliki AppXManifest.xml di dalamnya, dan kemudian menjalankan powershell.exe -command Add-AppXPackage -Register X:\wherever\it\is\AppXManifest.xml .

Sekarang, apakah Anda membangun dengan MSBuild atau dengan VS? Saya dapat mereproduksi tata letak paket yang rusak dengan MSBuild tetapi tidak dengan Visual Studio.

Di mesin saya, ketika VS membangun proyek, itu akhirnya meletakkan salinan MinMaxCloseControl.xbf di root paket appx, di mana pencari sumber daya menyarankannya. Salinan juga berakhir dengan TerminalApp.pri . Appx yang Anda tarik dari CI dan appx _layout_ yang Anda buat di mesin Anda mungkin tidak memiliki salinan pertama ( .xbf ) dan hanya memiliki salinan kedua (diverifikasi dalam .msix dari artefak CI.)

Mungkin ada beberapa masalah di sini. Satu, saya tidak tahu mengapa itu disalin oleh VS tetapi tidak MSBuild; Kedua, Ini harus digulung menjadi resources.pri dengan sumber daya Xaml lainnya; Tiga, saya tidak tahu mengapa ini berfungsi dengan baik untuk App.xbf sangat mirip.

Sekarang, apakah Anda membangun dengan MSBuild atau dengan VS? Saya dapat mereproduksi tata letak paket yang rusak dengan MSBuild tetapi tidak dengan Visual Studio.

MSBuild - yah, tepatnya, saya melakukan ini: cd/d [repo root] & .\tools\razzle.cmd dbg & bcz dbg
dan file batch bcz.cmd menjalankan MSBuild seperti yang Anda ketahui.

Aplikasi kemudian lumpuh saat saya menyebarkan folder file longgar melalui PowerShell atau Visual Studio.

Saya dapat memverifikasi bahwa setelah membakar repo dengan git clean -dxf , membuka solusi di Visual Studio, dan membangun, aplikasi yang dihasilkan berjalan dengan baik. Folder file lepas dengan AppXManifest.xml juga memiliki App.xbf dan MinMaxCloseControl.xbf ; keduanya hilang dari MSBuild build saya dan AzDO CI build.

Mungkin kita benar-benar perlu mengatasi masalah terpisah itu sekarang - ini adalah masalah yang sangat buruk menurut saya, tapi mungkin bukan masalah yang awalnya dibahas.

Saya mendapat masalah ini dan setelah hapus centang Use legacy console opsi, terminal saya muncul

Saya mendapat masalah ini dan setelah hapus centang Use legacy console opsi, terminal saya muncul

Ini mungkin berbeda. Saya memindahkannya ke masalah lain.

Saya mendapat masalah ini dan setelah hapus centang Use legacy console opsi, terminal saya muncul

Terima kasih, inilah situasi saya.

Saya dapat mengonfirmasi bahwa ini berfungsi. Terminal saya muncul. Namun, opsi pengaturan tidak responsif setelah saya memilihnya.

Seperti yang dikatakan @miniksa , itu mungkin masalah yang terpisah. Mesin saya tidak mengaktifkan fitur "Gunakan konsol lama", dan fitur itu tidak berfungsi bahkan jika fitur tersebut aktif.

Tampaknya ada banyak faktor yang menyebabkan respons khusus ini.

Yang mengatakan, saya memperbarui Terminal ke versi terbaru di toko dan bahkan tidak lagi gagal sampai titik ini, terbuka, menunjukkan bilah judul / batas (seperti perilaku sebelumnya) dan kemudian macet sebelum jendela selesai rendering. (Tidak seperti sebelumnya, bilah judul dan batas jendela UWP dihancurkan)

Saya telah mengirimkan masalah menggunakan Hub Umpan Balik - https://aka.ms/AA5jk66

Meskipun saya memiliki Terminal Windows (Pratinjau) yang terdaftar di Pengaturan | Aplikasi, tidak muncul dalam daftar Aplikasi di Hub Umpan Balik, jadi saya hanya perlu memilih "Semua aplikasi lain".

Saya juga membuat crash dump (menerapkan pengaturan yang sama seperti yang didokumentasikan di sini untuk WindowsTerminal.exe) dan melampirkannya ke laporan.

Saya tidak menginstal PowerShell Core di mesin yang menunjukkan kerusakan ini (tetapi di perangkat lain, Terminal dimulai tanpa kesalahan dan memang memiliki PowerShell Core).

Karena penasaran, saya menginstal Core pada mesin yang rusak, dan sekarang Terminal dimulai dengan benar!

choco install powershell-core FTW 😃

Saya tidak menginstal PowerShell Core di mesin yang menunjukkan kerusakan ini (tetapi di perangkat lain, Terminal dimulai tanpa kesalahan dan memang memiliki PowerShell Core).

Karena penasaran, saya menginstal Core pada mesin yang rusak, dan sekarang Terminal dimulai dengan benar!

choco install powershell-core FTW 😃

Oke, terima kasih untuk poin datanya. Di bagian belakang, error ini berakhir dengan masalah besar yang sama, jadi sulit bagi saya untuk memisahkan skenario yang berbeda di sini. Setiap laporan seperti ini membantu saya mengidentifikasi kasus lain dengan lebih mudah daripada mengobrak-abrik tumpukan dump.

Saya tidak menginstal PowerShell Core di mesin yang menunjukkan kerusakan ini (tetapi di perangkat lain, Terminal dimulai tanpa kesalahan dan memang memiliki PowerShell Core).

Karena penasaran, saya menginstal Core pada mesin yang rusak, dan sekarang Terminal dimulai dengan benar!

choco install powershell-core FTW 😃

Saya dapat mengonfirmasi, saya memiliki masalah dan menginstal inti PowerShell menyelesaikannya.

Berharap itu akan berhasil dalam kasus saya, tetapi sayangnya tidak. Masih menerima masalah pada perangkat x86 saya setelah menginstal pwsh-core.

Saya memiliki masalah yang sama pada 2 dari 4 komputer.

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

Kedua komputer memiliki masalah yang memiliki PowerShell-core (6) pada mereka, dan salah satunya juga memiliki pratinjau PowerShell 7. Default profiles.json tidak menyertakan entri untuk itu, dan tampaknya membuat wt.exe tidak bahagia. Masalahnya juga tampaknya muncul kembali secara berkala, mungkin saat pembaruan diterapkan secara otomatis.

Saya telah menemukan bahwa menghapus profiles.json sekaligus memperbaiki masalah, dan Terminal Windows akan membuat file profiles.json yang menyertakan entri untuk versi tambahan PowerShell.

Saya menambahkan sedikit fungsi ke PowerShell profile.ps1 yang memungkinkan saya untuk mengatur ulang, dan itu selalu memperbaiki masalah peluncuran di kedua komputer yang bermasalah.

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

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

Saya mengalami masalah yang sama sekarang setelah menginstal Terminal melalui Store untuk pertama kalinya di Surface Book saya dengan dGPU. Saya baru saja memperbarui Windows ke 1903 dan menginstal PowerShell Core menggunakan Scoop. Setelah menghapus file profiles.json seperti yang dikatakan @tksunw , itu berfungsi. Saya tidak mengalami masalah ini saat melakukan hal yang sama dengan desktop saya beberapa minggu yang lalu.

Baik...
Saya pikir saya menemukan mengapa ini terjadi ... 🤔

Beberapa menit yang lalu saya mencoba menjalankan lagi Terminal di PC saya untuk mencatat kesalahan apa pun untuk dilampirkan di sini ...
Yah ... Ini berjalan (dan itu bagus )! 🤩

"Begitu? Kenapa sekarang lari? Apa bedanya?"

Hari ini saya menggunakan notebook saya di kaki saya (tanpa perangkat apa pun yang terhubung).
Biasanya, saya menggunakan notebook saya yang terhubung ke Universal Dock ini .

Perangkat semacam ini (dok DisplayLink ) dilihat oleh OS sebagai kartu video eksternal tanpa dukungan tambahan untuk akselerasi perangkat keras ...
Faktanya, Anda tidak dapat menjalankan video game atau grafik 3D secara umum meskipun GPU Anda adalah yang terbaik yang dapat Anda beli!

Jadi, saya pikir, jika kartu video yang Anda coba untuk membuat Terminal tidak kompatibel dengan akselerasi perangkat keras (atau sesuatu seperti itu), itu, cukup, macet parah.

Bisa juga kasus Anda @ShadowEO , @magiblot dan @tanayagar?
Mungkin sesuatu seperti:

• Perangkat keras murah?
• Kartu video terintegrasi?
• Mesin virtual?
• _... dan seterusnya?_

Saya mengalami masalah yang sama.
Saya memiliki dok Dell USB 3 Displaylink.
Jika saya mencoba untuk memulai wt.exe saat terhubung itu tidak akan berjalan, 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

Tetapi, jika saya melepaskan Dock, itu akan berjalan pada grafis terintegrasi laptop saya.

Saya memiliki driver terbaru.

Tidak ada dok, seperti yang dinyatakan dalam tanggapan saya sebelumnya kepada orang lain yang menyarankan hal yang sama, bangunan sebelumnya berjalan dengan sempurna, bangunan toko dan bangunan pohon saat ini tidak.

Intel HD Graphics, semua internal. Tidak ada VM, menjalankan Windows 10 Pro Terbaru lewati.
Tablet TMAX TM101W638L. (Sekali lagi, build sebelumnya berjalan dengan sempurna, jadi sepertinya tidak ada masalah dengan grafisnya, dan conhost DxRenderer juga berfungsi dengan baik)

Tidak ada dok, seperti yang dinyatakan dalam tanggapan saya sebelumnya kepada orang lain yang menyarankan hal yang sama, bangunan sebelumnya berjalan dengan sempurna, bangunan toko dan bangunan pohon saat ini tidak.

Intel HD Graphics, semua internal. Tidak ada VM, menjalankan Windows 10 Pro Terbaru lewati.
Tablet TMAX TM101W638L. (Sekali lagi, build sebelumnya berjalan dengan sempurna, jadi sepertinya tidak ada masalah dengan grafisnya, dan conhost DxRenderer juga berfungsi dengan baik)

Maaf, saya tidak mencoba menyarankan bahwa solusinya adalah memutuskan sambungan Dock jika Anda memilikinya. :)

Meskipun, saya juga memiliki grafik Intel HD, mungkinkah ada hubungannya dengan itu?
Pemicu berbeda?

Hai,

Sekali lagi, tidak mengatakan ini adalah alasan / perbaikan untuk semua orang, tetapi saya pikir saya menemukan akar masalah di PC saya.

Saya mengintegrasikan grafis Intel HD ditambah kartu grafis AMD Radeon 530 di laptop saya.
Saya pikir pembaruan driver baru-baru ini telah menyebabkan semacam masalah.

Ini mungkin tidak terbatas pada grafik AMD, tetapi saya telah menemukan bahwa ketika Dock saya terhubung dan saya menggunakan Displaylink, laptop lebih memilih untuk menjalankan sebagian besar program menggunakan 530 GPU rahasia.
Jika demikian, Terminal Windows dan mstsc.exe keduanya macet saat dimulai.
Ketika saya memeriksa AppCrashView, kedua crash melibatkan dll dengan crt dalam nama, ucrtbase.dll untuk Terminal dan msvcrt.dll untuk mstsc.exe.

Sekarang saya telah menemukan cara untuk memberi tahu Windows agar tidak menggunakan Radeon 530 untuk mstsc.exe dan wt.exe. Kedua program sekarang berjalan dengan baik.

Jadi saya pikir driver grafis dan / atau pembaruan Windows baru-baru ini telah menyebabkan masalah dengan driver grafis.

Percakapan ini sekarang dikunci karena orang-orang menggunakannya sebagai tempat pembuangan untuk setiap crash saat memulai.

Saya telah mengidentifikasi banyak masalah di utas ini:

• Meluncurkan dengan Legacy Console dipilih
  
  
  
  • Ini diperbaiki pada # 1935
  
  
• Meluncurkan dengan font yang tidak valid
  
  
  
  • Ini diperbaiki di # 2153
  
  
• Meluncurkan tanpa Powershell Core 6
  
  
  
  • Ini adalah # 1348 dan # 1458 dan # 982
  
  
• Peluncuran dengan Powershell Core 7
  
  
  
  • Skenario seperti yang dijelaskan dalam # 1399 adalah hal yang sama yang akan ditangani oleh # 982
  
  
• Meluncurkan di perangkat portabel yang menggunakan GPU yang dapat dialihkan atau GPU dok eksternal
  
  
  
  • @ DHowett-MSFT memiliki Surface Book dengan GPU yang dapat dialihkan dan belum pernah melihat ini. Saya benar-benar percaya itu adalah masalah dan bahkan mungkin kesalahan penanganan dalam perender DirectX, tetapi kita harus mengekstrak masalah ini ke masalah lain DAN kita perlu membuat seseorang merasa nyaman dengan debugging ini yang memiliki perangkat keras ini.
  
  
  • Ini sekarang dipindahkan ke # 2183
  
  
• MinMaxControl belum stabil
  
  
  
  • Ini lebih stabil sekarang. Ini seharusnya baik-baik saja.
  
  
• Saya menggunakan arsitektur yang salah untuk mesin saya
  
  
  
  • # 1648 menghalangi Anda melakukan ini sekarang
  
  

Saya akan mengedit ini dengan resolusi. Tapi tidak ada lagi yang bertumpuk di sini. Jika Anda memiliki salah satu dari 7 hal ini, ikuti utas individu atau tunggu pembaruan jika sudah diperbaiki.

Perhatikan, saya tidak mengatakan jangan laporkan sesuatu. Saya hanya perlu memecah ini menjadi utas individu karena terlalu banyak untuk menangani semua di satu tempat. Mari kita pecahkan percakapan menjadi utas yang berkorelasi.

BAIK. Semua masalah di atas yang diisolasi dari berbagai diskusi di utas ini tampaknya memiliki nomor ID lanjutan (kecuali MinMaxControl yang hanya disebutkan sekali saat masih baru). Harap arahkan percakapan tentang masalah "jendela kosong dan kerusakan" yang sedang berlangsung ke utas spesifik tersebut jika relevan bagi Anda.

Jika tidak relevan, buka bug baru dan jelaskan bagaimana milik Anda berbeda dari yang di atas. Terima kasih!