VSCodeまたはVSCodeのPowerShell拡張機能に関連している可能性があります。 システムを再起動した後、すぐにPowerShellを問題なく開くことができました。 VS Codeが開いていると、PowerShellの非管理セッションは開いたままになりません。 VS Codeを閉じた後でも、PowerShellは確実に開くことを拒否しているようです。

cmd.exeからPowerShellCoreを実行すると、エラーメッセージが表示されます。

プロンプトでCMDからPWSHを開こうとすると、PowerShellが正常に起動します。 PowerShellのそのセッションを開いていても、タスクバーアイコンから開くと、開かれません。 また、エクスプローラーのアドレスバーにPWSHと入力してみたところ、同じ非オープンの結果が得られました。

開かないことによって、これが起こります。 ウィンドウがポップアップし、ヘッダー情報が表示されます。
`` `
PowerShell 6.2.0
Copyright（c）MicrosoftCorporation。 全著作権所有。

https://aka.ms/pscore6-docs
ヘルプを取得するには、「help」と入力します。
「」
コマンドプロンプトが表示されることはなく、少し遅れてウィンドウが閉じます。

しばらくシステムを離れると（数分、おそらく10分ですが、システムで他のタスクを実行し続けます）、PowerShellを開いても問題なく動作します。 パターンを繰り返すことができました。 PowerShellが正常に開いた後、VS Codeを閉じ（開いていた場合）、少し待ってからVS Codeを再度開き、少し待って（おそらく1分）、PowerShellが再び開くのに失敗しますが、これはしばらくの間再び続きます。

昨夜、19H1インサイダーマシンでこれをすべて繰り返してみましたが、最初から繰り返されませんでした。 PowerShellを初めて開くのに失敗しましたが、再起動した後でも、その後はすべて機能しました。

プロンプトでCMDからPWSHを開こうとすると、

常に？

PowerShell Coreホームディレクトリを開いてpwsh.exeをダブルクリックすると、いつでも正常に起動しますか？

プロンプトでCMDからPWSHを開こうとすると、

常に？

これまでのところ。 PWSHウィンドウを試してみると、失敗します。CMDを開いて、PWSHと入力します。正常に起動し、別のPWSHウィンドウを試してみると、失敗します。 PWSHのCMDインスタンスを終了して再試行すると、正常に開きます。 繰り返し、CMDウィンドウを完全に閉じて、最初からやり直しますが、それでもCMDプロンプトでのPWSHは常に機能しているようです。

また、PWSHウィンドウのインスタンスが正常に開いた後でも、数分後に再試行すると、これまでのところ推測できる特別な理由がない限り、再び開かないことを完全に誓うわけではありません。

PowerShell Coreホームディレクトリを開いてpwsh.exeをダブルクリックすると、いつでも正常に起動しますか？

同じノーオープン状態のようです。 これは奇妙なことです。EXEファイルを直接クリックすると、ほとんどの場合同じ非オープン状態になるようですが、スタートメニューフォルダに保存されているショートカットをクリックすると、散発的になり、正常に開くことがよくありますが、常にそうとは限りません。 。

Windows OSは、すべての（コンソール）アプリケーションのウィンドウパラメータを保持します。 パラメータが壊れているようで、レジストリからクリーンアップする必要があります。

私もこれを経験しています。 それが役立つ場合は、イベントビューアに次のように表示されます。

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: 

@cpmcgrathと同様に、起動に失敗した直後に、アプリケーションイベントログに同じことが表示されることを確認できます。
（2イベント）

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: 

これは、PowerShell Preview Extensionを使用してVSCodeを開くことと相互に関連していることがまだわかりますが、.Netを使用する他のアプリケーションでもこの条件を設定できると思います。

@msftrncs詳細情報を取得するために、デバッグビルドをコンパイルして実行してください。 また、クリーンなシステムで問題を再現できるように、レポの手順を取得しておくと便利です。

私はこれと同じ問題を経験しています。

ソース：アプリケーションエラー

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: 

ソース：.NETランタイム

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.

Windowsエラー報告で収集した情報を添付しました。
Report.zip

観察：

• Windows v1903（OSビルド18362.30）を実行しています
• Powershell拡張機能（v2019.5.0）を使用してVisual Studio Code（v1.35.0）をインストールしています
• 再起動後に発生するようです
• プロファイルの読み込みには時間がかかるようです
• 管理モードで発生することもあれば、発生しないこともあります
• 以下に定義されているプロファイルの一部としてpostgitモジュールをインストールしています。

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ありがとう！ あなたのレポは永続的ですか？ 最新のPowerShellCoreビルドでリポジトリを作成できますか？

それは永続的ではなく、より断続的です。 最新のビルドをダウンロードして、修正されるかどうかを確認します。

@Antarisリポジトリをフォークしてビルドしてください。デバッグモードでは、例外としてより多くの情報を取得できます。

@ SteveL-MSFT 6.2バージョンについて心配する必要がありますか？

モジュール名の誤りから判断すると、.NETの問題だと感じています。 同様のことが以前にも起こりました。
一方、これは、クラッシュプロセスのダンプを取得する簡単な方法であり、調査と修正に大いに役立つすべての詳細が含まれています。 @ Antaris - ProcDumpユーティリティを試すことができ

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

次回PSがクラッシュすると、詳細なエラー情報を含むダンプが指定されたフォルダーに書き込まれます。

@anmenaga

私は今朝、なんとかこの経験を引き起こすことができました。 ラップトップを新たに再起動します。 PowerShell Coreを初めて開いたときは、問題ありませんでした。 次に、Visual StudioCodeを使用してPSCoreプロファイルを読み取り、_変更を加えずに_保存を開始しました。 次に、PowerShell Coreを開くと、すぐに閉じました。

ダンプファイルはここにあります：
https://drive.google.com/file/d/1KKeS3co8rE3w1xi3cFUPT21notKSmudT/view?usp=sharing

@iSazonov申し訳ありませんが、現在のコミットに対してこれをテストする時間がありませんでした。今週はそれを実行しようとします

アクセス違反はTaskbarJumpList.CreateElevatedEntry下から発生しているようです。
@bergmeister 、この関数の安定性の問題を

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

これは、コマンドラインからpwshを起動した場合にこれが発生しない理由を説明しています。

以前に散発的な障害の報告があり、他の人々がCOM呼び出しを改善しようとしました。 この場合、使用済みのWindowsInsiderビルド19H1も原因である可能性があります。
同じCOM呼び出しを使用して元のC ++コードをWindowsPowerShellからC＃に移植し、COMインターフェイス定義にWindowsApiパックのソースコードを使用しました。
幸いなことに、このコードはpwshがインタラクティブに起動したときにのみ実行され、ジャンプリストメニューの登録は1回だけ実行する必要があります（暗黙的にチェックするコードがあります）。 たぶん、その周りにtry {} catchブロックを配置し、障害スタックトレースのみをログアウトする必要がありますか？
一般的に言って、私がそれをしたとき、私はWindows ApiPackの完全な.Netコードを.NetCoreに移植し、それを微調整して、昇格のあるジャンプスタートエントリを可能にする必要がありました。 2週間前、WPFはJumpListのソースコードを追加し、PRを使用してジャンプリストを昇格できるようにすることで、多くの作業を数行に延期できましたが、最終的には.NetCoreの問題だと思います。

@bergmeisterあなたはこの仕事を引き受けても構わないと

試してみると、ジャンプリストエントリでアプリケーションを昇格モードで開くには、WPF APIにブールパラメータ（デフォルトはfalse）を追加する必要があります。 APIの変更を受け入れる意思の点で、WPFの担当者がどれだけ柔軟であり、PRをマージするのがどれほど難しいかによって異なりますが、.Net Core 3は7月頃にRCを公開したいので、時間との戦いになると思います。 （それ以降、そのような変更を受け入れる可能性が低くなることを意味します）。
それ以外の場合、唯一の代替手段はエラーをキャッチしようとすることです（しかし、私にはこれはキャッチできない致命的なCLRエラーのように見えます）。
私自身、残念ながらそのようなエラーを経験したことはありません

GUIでは競合状態のようです。

@ SteveL-MSFT 6.2バージョンについては明確ではありません-それも修正する必要がありますか？

次のステートメントをバックアップするためのデータがない場合、「管理者として実行」を指定してPowerShellを開いた場合、この問題はほとんど発生しないようです。

@jlouros私は、昇格せずに実行することと、管理者として実行することの両方を経験しました

これはPS7-preview1でも発生しますか？ .Net Core 3ではCOMの相互作用が改善されており、.Net Core2.1の問題である可能性があります。
また：PR＃7580と同様のコードへの同様の改善も役立つ可能性がありますか？

@ bergmeister 、7プレビューでも発生しましたが、それほど頻繁ではありません。 7プレビューではCLRエラーダンプが表示されるようですが、すぐに閉じます…しかし、私はそれを取得しました：

@jlourosが言及しているように、「管理者として」実行しているときも、これはほとんど経験しませんが、 @ Antarisが言ったように、それでも時折発生します。

デバッグビルドでより多くの情報を得ることができます（コードのリリースビルドのエラーは無視します！）

@ SteveL-MSFT最初にサインオフするためにWPFでAPI提案を開き（提案された変更は中断しないので、問題ないはずです）、いくつかの低レベルの実装の詳細を含めました。 WPFコード自体については詳しく調べていませんが、それほど難しくはないはずです（最も難しい部分はテストかもしれません）。
https://github.com/dotnet/wpf/issues/950
これは、PowerShell 7の前進の道です。私は、WPFコードをより詳細に読み始め、それを実装と比較して、COM呼び出しを改善できるかどうかを確認します。これが、 AppartmentStateはMTAこれは、基本的にC ++ Windows PowerShellコードをC＃に変換し、最初に実装を行ったときにWindowsAPIのインターフェイス定義を使用したためです。

@bergmeister今のところ、おそらく暫定的な解決策は、pwshが少なくとも開始するようにtry ... catchでラップすることだと思います。 その修正を6.2.xサービスに適用できます。 適切な修正は後で行うことができます。

@ SteveL-MSFT致命的なCLR例外をキャッチできると確信していますか？ これを再現できる環境がないため、修正の確認は困難です。 この修正を使用してPowerShellのバージョンを作成し、ここにアップロードして、この問題の人々がテストできるようにすることができますか？

@bergmeisterこれを自分で

悪い可能性のあるコード内のリターンコードを無視していることがわかります。

[編集] [PreserveSig]属性が複数の場所で間違っている場合でも、以前のコメントを無視します。それらを修正するためのPRを行っているときに、呼び出していないインターフェイスメソッドでのみ間違っていることに気付きました。

とにかくPRが必要な場合は、ここで変更を加え

@weltkante興味深いことに、私は元のWindows APIパック（たとえばここを参照）からインターフェイス定義を取得しましたが、これに気づいていませんでした。 私はこの分野の専門家ではありませんが、変更によって改善されたと思われる場合は、PRを提出してください。

@Antaris @jlouros @msftrncs @cpmcgrath
PR＃9896では、その周りにグローバルキャッチを追加し、ログを追加してより多くの情報を取得しました。
そのPRのPowerShell-CI-windowsビルドからMSIをダウンロードしてください。 システムに慣れていない場合は、ここでビルドへの直接リンクを使用し、右上のボタンをクリックしてから、 Artifactsをクリックしてから、 artifactsサブメニューをクリックしてください。 これによりzipがダウンロードされ、MSIがあります。これは、マスターでの最新のコミットからのPowerShell7のカスタムバージョンです。

修正されたかどうかを報告してください。修正されていない場合は、PowerShellコンソールに出力されるログメッセージを提供してください。 コードが通過するすべての段階をログアウトします。 Exception '{exception}' with stack trace {exception.StackTrace} successfully caught.の形式のメッセージが表示された場合は、 catchステートメントが致命的なCLRエラー（現時点では疑わしい）をキャッチできたことを意味するため、お知らせください。
これは単なるテストビルドであり、サポートされている使用を目的としたものではありません。
更新（6月19日）： Task.Runステートメント内の例外をキャッチする新しいビルドへのリンクを、以前と同じようにリークする可能性があるように更新しました。

@bergmeisterそのPreview7MSIをインストールしました。問題を再現しようとすると、返信があり、メインシェルとして数日間実行します👍

悪い可能性のあるコード内のリターンコードを無視していることがわかります。

@iSazonovどこにあると思いますか？ COMインターフェイス宣言とCreateElevatedEntryメソッドの呼び出しを確認したところ、少なくとも実際に使用されているメソッドでは、明らかに問題は見つかりませんでした。 PreserveSigを宣言しているすべてのメソッドがリターンコードをチェックしているようです（voidを返し、PreserveSigを宣言していないメソッドは、相互運用レイヤーによってリターンコードがチェックされます）。

とにかく、リターンコードをチェックしないと、coreclrでAccessViolationExceptionが発生することはありません。 上記の@anmenagaからのスタックトレースが問題の代表である場合、それは

調査がどこにも進まない場合は、coreclrの誰かにダンプを見てもらう価値があるかもしれません。 内部coreclrコードにあるスタックトレースは、実際には、誤ってコーディングされた相互運用機能宣言を呼び出すようには見えません。 特に、 coreclr RCWHolderヘルパークラスで、行m_pSB->GetInteropInfoNoCreate()->GetRCWAndIncrementUseCount();がGetInteropInfoNoCreateの中間呼び出しに対してNULLを返す場合、クラッシュ呼び出しを行うのにそれほど遠くはありませんでした。 （これはダンプで起こったことであり、その代表者かどうかはわかりません。）

というのは
c# if (hResult < 0) { Debug.Fail($"BeginList on ICustomDestinationList failed with HResult '{hResult}'."); return; }
リリースビルドでは、失敗の結果を無視します。

@iSazonovああ、これは失敗の結果を実際に無視するわけではなく、診断を提供しないだけです。 それでもすぐに戻ります。つまり、JumpListエントリを作成する試みは、COM呼び出しを行わずに中止されます。 返品を行うことは、確かに私たちがここで見ているようなクラッシュにつながることはありません。

WPFの実装と、そのコードがSTAアパートメント状態にあることを確認しました。 WPFスレッドはすべてSTAにあるため、このチェックがWPFによるものなのか、それともSTAが私たちが行うCOM呼び出しに適しているのかはわかりません（PowerShell Coreは7つでも、.Net CoreがこれまでサポートされていなかったためMTAモードになっています） STA）：
https://github.com/dotnet/wpf/blob/ae1790531c3b993b56eba8b1f0dd395a3ed7de75/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Shell/JumpList.cs#L564

通常、COMがアパートメントを処理します。STAを使用していない場合、CoCreateInstanceは、COMオブジェクトがSTAでのみ実行されるように登録されている場合、COMオブジェクト専用のSTAスレッドを作成します。

PowerShell Coreは、7であっても、.Net CoreがこれまでSTAをサポートしていなかったため、MTAモードになっています。

スレッドをSTAに変えることはできません。そうすると、メッセージループも必要になります。 Windowsメッセージループがない場合は、おそらくSTAになるべきではありません。

@Antarisありがとう。 PS： Exception '{exception}' with stack trace {exception.StackTrace} successfully caught.の形式のメッセージが表示された場合は、 catchステートメントが致命的なCLRエラーをキャッチできたことを意味するのでお知らせください（現時点では疑わしいです）。
それまでの間、このエラーはハードウェア仕様の異なるマシンで発生するのではないかと思います。1、4、16個のCPUコアで疲れました。 誰かが詳細を共有できますか？

@bergmeister過去数日間、問題を再現できませんでした。 PowerShellを常に使用しているので、これを維持します。

また、例外は発生していません。

参考までに、私のスペックマシンは次のとおりです。
Dell XPS 15 9570
Intel Corei7-8750H-6コア
32GB RAM

それは良いことですが、コンソールで次のようなメッセージを見たことがありますか
Exception '{exception}' with stack trace {exception.StackTrace} successfully caught. ？
あなたがそれを見た場合にのみ、それは致命的なCLRエラーがうまく捕らえられたという証拠になるでしょう。

PowerShellを実行しようとすると、毎回このバグを再現できます。 2つの異なるシナリオで説明します。最初のシナリオでは問題なく動作し、2番目のシナリオでは問題なく動作しています。
必要に応じて、より多くのログまたは出力を提供できます。

私のハードウェア：

レノボY520
Intel I7 7700HQ（2.8Ghz）
16GBラム
サムスン512970Pro SSD
WesternDigital WD10SPCX 1TB HDD
Nvidia 1050TI GPU 4GB

私のソフトウェア：

OS：
M $ Windows10-バージョン1903-OsBuild18917.1000

VSコード：
バージョン：1.36.0-インサイダー（システムセットアップ）
コミット：68a7e5bc437b38d0281df0756997a25da2a2900c
日付：2019-06-18T18：40：22.519Z
電子：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

パワーシェル：
$ PSVersionTable

名前値
---- -----
PSVersion 7.0.0-preview.1
PSEditionコア
GitCommitId 7.0.0-preview.1
OS Microsoft Windows 10.0.18917
プラットフォームWin32NT
PSCompatibleVersions {1.0、2.0、3.0、4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

シナリオ：

シナリオ1：

手順：
1-フォルダーを右クリックして、PowerShellプレビューを選択します7->ここで開きます
結果：
問題なく完全に動作します

シナリオ2：

手順：
1-pipenv（virtualenv）フォルダーでVS Codeを開きます（フォルダー/ディレクトリを右クリックして[Open with Code Insider]を選択します）
2-virtualenvを初期化するまで待ちます
3-同じフォルダーを右クリックしてPowerShellプレビュー7を選択します->ここで開きます（またはショートカットを使用して実行してみます）
結果：
このエラーを出して閉じます：
内部CLRエラー。 （0x80131506）
Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry（System.String）で
Microsoft.PowerShell.ConsoleHost + <> cで。b__4_0（）
System.Threading.Tasks.Task.InnerInvoke（）で
System.Threading.Tasks.Task + <> c。<。cctor> b__274_0（System.Object）で
System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop（System.Threading.Thread、System.Threading.ExecutionContext、System.Threading.ContextCallback、System.Object）で
System.Threading.Tasks.Task.ExecuteWithThreadLocal（System.Threading.Tasks.Task ByRef、System.Threading.Thread）で
System.Threading.Tasks.Task.ExecuteEntryUnsafe（System.Threading.Thread）で
System.Threading.Tasks.Task.ExecuteFromThreadPool（System.Threading.Thread）で
System.Threading.ThreadPoolWorkQueue.Dispatch（）で
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback（）で

@usta 「pipenv（virtualenv）」の意味を教えてください。私はPythonをあまり使用していません。 いつでも複製できるとおっしゃっていますので、以下の私のコメントを読んで、カスタムビルドをインストールし、修正されたら報告してください。
https://github.com/PowerShell/PowerShell/issues/9295#issuecomment -502053584

@usta 「pipenv（virtualenv）」の意味を教えてください。私はPythonをあまり使用していません。 いつでも複製できるとおっしゃっていますので、以下の私のコメントを読んで、カスタムビルドをインストールし、修正されたら報告してください。
＃9295（コメント）
@bergmeister
これでバグが修正されたようです（同じ問題が発生した場合は、ここで説明します）ありがとうございます

カスタムビルドでは再現できないようですが、7プレビュー1では非常にまれでしたが、6.2では非常に定期的に再現されています。 6.2のカスタムビルド、または6.2からの一連のビルドにパッチを適用することには、いくつかの有用性があるかもしれません。 debug / try / catch inを追加するだけで、タイミング関連のリソースロックアップなどが変更された可能性があります。

CC @ TravisEz13我々は6.2.2に@bergmeisterの変更を取って検討すべきである@adityapatwardhan

@bergmeisterこのバグを再開できますか？
今日も同じバグに遭遇したので（あなたが言及したもの（カスタムビルド）で）
（または別のもの）

GetStartupInfo
CoCreateInstance
BeginList
SetValue
コミット
CoCreateInstance
AddObject
内部CLRエラー。 （0x80131506）
Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry（System.String）で
Microsoft.PowerShell.ConsoleHost + <> cで。b__4_0（）
System.Threading.Tasks.Task.InnerInvoke（）で
System.Threading.Tasks.Task + <> c。<。cctor> b__274_0（System.Object）で
System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop（System.Threading.Thread、System.Threading.ExecutionContext、System.Threading.ContextCallback、System.Object）で
System.Threading.Tasks.Task.ExecuteWithThreadLocal（System.Threading.Tasks.Task ByRef、System.Threading.Thread）で
System.Threading.Tasks.Task.ExecuteEntryUnsafe（System.Threading.Thread）で
System.Threading.Tasks.Task.ExecuteFromThreadPool（System.Threading.Thread）で
System.Threading.ThreadPoolWorkQueue.Dispatch（）で
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback（）で

PS C：\ Windows \ System32> $ PSVersionTable

名前値
---- -----
PSVersion 7.0.0-preview2.25651
PSEditionコア
GitCommitId 7.0.0-preview2.25651
OS Microsoft Windows 10.0.18922
プラットフォームWin32NT
PSCompatibleVersions {1.0、2.0、3.0、4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

@ustaはい、同意します。再開する必要があります（ただし、権利はありませんが、メンテナに通知します）。 ログを報告して提供していただきありがとうございます。問題がこの行で発生していることがわかりました（再度発生する場合でも、クラッシュ前の最後の行ではない別のログでAddObjectが発生した場合はお知らせください） ）：：
https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L89 -L90
@ daxian-dbw @ SteveL-MSFT @iSazonovこれは、PR＃9928が複数回報告された致命的なCLRエラーをキャッチできないという最初の肯定的な報告にもかかわらず（すべてのバグレポートが同じエラーを報告した）ことを意味します。 本質的ではないものをグローバルにキャッチすることにはまだ価値がありますが、問題は解決しません...追加情報を使用して、このポイントに到達しないように、より防御的にコーディングできるかどうかを調べることができます。問題が発生します（coreclr自体のバグであると思われますが、そこで問題を開く価値はありますか？）。 それ以外の場合は、環境変数などを使用してこの機能を無効にすることしか考えられません（または、ジャンプリストが後で保持されるために一度入力されている場合は情報を保存しますが、Windowsの更新後も保持されるかどうかはわかりません...）考える/好む。
関連するメモとして、次の問題とPRをWPFで開き、必要なAPIを追加して、今後このリポジトリのコード/責任を根本的に簡素化しましたが、これまでのところPRはレビューされておらず、問題には.Net 5タグが付けられています。
https://github.com/dotnet/wpf/issues/950
https://github.com/dotnet/wpf/pull/996

@bergmeister今、私は同じエラーを再現するために何度も何度も試みました。
最後に私はそれを再現するかもしれませんが、今回は別のログを提供します：

GetStartupInfo
CoCreateInstance
BeginList
SetValue
コミット
CoCreateInstance
AddObject
例外 'System.Runtime.InteropServices.InvalidComObjectException：基になるRCWから分離されたCOMオブジェクトは使用できません。
System.StubHelpers.InterfaceMarshaler.ConvertToNative（Object objSrc、IntPtr itfMT、IntPtr classMT、Int32フラグ）で
Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks（IObjectArray poa）で
Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry（String title）で
Microsoft.PowerShell.ConsoleHost。<> cで。b__4_0（） 'System.StubHelpers.InterfaceMarshaler.ConvertToNative（Object objSrc、IntPtr itfMT、IntPtr classMT、Int32フラグ）でスタックトレースを使用
Microsoft.PowerShell.ComInterfaces.ICustomDestinationList.AddUserTasks（IObjectArray poa）で
Microsoft.PowerShell.TaskbarJumpList.CreateElevatedEntry（String title）で
Microsoft.PowerShell.ConsoleHost。<> cで。b__4_0（）が正常にキャッチされました。
PS C：\ Users \ usta>

必要に応じて、別のビルドをテストしたり、他のログを提供したりできます（このバグを克服する必要があるかもしれません）

@bergmeister
私はテクノロジープログラマーでもありませんが、好奇心のために、この行もAddUserTasksに渡す前に追加のチェックが必要ではありませんか？
（https://github.com/PowerShell/PowerShell/blob/86a1697da95974495fc8f08bc58932d0b4020603/src/Microsoft.PowerShell.ConsoleHost/WindowsTaskbarJumpList/TaskbarJumpList.cs#L87）
私はそれがこのような何かより良いかもしれないということではないということです：
hResult = pShortCutCollection.AddObject（（IShellLinkW）nativePropertyStore）;
if（hResult <0）
{{
pShortCutCollection.Clear（）;
Debug.Fail（$ "nativePropertyStoreをコレクションに追加できませんでした：HResult '{hResult}'。"）;
戻る;
}

ジャンプリストがすでに存在する（永続する）かどうかを検出し、その場合はそれを作成する手順をスキップすることは可能ですか？

@ustaいいえ、AddObjectはvoidを返すものとして宣言されているため、相互運用レイヤーがチェックを実行します（そして例外をスローします）

@msftrncsジャンプリストの読み取りを公開するマネージAPIを知らないので、ネイティブAPIもそれをサポートしていないのではないかと思いますが、確認しませんでした。 いずれにせよ、存在をチェックするだけでは間違っています。プロパティの1つが変更されると、ジャンプリストが古くなる原因になります。

いずれにせよ、ここで問題を修正できない場合（そして、coreclrパニックにtry / catchを追加してもうまくいかないか、良い考えではないかと真剣に疑っています）、coreclrで問題を提起してさらに調査する必要があります。 結局のところ、調べるためのダンプがあります。 ダンプのシナリオは確かに私にはcoreclrのバグのように見えます。 （ダンプで何がうまくいかないかについては、上記の私の

CoreClrリポジトリのすべての詳細について問題を開きました。おそらく、それらが私たちを助けてくれるでしょう。 コードをもう一度確認しましたが、ジャンプリストがすでに作成されている場合、APIをクエリするための防御的な方法はありません。使用可能なスロットの最大数のみを取得し、ジャンプリスト用の十分なスペースがない場合は早期に戻ります。 、私たちにできることは、ジャンプリストを内部にキャッシュするか、問題のあるジャンプリスト作成コードをスキップする機能フラグのようなものを用意することだけです（ジャンプリストエントリが作成されると、それは持続します）。
https://github.com/dotnet/coreclr/issues/25502

@bergmeister最新のデイリービルドを試しましたが、このビルドではバグを再現できなかったようです。
それが修正されたか、そのバグの理由がなくなったかどうか。

PS C：\ Users \ usta> echo $ PSVersionTable

名前値
---- -----
PSバージョン7.0.0-dailypreview2.26796
PSEditionコア
GitCommitId 7.0.0-dailypreview2.26796
OS Microsoft Windows 10.0.18922
プラットフォームWin32NT
PSCompatibleVersions {1.0、2.0、3.0、4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

全員：CoreClrチームが問題を調査しました。問題は、呼び出されているCOM APIが厳密にSTAのみであり（PS Coreは現在＃7216が解決されるまでMTAで動作します）、coreclrが警告/エラーを提供しなかったことです。 したがって、STAスレッドでJumpListを作成するための変更をプッシュしました。これが、最終的な解決策になることを願っています。
PR＃9896の最新ビルドで再テストし、フィードバックを提供してください

全員：この問題の修正は、最近のリリースの6.2.2にバックポートされています。修正された場合は、更新してフィードバックを提供してください。 プレビューのユーザーは7.0.0-preview.2を待つ必要があります
https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2
cc @msftrncs @usta @Antaris @cpmcgrath @jlouros

： tada：この問題は＃10057で解決され、 v7.0.0-preview.2として正常にリリースされました。：tada：

便利なリンク：

• リリースノート

： tada：この問題は＃9928で解決され、 v7.0.0-preview.2として正常にリリースされました。：tada：

便利なリンク：

• リリースノート