次の方法で共有

パフォーマンスの問題が修正される可能性を高める

"問題の報告" ツールは、Visual Studio ユーザーがさまざまな問題を報告するために広く使用されています。 Visual Studio チームは、ユーザー フィードバックのクラッシュと低速の傾向を見つけて、幅広いユーザーに影響を与える問題に対処します。 特定のフィードバック チケットの操作性が高いほど、製品チームによって迅速に診断および解決される可能性が高くなります。 このドキュメントでは、クラッシュまたは低速の問題を報告して、より実用的にするためのベスト プラクティスについて説明します。

一般的なベスト プラクティス

Visual Studio は、多数の言語、プロジェクトの種類、プラットフォームなどをサポートする大規模で複雑なプラットフォームです。 実行方法は、セッションにインストールされアクティブになっているコンポーネント、インストールされている拡張機能、Visual Studio の設定、コンピューターの構成、最後に編集中のコードの形状を表す関数です。 変数の数を考えると、目に見える症状が同じであっても、あるユーザーからの問題レポートに、別のユーザーからの問題レポートと同じ根本的な問題があるかどうかを判断するのは困難です。 その場合、特定の問題レポートが診断される可能性が高いことを確認するためのベスト プラクティスをいくつか次に示します。

可能な限り特定のタイトルを指定

報告される問題の個別の署名を探し、タイトルにできるだけ多く含めます。 タイトルがわかりやすい場合、関連のない問題 (ただし、同じ表面的症状) を持つユーザーがチケットに投票またはコメントする可能性が低いため、の問題 診断が困難になります。

不明な場合は、新しい問題レポートをログに記録

多くの問題には、再現する固有の署名や手順がない可能性があります。 このような場合は、同様の外部の症状を報告する別の報告に対してアップ投票やコメントを行うよりも、新しい報告を行う方が適切です。 レポートの種類に応じて、このドキュメントの後半で説明するように、レポートに追加の診断ファイルを含めます。

問題固有のベスト プラクティス

適切な診断ファイルがないと診断が困難な問題を以下に示します。 問題を最も適切に説明するケースを特定したら、そのケースに固有のフィードバック手順に従います。

クラッシュ

プロセス (Visual Studio) が予期せず終了すると、クラッシュが発生します。

直接再現可能なクラッシュ

直接再現可能なクラッシュは、次のすべての特性を持つケースです。

  • 既知の一連の手順に従って観察できます

  • 複数のコンピューターで観察可能 (使用可能な場合)

  • フィードバックの一部としてリンクまたは提供できるサンプル コードまたはプロジェクトで再現できます (手順にプロジェクトまたはドキュメントを開く場合)

これらの問題については、「問題を報告する方法」の手順に従い、必ず以下を含めてください。

  • 問題を再現する手順

  • 上で説明したスタンドアロンの再現プロジェクト。 スタンドアロンの再現が不可能な場合は、次の項目を含めてください。

    • 開いているプロジェクトの言語 (C#、C++など)

    • プロジェクトの種類 (コンソール アプリケーション、ASP.NET など)

手記

最も貴重なフィードバック: この場合、最も価値のあるフィードバックは、サンプルのソース コードと共に問題を再現するための一連の手順です。

不明なクラッシュ

クラッシュの原因がわからない場合、またはランダムに見える場合は、Visual Studio がクラッシュするたびにダンプをローカルにキャプチャし、それらを個別のフィードバック項目に添付できます。 Visual Studio がクラッシュしたときにダンプをローカルに保存するには、管理者コマンド ウィンドウで次のコマンドを実行します。

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService32.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpType /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpCount /t REG_DWORD /d 2
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ServiceHub.RoslynCodeAnalysisService.exe" /v DumpFolder /t REG_SZ /d "C:\CrashDumps"

必要に応じてダンプ数とダンプ フォルダーをカスタマイズします。 これらの設定 の詳細については、を参照してください。

手記

タスク マネージャーを使用してキャプチャされたダンプのビット数が間違っている可能性が高いため、使用できなくなります。 前述の手順は、ヒープ ダンプをキャプチャする場合に推奨される方法です。 タスク マネージャーを使用する場合は、現在実行中のタスク マネージャーを閉じ、32 ビット タスク マネージャー (%windir%\syswow64\taskmgr.exe) を起動し、そこからヒープ ダンプを収集します。

手記

このメソッドによって生成される各ダンプ ファイルのサイズは最大 4 GB です。 DumpFolder を適切なドライブ領域を持つ場所に設定するか、DumpCount を適切に調整してください。

Visual Studio がクラッシュするたびに、構成された場所に devenv.exe.[number].dmp ダンプ ファイルが作成されます。

次に、Visual Studio の「問題の報告...」機能を使用します。 これにより、該当するダンプをアタッチできます。

  1. 報告しているクラッシュのダンプ ファイルを見つけます (正しい作成時刻のファイルを探します)

  2. 可能であれば、フィードバックを送信する前にファイル (*.zip) を圧縮してサイズを小さくします

  3. 「問題を報告する方法」の手順に従って、ヒープ ダンプを新しいフィードバック項目にアタッチします。

手記

最も貴重なフィードバック: この場合、最も価値のあるフィードバックは、クラッシュ時にキャプチャされたヒープ ダンプです。

応答しない

VS は長時間応答しなくなります。

直接再現可能な無応答

クラッシュに関する対応するセクションで説明したように、複数のコンピューターで簡単に再現でき、小さなサンプルで示すことができる問題の場合、最も価値のあるフィードバック レポートは、問題を再現する手順を含むものであり、問題を示すサンプル ソース コードが含まれています。

不明な応答しない状態

応答が予期しない方法で現れる場合は、次に Visual Studio の新しいインスタンスを起動し、そのインスタンスから問題を報告します。 [記録] 画面で、応答しない Visual Studio セッションを選択してください。 (問題を再現するために実行できるアクションを記録する方法の詳細については、「問題を報告する方法」ページの手順 8 参照してください)。

応答しない Visual Studio インスタンスが管理者モードで起動された場合は、2 番目のインスタンスも管理者モードで起動する必要があります。

手記

最も価値のあるフィードバック: この場合、最も価値のあるフィードバックは、応答不能時にキャプチャされたヒープ ダンプです。

低速と高 CPU の問題

低速または高 CPU 使用率の問題を最も実行可能にしているのは、低速操作または高 CPU イベントの進行中にキャプチャされたパフォーマンス トレースです。

手記

可能であれば、各シナリオを個別の特定のフィードバック レポートに分離します。 たとえば、入力とナビゲーションの両方が遅い場合は、問題ごとに次の手順を 1 回実行します。 これは、製品チームが特定の問題の原因を特定するのに役立ちます。

パフォーマンスをキャプチャするのに最適な結果を得るには、次の手順に従います。

  1. まだ実行していない場合は、Visual Studio のコピーを開いて問題を再現します

    • 問題を再現するために必要なすべてを準備します。 たとえば、特定のプロジェクトを特定のファイルを開いて読み込む必要がある場合は、続行する前に両方の手順が完了していることを確認してください。

    • ソリューションの読み込みに固有の問題を報告していない 場合は、ソリューションを開いてから5~10分（またはソリューションのサイズによってはそれ以上）待ってからパフォーマンストレースを記録するようにしてください。 ソリューションの読み込みプロセスでは大量のデータが生成されるため、数分待つと、報告している特定の問題に集中できます。

  2. ソリューションを開かずに Visual Studio の 2 つ目のコピーを開始

  3. Visual Studio の新しいコピーで、問題の報告 ツールを開きます

  4. "トレースとヒープ ダンプを提供する (オプション)" 手順に到達するまで、問題を報告する方法に関する手順に従います。

  5. Visual Studio の最初のコピー (パフォーマンスの問題が発生したコピー) を記録し、記録を開始することを選択します。

    • ステップレコーダーアプリケーションが表示され、記録が開始されます。

    • 記録中に、Visual Studio の最初のコピーで問題のあるアクションを実行。 記録された時間内に表示されない場合、特定のパフォーマンスの問題を修正することは困難です。

    • アクションが 30 秒未満で、簡単に繰り返すことができる場合は、アクションを繰り返して問題をさらに示します。

    • ほとんどの場合、問題のあるアクションが 30 秒を超えて続いた (または繰り返された) 場合は、問題を示すには、60 秒のトレースで十分です。 期間は、修正したい動作をキャプチャするために必要に応じて調整できます。

  6. 遅い操作や高いCPUイベントが完了したら、ステップレコーダーで[記録の停止]をクリックします。 パフォーマンス トレースの処理には数分かかる場合があります。

  7. 完了すると、フィードバックにいくつかの添付ファイルが表示されます。 問題の再現に役立つ可能性のある追加のファイル (サンプル プロジェクト、スクリーンショット、ビデオなど) を添付します。

  8. フィードバックを送信します。

パフォーマンス トレースの記録中に、報告する低速操作または高 CPU が終了した場合は、すぐに記録を停止します。 収集される情報が多すぎると、最も古い情報が上書きされます。 トレースが興味深い操作の後すぐに (数秒以内に) 停止しないと、有用なトレース データが上書きされます。

Developer Community Web サイトの既存のフィードバック項目にパフォーマンス トレースを直接添付しないでください。 追加情報の要求/提供は、Visual Studio の組み込みの問題報告ツールでサポートされているワークフローです。 以前のフィードバック項目を解決するためにパフォーマンス トレースが必要な場合は、フィードバック項目の状態を "詳細情報が必要" に設定します。これは、新しい問題の報告と同じ方法で対応できます。 詳細な手順については、「問題の報告」ツールのドキュメントの 「詳細情報が必要」セクションを参照してください。

手記

最も貴重なフィードバック: ほぼすべての低速/高 CPU の問題について、最も重要なフィードバックは、その間の動作をキャプチャするパフォーマンス トレース (*.etl.zip) と共に、実行しようとした操作の概要を説明することです。

高度なパフォーマンス トレース

ほとんどのシナリオでは、問題報告ツールのトレース収集機能で十分です。 ただし、トレース コレクションをより細かく制御する必要がある場合 (たとえば、バッファー サイズが大きいトレースなど)、PerfView は最適なツールです。 PerfView ツールを使用してパフォーマンス トレースを手動で記録する手順については、「PerfView を使用したパフォーマンス トレースの記録 」 ページを参照してください。

アウトプロセスの問題

手記

Visual Studio 2019 バージョン 16.3 以降では、アウトプロセス ログは、問題の報告ツールを使用して送信されたフィードバックに自動的に添付されます。 ただし、問題が直接再現可能な場合は、次の手順に従うことで、問題の診断を改善するために追加情報を追加できます。

Visual Studio と並列に実行され、Visual Studio のメイン プロセスの外部からさまざまな機能を提供するサテライト プロセスが多数あります。 これらのサテライト プロセスのいずれかでエラーが発生した場合、通常は Visual Studio 側で "StreamJsonRpc.RemoteInvocationException" または "StreamJsonRpc.ConnectionLostException" と表示されます。

これらの種類の問題が最も実用的なのは、次の手順に従って収集できる追加のログを提供することです。

  1. これが直接再現可能な問題である場合は、まず %temp%/servicehub/logs フォルダーを削除します。 この問題を再現できない場合は、フォルダーをそのまま維持して、次の箇条書きを無視してください。

    • グローバル環境変数 ServiceHubTraceLevel を All に設定する
    • 問題を再現します。

  2. Microsoft Visual Studio と .NET Framework ログ収集ツール をダウンロード。

  3. ツールを実行します。 これにより、zip ファイルが %temp%/vslogs.zipに出力されます。 そのファイルをフィードバックに添付してください。

関連コンテンツ