Ini mungkin terkait dengan VS Code atau ekstensi PowerShell pada VS Code. Setelah me-reboot sistem saya, saya dapat segera membuka PowerShell tanpa masalah. Dengan VS Code terbuka, sesi non-administratif PowerShell menolak untuk tetap terbuka. Bahkan setelah menutup VS Code, PowerShell tampaknya menolak membuka dengan andal.

Anda dapat menjalankan PowerShell Core dari cmd.exe dan melihat pesan kesalahan.

Ketika saya mencoba membuka PWSH dari CMD saat diminta, PowerShell mulai dengan baik. Bahkan dengan sesi PowerShell itu terbuka, mencoba membukanya dari ikon bilah tugas menyebabkannya tidak terbuka. Saya juga mencoba mengetik PWSH di bilah alamat Explorer dan mendapatkan hasil tanpa buka yang sama.

Dengan tidak membuka, inilah yang terjadi. Sebuah jendela muncul, dan memiliki info header:
``
PowerShell 6.2.0
Hak Cipta (c) Microsoft Corporation. Seluruh hak cipta.

https://aka.ms/pscore6-docs
Ketik 'bantuan' untuk mendapatkan bantuan.
`` ''
Prompt perintah tidak pernah muncul, dan setelah penundaan singkat, jendela ditutup.

Jika saya meninggalkan sistem untuk sementara waktu (menit, mungkin 10 menit, tetapi saya terus melakukan tugas lain pada sistem) maka membuka PowerShell berfungsi dengan baik. Saya sudah bisa mengulangi polanya. Setelah PowerShell terbuka dengan baik, saya menutup VS Code (jika bahkan terbuka), tunggu sebentar, buka kembali VS Code, tunggu sebentar (mungkin sebentar) dan kemudian PowerShell gagal membuka lagi, dan ini tetap lagi untuk beberapa periode waktu .

Saya mencoba mengulangi semua ini pada mesin orang dalam 19H1 saya tadi malam, dan itu tidak akan terulang setelah pertama kali. Pertama kali membuka PowerShell gagal, tetapi setiap kali berhasil, bahkan setelah reboot.

Saat saya mencoba membuka PWSH dari CMD saat diminta,

Selalu?

Jika Anda membuka direktori utama PowerShell Core dan mengklik dua kali pada pwsh.exe - apakah itu dimulai dengan baik kapan saja?

Saat saya mencoba membuka PWSH dari CMD saat diminta,

Selalu?

Sejauh ini. Saya akan mencoba jendela PWSH, itu akan gagal, saya akan membuka CMD, ketik PWSH, mulai dengan baik, coba jendela PWSH lain, itu akan gagal. KELUAR dari instance CMD PWSH dan coba lagi, itu akan terbuka kembali dengan baik. Saya akan terus mengulang, menutup jendela CMD sepenuhnya, memulai dari awal, masih PWSH pada prompt CMD tampaknya selalu berfungsi.

Juga, saya tidak akan sepenuhnya bersumpah, bahwa bahkan setelah jendela PWSH berhasil dibuka, mencoba lagi beberapa menit kemudian dan tidak akan terbuka lagi, tanpa alasan tertentu yang sejauh ini dapat saya simpulkan.

Jika Anda membuka direktori utama PowerShell Core dan mengklik dua kali pada pwsh.exe - apakah itu dimulai dengan baik kapan saja?

Sepertinya kondisi tanpa-terbuka yang sama. Ini aneh meskipun, karena langsung mengklik file EXE tampaknya menghasilkan kondisi tidak terbuka yang sama hampir sepanjang waktu, tetapi mengklik pintasan yang disimpan di folder menu mulai tampak lebih sporadis, sering kali berhasil dibuka, tetapi jelas tidak selalu .

OS Windows menyimpan parameter jendela untuk setiap aplikasi (konsol). Tampaknya parameter rusak dan kita perlu membersihkannya dari registri.

Saya mengalami ini juga. Jika membantu, berikut ini muncul di Event Viewer:

Source: .NET Runtime
Application: pwsh.exe
CoreCLR Version: 4.6.27317.3
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FF93A6B298E (00007FF93A6B0000) with exit code 80131506.

Source: Application Error
Faulting application name: pwsh.exe, version: 6.2.0.0, time stamp: 0x5c410542
Faulting module name: coreclr.dll, version: 4.6.27317.3, time stamp: 0x5c40be0f
Exception code: 0xc0000005
Fault offset: 0x000000000000298e
Faulting process id: 0x4f48
Faulting application start time: 0x01d4f30cd62ddac2
Faulting application path: C:\Program Files\PowerShell\6\pwsh.exe
Faulting module path: C:\Program Files\PowerShell\6\coreclr.dll
Report Id: 532d875c-683f-4640-bf93-310d5de00cb4
Faulting package full name: 
Faulting package-relative application ID: 

Sama seperti @cpmcgrath , saya dapat mengonfirmasi bahwa saya melihat hal yang sama di log peristiwa aplikasi segera setelah gagal meluncurkan:
(2 acara)

Application: pwsh.exe
CoreCLR Version: 4.6.27317.3
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFFDDAB298E (00007FFFDDAB0000) with exit code 80131506.

Faulting application name: pwsh.exe, version: 6.2.0.0, time stamp: 0x5c410542
Faulting module name: coreclr.dll, version: 4.6.27317.3, time stamp: 0x5c40be0f
Exception code: 0xc0000005
Fault offset: 0x000000000000298e
Faulting process id: 0xc60
Faulting application start time: 0x01d4f3a7d85fc982
Faulting application path: C:\Program Files\PowerShell\6\pwsh.exe
Faulting module path: C:\Program Files\PowerShell\6\coreclr.dll
Report Id: 2d4862a8-7e13-4eeb-8d60-4ec7e2e74f30
Faulting package full name: 
Faulting package-relative application ID: 

Saya masih melihat ini terkait dengan membuka Kode VS dengan Ekstensi Pratinjau PowerShell, tetapi saya kira aplikasi lain yang menggunakan .Net dapat mengatur kondisi ini juga.

@msftrncs Bisakah Anda mengkompilasi dan menjalankan debug build untuk mendapatkan info lebih lanjut? Juga akan menyenangkan mendapatkan langkah repo dari Anda sehingga kami dapat mereproduksi masalah pada sistem yang bersih.

Saya mengalami masalah yang sama.

Sumber: Kesalahan Aplikasi

Faulting application name: pwsh.exe, version: 6.2.0.0, time stamp: 0x5c410542
Faulting module name: coreclr.dll, version: 4.6.27317.3, time stamp: 0x5c40be0f
Exception code: 0xc0000005
Fault offset: 0x000000000000298e
Faulting process id: 0x4e64
Faulting application start time: 0x01d520380945a490
Faulting application path: C:\Program Files\PowerShell\6\pwsh.exe
Faulting module path: C:\Program Files\PowerShell\6\coreclr.dll
Report Id: 0fe828fd-a45e-4dc2-b7f0-77b07ecdba93
Faulting package full name: 
Faulting package-relative application ID: 

Sumber: .NET Runtime

Application: pwsh.exe
CoreCLR Version: 4.6.27317.3
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFC0240298E (00007FFC02400000) with exit code 80131506.

Saya telah melampirkan informasi yang dikumpulkan oleh Pelaporan Kesalahan Windows.
Report.zip

Pengamatan:

• Saya menjalankan Windows v1903 (OS Build 18362.30)
• Saya memiliki Visual Studio Code diinstal (v1.35.0) dengan ekstensi Powershell (v2019.5.0)
• Tampaknya terjadi setelah reboot
• Waktu muat profil sepertinya memakan waktu cukup lama
• Terkadang terjadi dalam mode Administrasi, dan terkadang tidak
• Saya memasang modul postgit sebagai bagian dari profil saya, yang didefinisikan di bawah ini:

Import-Module posh-git

# Customise the Prompt
$GitPromptSettings.DefaultPromptPrefix.Text = '$((Get-Date).ToShortTimeString()) ';
$GitPromptSettings.DefaultPromptPrefix.ForegroundColor = [ConsoleColor]::Magenta;
#$GitPromptSettings.DefaultPromptSuffix.Text = ' $(GitVersionForCurrentRepoPrefixed)`r`nλ ';
$GitPromptSettings.DefaultPromptSuffix.Text = '`r`nλ ';

@Antaris Terima kasih! Apakah repo Anda gigih? Bisakah Anda melakukan repo dengan build PowerShell Core terbaru?

Itu tidak persisten, lebih terputus-putus. Saya akan mencoba dan mengunduh versi terbaru dan melihat apakah itu memperbaikinya.

@Antaris Jika Anda dapat melakukan fork repo dan build - dengan mode debug, Anda dapat memperoleh informasi lebih lanjut dalam pengecualian.

@ SteveL-MSFT Haruskah kita khawatir tentang versi 6.2?

Dilihat dari nama modul kesalahan saya merasa bahwa masalah NET. Hal serupa terjadi sebelumnya.
Sementara itu, berikut adalah cara sederhana untuk membuang proses mogok dengan semua detail yang akan sangat membantu untuk menyelidiki dan memperbaikinya. @Antaris - Anda dapat mencoba utilitas ProcDump :

Register as the Just-in-Time (AeDebug) debugger. Makes full dumps in c:\dumps.
C:\>procdump -ma -i c:\dumps

Saat PS crash berikutnya, dump dengan info kesalahan rinci akan ditulis ke folder yang ditentukan.

@anaga

Saya berhasil memicu pengalaman ini pagi ini. Laptop saya baru dinyalakan kembali. Pertama kali saya membuka PowerShell Core, tidak apa-apa. Saya kemudian menggunakan Visual Studio Code untuk membaca profil PS Core saya, dan memulai save _tanpa membuat perubahan_. Saya kemudian membuka PowerShell Core dan segera ditutup.

File dump ada di sini:
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov Maaf, saya belum punya waktu untuk menguji ini terhadap komitmen saat ini, saya akan mencoba dan menyelesaikannya minggu ini

Sepertinya pelanggaran Akses berasal dari kurang dari TaskbarJumpList.CreateElevatedEntry .
@bergmeister , apakah Anda ingat ada masalah stabilitas dengan fungsi ini?

ExceptionAddress: 00007fff471f298e (coreclr!InteropSyncBlockInfo::GetRCWAndIncrementUseCount+0x000000000000000a)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000001
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000018
Attempt to read from address 0000000000000018

Partial stack:
coreclr!InteropSyncBlockInfo::GetRCWAndIncrementUseCount+0xa
coreclr!RCWHolder::Init+0x16
coreclr!ComObject::SupportsInterface+0x101
coreclr!ObjIsInstanceOf+0x482
coreclr!JITutil_ChkCastAny+0x95
coreclr!JITutil_ChkCastInterface+0x2e
Microsoft_PowerShell_ConsoleHost!Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry(System.String)+0x386
Microsoft_PowerShell_ConsoleHost!Microsoft.PowerShell.ConsoleHost+<>c.<Start>b__4_0()+0x14

Itu akan menjelaskan mengapa ini tidak terjadi jika saya meluncurkan pwsh dari baris perintah.

Kami telah melihat laporan kegagalan sporadis sebelumnya dan orang lain mencoba untuk meningkatkan panggilan COM. Dalam hal ini saya agak curiga bahwa Windows Insider build 19H1 yang digunakan mungkin juga penyebabnya.
Saya mem-porting kode C ++ asli dari Windows PowerShell ke C # menggunakan panggilan COM yang sama dan menggunakan kode sumber paket Windows Api untuk definisi antarmuka COM.
Kabar baiknya adalah kode ini hanya berjalan ketika pwsh dimulai secara interaktif dan registrasi menu jumplist hanya perlu dilakukan sekali (ada kode yang memeriksa secara implisit). Mungkin kita harus mencoba {} menangkap blok di sekitarnya dan hanya keluar dari jejak tumpukan kegagalan?
Secara umum, ketika saya melakukannya, saya harus mem-port kode .Net lengkap dari Paket Windows Api ke .Net Core dan men-tweaknya untuk memungkinkan entri jumpstart dengan ketinggian. 2 minggu yang lalu, WPF menambahkan kode sumber untuk JumpList dan dengan PR untuk memungkinkan jumplist yang ditinggikan, kami dapat menunda banyak pekerjaan menjadi hanya beberapa baris, tetapi pada akhirnya saya pikir ini adalah masalah .Net Core.

@bergmeister apakah Anda bersedia melakukan pekerjaan ini? Silahkan :)

Saya dapat mencoba, WPF API akan membutuhkan sesuatu seperti parameter boolean yang ditambahkan (default ke false) untuk membuat entri jumplist membuka aplikasi dalam mode tinggi. Ini akan tergantung pada seberapa fleksibel orang-orang WPF dalam hal bersedia menerima perubahan API dan seberapa sulit untuk menggabungkan PR tetapi saya pikir itu akan berpacu dengan waktu karena .Net Core 3 ingin menerbitkan RC sekitar bulan Juli (artinya mereka cenderung tidak menerima perubahan seperti itu setelah waktu itu) ....
Jika tidak, satu-satunya alternatif adalah mencoba menangkap kesalahan (tetapi bagi saya ini tampak seperti kesalahan CLR yang fatal dan tidak tertandingi).
Saya sendiri sayangnya tidak pernah mengalami kesalahan seperti itu

Sepertinya kondisi balapan di GUI.

@ SteveL-MSFT Tidak jelas tentang versi 6.2 - haruskah kita memperbaikinya juga?

Tanpa data apa pun untuk mencadangkan pernyataan saya berikutnya, tampaknya masalah ini hampir tidak pernah terjadi jika saya membuka PowerShell dengan 'Run as Administrator'

@jlouros Saya telah mengalami keduanya berjalan non-elevasi, dan berjalan sebagai Adminstrator

Apakah ini juga terjadi untuk PS 7-preview1? .Net Core 3 telah meningkatkan interaksi COM, mungkin masalah .Net Core 2.1.
Juga: Mungkinkah perbaikan serupa dengan kode yang mirip dengan PR # 7580 juga dapat membantu?

@bergmeister , Saya telah mengalaminya dengan 7 pratinjau juga, tetapi lebih jarang. Pratinjau 7 tampaknya memberikan dump kesalahan CLR, tetapi menutup begitu cepat ... tapi saya mengerti:

Saya juga tidak mengalami ini hampir sebanyak saat menjalankan 'sebagai administrator', seperti yang disebutkan @jlouros , tetapi seperti yang dikatakan @Antaris , hal itu masih terjadi secara kebetulan.

Kita bisa mendapatkan lebih banyak informasi dengan debug build (kita mengabaikan kesalahan dalam rilis build dalam kode!)

@ SteveL-MSFT Saya membuka proposal API di WPF untuk mendapatkan persetujuan terlebih dahulu (perubahan yang diusulkan tidak melanggar, jadi seharusnya OK) dan menyertakan beberapa detail implementasi tingkat rendah. Saya belum melihat kode WPF itu sendiri secara detail tetapi seharusnya tidak terlalu sulit (bagian tersulit mungkin adalah pengujiannya)
https://github.com/dotnet/wpf/issues/950
Ini akan menjadi cara maju untuk PowerShell 7, ketika saya mulai membaca kode WPF secara lebih rinci, saya akan mencoba membandingkannya dengan implementasi saya dan melihat apakah saya dapat meningkatkan panggilan COM, saya bertanya-tanya apakah ini adalah masalah dari AppartmentState menjadi MTA karena pada dasarnya saya menerjemahkan kode C ++ Windows PowerShell ke C # dan menggunakan definisi antarmuka dari Windows API saat saya pertama kali melakukan implementasi

@bergmeister Saya pikir untuk saat ini, mungkin solusi sementara adalah membungkusnya dalam percobaan ... menangkap sehingga pwsh setidaknya dimulai. Kami dapat mengambil perbaikan itu ke layanan 6.2.x. Perbaikan yang tepat bisa dilakukan nanti.

@ SteveL-MSFT Apakah Anda yakin pengecualian CLR yang fatal dapat ditangkap? Memverifikasi perbaikan akan sulit karena saya tidak memiliki lingkungan tempat saya dapat mereproduksi ini. Saya dapat mencoba membuat versi PowerShell dengan perbaikan ini dan mengunggahnya di sini sehingga orang-orang yang mengalami masalah ini mengujinya?

@bergmeister Saya tidak bisa

Saya melihat bahwa kita mengabaikan kode pengembalian dalam kode yang bisa berakibat buruk.

[sunting] abaikan komentar saya sebelumnya, meskipun atribut [PreserveSig] salah di banyak tempat, saat membuat PR untuk memperbaikinya, saya perhatikan mereka hanya salah pada metode antarmuka yang tidak Anda panggil.

Saya memiliki perubahan di sini jika Anda menginginkan PR, tetapi itu seharusnya tidak menjadi sumber crash.

@weltkante Menarik, saya mengambil definisi antarmuka dari paket Windows API asli (lihat misalnya di sini ) dan tidak menyadarinya. Saya bukan ahli di bidang ini tetapi jika menurut Anda perubahan Anda membuatnya lebih baik, harap kirimkan PR.

@Antaris @jlouros @msftrncs @cpmcgrath
Dalam PR # 9896, saya menambahkan tangkapan global di sekitarnya dan menambahkan logging untuk mendapatkan lebih banyak informasi.
Silakan unduh MSI dari PowerShell-CI-windows build dari PR tersebut. Jika Anda tidak terbiasa dengan sistem, cukup gunakan tautan langsung ke build di sini dan klik tombol di kanan atas, lalu klik Artifacts dan submenu artifacts . Ini akan mengunduh Anda zip dan di sana ada MSI, yang merupakan versi kustom PowerShell 7 dari commit terbaru di master.

Harap laporkan jika itu memperbaikinya dan jika tidak, berikan pesan log yang dicetak ke konsol PowerShell. Ini akan mengeluarkan semua tahapan yang dilalui kode. Jika Anda melihat pesan dalam format Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. harap beri tahu kami karena itu berarti pernyataan catch dapat menangkap kesalahan CLR yang fatal (yang saya ragu saat ini).
Ini hanyalah versi uji coba dan tidak dimaksudkan untuk penggunaan yang didukung.
UPDATE (19 Juni): Saya memperbarui tautan ke versi yang lebih baru yang seharusnya menangkap pengecualian di dalam pernyataan Task.Run seperti sebelumnya mungkin masih bocor.

@bergmeister Saya telah menginstal MSI Preview7 itu dan akan menghubungi Anda kembali saat saya mencoba dan membuat ulang masalah, dan menjalankannya selama beberapa hari sebagai shell utama saya 👍

Saya melihat bahwa kita mengabaikan kode pengembalian dalam kode yang bisa berakibat buruk.

@iSazonov di mana Anda melihat itu? Saya baru saja meninjau deklarasi antarmuka COM serta memanggil metode CreateElevatedEntry dan tidak dapat menemukan sesuatu yang jelas salah, setidaknya dalam metode yang sebenarnya digunakan. Sepertinya semua metode yang mendeklarasikan PreserveSig memeriksa kode kembaliannya (metode yang mengembalikan void dan tidak mendeklarasikan PreserveSig, kodenya diperiksa oleh lapisan interop).

Bagaimanapun, tidak memeriksa kode pengembalian tidak bisa mengarah ke AccessViolationException di coreclr. Jika stacktrace dari @anmenaga di atas mewakili masalah tersebut, maka kemungkinan besar itu adalah bug lain di lapisan interop coreclr (sudah ada beberapa)

Jika penyelidikan Anda tidak mengarah ke mana pun, mungkin ada baiknya meminta seseorang dari coreclr untuk melihat tempat sampah tersebut. Stacktrace yang berada dalam kode coreclr internal benar-benar tidak terlihat seperti memanggil deklarasi interop dengan kode yang salah. Khususnya ketika di kelas pembantu RCWHolder m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount(); mengembalikan NULL untuk panggilan tengah GetInteropInfoNoCreate maka itu tidak terlalu jauh dalam membuat panggilan menerjang. (Inilah yang terjadi di tempat pembuangan sampah, tidak tahu apakah itu perwakilannya.)

maksudku
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
Dalam rilis build kami mengabaikan hasil gagal.

@iSazonov ah ok, ini tidak benar-benar mengabaikan hasil kegagalan, hanya tidak memberikan diagnosa. Ini masih segera kembali, yang berarti upaya untuk membuat entri JumpList dibatalkan tanpa melakukan panggilan COM lagi. Melakukan pengembalian tentu tidak dapat menyebabkan jenis kecelakaan yang kita lihat di sini.

Saya baru saja melihat implementasi WPF dan memeriksa kodenya bahwa itu dalam status apartemen STA. Utas WPF semuanya dalam STA jadi saya tidak yakin apakah pemeriksaan ini disebabkan oleh WPF atau jika STA lebih cocok untuk panggilan COM yang kami buat (PowerShell Core, bahkan 7, dalam mode MTA karena .Net Core secara historis tidak mendukung STA):
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L564

Biasanya COM menangani apartemen untuk Anda, jika Anda tidak menggunakan STA maka CoCreateInstance akan membuat utas STA khusus untuk objek COM jika terdaftar hanya berjalan di STA.

PowerShell Core, bahkan 7, dalam mode MTA karena .Net Core secara historis tidak mendukung STA

Anda tidak bisa begitu saja mengubah utas menjadi STA, jika Anda melakukannya maka Anda memerlukan loop pesan juga. Jika Anda tidak memiliki loop pesan Windows maka Anda mungkin seharusnya tidak menjadi STA.

@Aaris Terima kasih. NB: Jika Anda melihat pesan dalam format Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. harap beri tahu kami karena itu berarti pernyataan catch dapat menangkap kesalahan CLR yang fatal (yang saya ragu saat ini).
Sementara itu, saya menduga bahwa kesalahan ini terjadi pada mesin dengan spesifikasi perangkat keras yang berbeda, saya lelah dengan inti CPU 1, 4 dan 16. Adakah yang bisa berbagi detail?

@bergmeister Saya belum dapat mereplikasi masalah ini dalam beberapa hari terakhir. Saya akan terus melakukannya, karena saya menggunakan PowerShell secara konstan.

Saya juga tidak menemukan pengecualian apa pun.

Sebagai referensi, mesin spesifikasi saya adalah:
Dell XPS 15 9570
Intel Core i7-8750H - 6 Inti
RAM 32 GB

Itu bagus tapi pernahkah Anda melihat pesan di konsol mengatakan sesuatu seperti
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ?
Hanya jika Anda sudah melihatnya maka itu akan menjadi bukti bahwa kesalahan CLR yang fatal berhasil ditangkap.

Saya dapat mereproduksi bug ini setiap saat jika saya mencoba menjalankan PowerShell. Saya akan menjelaskan dalam 2 Skenario berbeda, yang pertama, ini bekerja tanpa masalah di sisi lain dengan yang kedua tidak.
Jika perlu saya dapat memberikan lebih banyak log atau keluaran.

Perangkat Keras Saya:

Lenovo Y520
Intel I7 7700HQ (2.8Ghz)
16 GB Ram
Samsung 512 970Pro SSD
HDD WesternDigital WD10SPCX 1TB
Nvidia 1050TI GPU 4GB

Perangkat Lunak Saya:

OS:
M $ Windows 10 - Versi 1903 - OsBuild 18917.1000

Kode VS:
Versi: 1.36.0-insider (pengaturan sistem)
Komit: 68a7e5bc437b38d0281df0756997a25da2a2900c
Tanggal: 2019-06-18T18: 40: 22.519Z
Elektron: 4.2.4
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18917

PowerShell:
$ PSVersionTable

Nilai Nama
---- -----
PSVersion 7.0.0-preview.1
PSEdition Core
GitCommitId 7.0.0-preview.1
OS Microsoft Windows 10.0.18917
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Skenario:

Skenario 1 :

Langkah :
1-coba klik kanan folder dan pilih PowerShell preview 7 -> buka di sini
Hasil:
bekerja dengan sempurna tanpa masalah

Skenario2:

Langkah :
1-buka VS Code di folder pipenv (virtualenv) (Klik kanan folder / direktori dan pilih Open with Code Insider)
2-tunggu sampai virtualenv diinisialisasi
3-coba klik kanan folder yang sama dan pilih PowerShell preview 7 -> buka di sini (atau coba jalankan melalui pintasan)
Hasil:
Memberikan kesalahan ini dan tutup:
Kesalahan CLR internal. (0x80131506)
di Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
di Microsoft.PowerShell.ConsoleHost + <> c.b__4_0 ()
di System.Threading.Tasks.Task.InnerInvoke ()
di System.Threading.Tasks.Task + <> c. <. cctor> b__274_0 (System.Object)
di System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop (System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
di System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task ByRef, System.Threading.Thread)
di System.Threading.Tasks.Task.ExecuteEntryUnsafe (System.Threading.Thread)
di System.Threading.Tasks.Task.ExecuteFromThreadPool (System.Threading.Thread)
di System.Threading.ThreadPoolWorkQueue.Dispatch ()
di System.Threading._ThreadPoolWaitCallback.PerformWaitCallback ()

@usta Bisakah Anda jelaskan apa yang Anda maksud dengan 'pipenv (virtualenv)', saya tidak terlalu banyak menggunakan Python. Karena Anda mengatakan Anda selalu dapat mereproduksi, silakan baca komentar saya di bawah ini, instal custom build dan laporkan jika itu memperbaikinya:
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

@usta Bisakah Anda jelaskan apa yang Anda maksud dengan 'pipenv (virtualenv)', saya tidak terlalu banyak menggunakan Python. Karena Anda mengatakan Anda selalu dapat mereproduksi, silakan baca komentar saya di bawah ini, instal custom build dan laporkan jika itu memperbaikinya:
# 9295 (komentar)
@gambarunik
Sepertinya yang satu ini telah memperbaiki bug itu (jika saya mengalami masalah yang sama, saya akan menyebutkannya di sini) terima kasih

Sepertinya saya tidak dapat mereproduksinya dengan custom build, tetapi cukup jarang dengan 7 preview 1, namun 6.2 melakukannya dengan sangat teratur. Mungkin ada beberapa kegunaan dalam menerapkan tambalan ke versi kustom 6.2, atau serangkaian versi dari 6.2. Hanya menambahkan debug / coba / tangkap mungkin telah mengubah sesuatu seperti penguncian sumber daya terkait waktu atau sesuatu.

cc @ TravisEz13 @adityapatwardhan kita harus mempertimbangkan untuk mengambil perubahan @bergmeister ke 6.2.2

@bergmeister bisakah kita membuka kembali bug ini?
Karena saya telah terkena bug yang sama hari ini lagi (dengan yang Anda sebutkan (custom build))
(atau mungkin yang berbeda)

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Melakukan
CoCreateInstance
AddObject
Kesalahan CLR internal. (0x80131506)
di Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (System.String)
di Microsoft.PowerShell.ConsoleHost + <> c.b__4_0 ()
di System.Threading.Tasks.Task.InnerInvoke ()
di System.Threading.Tasks.Task + <> c. <. cctor> b__274_0 (System.Object)
di System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop (System.Threading.Thread, System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
di System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task ByRef, System.Threading.Thread)
di System.Threading.Tasks.Task.ExecuteEntryUnsafe (System.Threading.Thread)
di System.Threading.Tasks.Task.ExecuteFromThreadPool (System.Threading.Thread)
di System.Threading.ThreadPoolWorkQueue.Dispatch ()
di System.Threading._ThreadPoolWaitCallback.PerformWaitCallback ()

PS C: \ Windows \ System32> $ PSVersionTable

Nilai Nama
---- -----
PSVersion 7.0.0-preview2.25651
PSEdition Core
GitCommitId 7.0.0-preview2.25651
OS Microsoft Windows 10.0.18922
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

@usta Ya, saya setuju, kami harus membuka kembali (saya tidak memiliki hak tetapi akan memberi tahu pengelola). Terima kasih banyak telah melaporkan dan menyediakan log, sekarang kami tahu bahwa masalah terjadi pada baris ini (jika terjadi lagi tetapi dengan log yang berbeda di mana AddObject bukan baris terakhir sebelum crash, beri tahu kami ):
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89 -L90
@ daxian-dbw @ SteveL-MSFT @iSazonov Ini berarti bahwa meskipun ada laporan awal positif bahwa PR # 9928 tidak dapat menangkap kesalahan CLR fatal yang telah dilaporkan beberapa kali (semua laporan bug melaporkan kesalahan yang sama). Sementara masih ada beberapa nilai dalam melakukan penangkapan global untuk sesuatu yang tidak penting, masalahnya masih tetap ada ... Dengan informasi tambahan saya dapat mencoba melihat apakah kita dapat membuat kode lebih defensif untuk menghindari sampai ke titik di mana ini masalah terjadi (yang saya curigai sebagai bug di coreclr itu sendiri, apakah bermanfaat membuka masalah di sana?). Kalau tidak, saya hanya dapat berpikir untuk menonaktifkan fitur ini melalui misalnya variabel lingkungan (atau menyimpan beberapa info jika jumplist telah diisi sekali karena tetap ada setelah itu, tidak yakin apakah tetap ada setelah pembaruan Windows ...) Beri tahu saya apa yang Anda berpikir / lebih suka.
Pada catatan terkait, saya membuka masalah berikut dan PR di WPF untuk menambahkan API yang diperlukan untuk secara radikal menyederhanakan kode / tanggung jawab dalam repo ini, tetapi sejauh ini PR belum ditinjau dan masalah telah ditandai dengan .Net 5 ....:
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister sekarang saya mencoba lagi dan lagi untuk mereproduksi kesalahan yang sama.
Pada akhirnya saya dapat mereproduksinya tetapi kali ini memberikan log anohter:

GetStartupInfo
CoCreateInstance
BeginList
SetValue
Melakukan
CoCreateInstance
AddObject
Exception 'System.Runtime.InteropServices.InvalidComObjectException: objek COM yang telah dipisahkan dari RCW dasarnya tidak dapat digunakan.
di System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, tanda Int32)
di Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
di Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (Judul string)
di Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () 'dengan pelacakan tumpukan di System.StubHelpers.InterfaceMarshaler.ConvertToNative (Object objSrc, IntPtr itfMT, IntPtr classMT, Int32 flags)
di Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks (IObjectArray poa)
di Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry (Judul string)
di Microsoft.PowerShell.ConsoleHost. <> c.b__4_0 () berhasil ditangkap.
PS C: \ Users \ usta>

Jika perlu, saya akan dengan senang hati menguji build lain atau mencoba memberikan log lain (yang mungkin perlu mengatasi bug ini)

@gambarunik
Saya bahkan bukan $ programmer teknologi tetapi hanya karena rasa ingin tahu, bukankah baris ini juga perlu pemeriksaan ekstra sebelum meneruskan ke AddUserTasks?
(https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L87)
Maksud saya bukankah itu mungkin lebih baik seperti ini:
hResult = pShortCutCollection.AddObject ((IShellLinkW) nativePropertyStore);
jika (hResult <0)
{
pShortCutCollection.Clear ();
Debug.Fail ($ "Tidak dapat menambahkan nativePropertyStore ke Collection: HResult '{hResult}'.");
kembali;
}

Apakah mungkin untuk mendeteksi jika daftar lompat sudah ada (tetap ada), dan melewati langkah-langkah untuk membuatnya dalam kasus tersebut?

@usta no, AddObject dideklarasikan sebagai return void dan dengan demikian lapisan interop akan melakukan pemeriksaan (dan mengeluarkan pengecualian)

@msftrncs Saya tidak tahu API terkelola yang mengekspos pembacaan jumplist, jadi saya curiga bahwa API asli bahkan tidak mendukungnya, tetapi saya tidak memeriksanya. Bagaimanapun, hanya memeriksa keberadaan itu salah, itu akan menyebabkan jumplist menjadi usang jika salah satu propertinya berubah.

Dengan cara apa pun jika Anda tidak dapat memperbaiki masalah di sini (dan saya benar-benar ragu menambahkan coba / tangkap karena kepanikan yang benar akan berhasil atau ide yang baik), Anda mungkin harus mengangkat masalah dengan coreclr untuk pemeriksaan lebih lanjut. Anda memang memiliki tempat sampah untuk diperiksa. Skenario dalam dump jelas terlihat seperti bug yang benar bagi saya. (Lihat komentar saya di

Saya membuka masalah dengan semua detail di repo CoreClr, mungkin mereka dapat membantu kami. Saya telah melihat kode kami lagi dan tidak ada cara yang lebih defensif untuk menanyakan API jika jumplist telah dibuat, kami hanya mendapatkan jumlah maksimum slot yang tersedia dan sudah kembali lebih awal jika tidak ada cukup ruang untuk jumplist , yang bisa kita lakukan hanyalah menyimpan jumplist ke dalam cache secara internal atau memiliki fitur seperti flag fitur untuk melewati kode pembuatan jumplist yang bermasalah (setelah entri jumplist dibuat, ia tetap ada).
https://github.com/dotnet/coreclr/issues/25502

@bergmeister Saya telah mencoba
Apakah sudah diperbaiki atau alasan bug itu hilang.

PS C: \ Users \ usta> echo $ PSVersionTable

Nilai Nama
---- -----
PSVersion 7.0.0-dailypreview2.26796
PSEdition Core
GitCommitId 7.0.0-dailypreview2.26796
OS Microsoft Windows 10.0.18922
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Semua orang: Tim CoreClr telah menyelidiki masalah ini dan masalahnya adalah bahwa COM API yang dipanggil hanya STA saja (PS Core saat ini masih beroperasi di MTA sampai # 7216 diselesaikan) dan coreclr tidak memberikan peringatan / kesalahan. Oleh karena itu saya telah mendorong perubahan untuk membuat JumpList di thread STA, yang diharapkan menjadi resolusi akhir.
Silakan re-test dengan terbaru membangun PR # 9896 dan memberikan umpan balik

Semua orang: Perbaikan untuk masalah ini telah di-backport ke rilis terbaru 6.2.2 , harap perbarui dan berikan umpan balik jika telah memperbaikinya. Pengguna pratinjau harus menunggu 7.0.0-preview.2
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

: tada: Masalah v7.0.0-preview.2 .: tada:

Tautan yang berguna:

• Catatan Rilis

: tada: Masalah v7.0.0-preview.2 .: tada:

Tautan yang berguna:

• Catatan Rilis