このトピックでは、Visual Studio デバッガーの生産性に関するいくつかのヒントとテクニックについて説明します。 デバッガーの基本的な機能については、「 デバッガーの最初の確認」を参照してください。 このトピックでは、機能ツアーに含まれていないいくつかの領域について説明します。
キーボード ショートカット
デバッグに関連する最も一般的なキーボード ショートカットの一覧については、「キーボード ショートカット」の 「デバッグ 」セクションを参照してください。
データ ヒントをピン留めする
デバッグ中にデータ ヒントを頻繁にポイントする場合は、変数のデータ ヒントをピン留めして、すばやくアクセスできるようにすることができます。 変数は再起動後も固定されたままです。 データ ヒントをピン留めするには、アイコンの上にカーソルを合わせた状態でピン アイコンをクリックします。 複数の変数をピン留めできます。
また、データ ヒントを拡張したままにする ( 固定データ ヒント)、データ ヒントを透明にするなど、他のいくつかの方法でデータ ヒントをカスタマイズすることもできます。 詳細については、 コード エディターでデータヒントのデータ値を表示するを参照してください。
コードを編集してデバッグを続行する (C#、VB、C++)
Visual Studio でサポートされているほとんどの言語では、デバッグ セッションの途中でコードを編集し、デバッグを続行できます。 この機能を使用するには、デバッガーで一時停止中にカーソルを置いてコードをクリックし、編集を行い、F5 、F10、または F11 を してデバッグを続行します。
機能の使用と機能の制限の詳細については、「 編集と続行」を参照してください。
XAML コードを編集してデバッグを続行する
デバッグ セッション中に XAML コードを変更するには、「XAML ホット リロードを使用して XAML コードを記述およびデバッグする」を参照してください。
再現が困難なデバッグの問題
アプリで特定の状態を再作成するのが困難な場合や時間がかかる場合は、条件付きブレークポイントの使用が役立つかどうかを検討してください。 条件付きブレークポイントとフィルター ブレークポイントを使用して、アプリが目的の状態 (変数が不適切なデータを格納している状態など) になるまでアプリ コードに侵入しないようにすることができます。 条件は、式、フィルター、ヒットカウントなどを使用して設定できます。
条件付きブレークポイントを作成するには
ブレークポイント アイコン (赤い球) を右クリックし、[ 条件] を選択します。
[ ブレークポイントの設定] ウィンドウで、式を入力します。
別の種類の条件に関心がある場合は、[ブレークポイントの設定] ダイアログ ボックスの [条件式] ではなく [フィルター] を選択し、フィルターのヒントに従います。
デバッガーに表示するデータを構成する
C#、Visual Basic、および C++ の場合 (C++/CLI コードのみ)、 DebuggerDisplay 属性を使用して表示する情報をデバッガーに通知できます。 C++ コードの場合は、 Natvis 視覚化を使用して同じ操作を実行できます。
同じアプリケーションに繰り返しアタッチする
プロセスへのアタッチ機能を使用している場合は、[デバッグ]、[プロセスへの再アタッチ] (>Alt+P) の順に選択することで+、以前にアタッチしたプロセスにすばやく再アタッチできます。 このコマンドを選択すると、デバッガーは、最初に前のプロセス ID の照合を試み、失敗した場合は前のプロセス名と一致させることで、アタッチした最後のプロセスへのアタッチをすぐに試みます。 一致が見つからない場合、または同じ名前のプロセスが複数ある場合は、[ プロセスにアタッチ ] ダイアログ ボックスが開き、適切なプロセスを選択できます。
スコープ外のオブジェクトを追跡する (C#、Visual Basic)
ウォッチ ウィンドウのようなデバッガー ウィンドウを使用すると、変数を簡単に表示できます。 ただし、[ ウォッチ ] ウィンドウで変数がスコープ外になると、その変数が淡色表示される場合があります。一部のアプリ シナリオでは、変数がスコープ外の場合でも変数の値が変わる可能性があり、注意深く監視したい場合があります (たとえば、変数がガベージ コレクションされる場合があります)。 変数を追跡するには、[ ウォッチ ] ウィンドウでオブジェクト ID を作成します。
オブジェクト ID を作成するには
追跡する変数の近くにブレークポイントを設定します。
デバッガー (F5) を起動し、ブレークポイントで停止します。
[ローカル] ウィンドウで変数を見つけて (Windows > ローカル>デバッグ)、変数を右クリックして [オブジェクト ID の作成] を選択します。
オブジェクト ID「CreateObjectID」を作成する
$ ウィンドウに、 [ローカル] ウィンドウを閉じます。 この変数はオブジェクト ID です。
オブジェクト ID 変数を右クリックし、[ ウォッチの追加] を選択します。
詳細については、「 オブジェクト ID の作成」を参照してください。
関数の戻り値を表示する
関数の戻り値を表示するには、コードのステップ実行中に [自動変数 ] ウィンドウに表示される関数を確認します。 関数の戻り値を確認するには、対象の関数が既に実行されていることを確認します (関数呼び出しで現在停止している場合は F10 キーを押します)。 ウィンドウが閉じている場合は、Windows > Autos >デバッグを使用して [自動変数] ウィンドウを開きます。
また、[ イミディエイト ] ウィンドウに関数を入力して戻り値を表示することもできます。 ( デバッグ > Windows > イミディエイトを使用して開きます)。
また、など、[ウォッチ] ウィンドウと [イミディエイト] ウィンドウで$ReturnValue
を使用することもできます。
ビジュアライザー内の文字列を検査する
文字列を操作する場合は、書式設定された文字列全体を表示すると便利です。 プレーン テキスト、XML、HTML、または JSON 文字列を表示するには、虫眼鏡アイコン をクリックし、文字列値を含む変数にカーソルを合わせます。
開く
文字列ビジュアライザーは、文字列の種類に応じて、文字列の形式が正しくないかどうかを調べるのに役立ちます。 たとえば、空白の Value フィールドは、文字列がビジュアライザー型で認識されていないことを示します。 詳細については、「 文字列ビジュアライザー」ダイアログ ボックスを参照してください。
デバッガー ウィンドウに表示される DataSet オブジェクトや DataTable オブジェクトなど、他のいくつかの種類の場合は、組み込みのビジュアライザーを開くこともできます。
メモリ使用量を分析する
ヒープのスナップショットを取得して比較し、メモリ使用量を最適化し、メモリ使用量ツールを使用してメモリ リークを見つけることができます。 詳細については、「 メモリ分析ツールの選択」を参照してください。
ダンプ ファイルを作成する
ダンプ ファイルは、実行中のプロセスと、ある時点でアプリに読み込まれたモジュールを示すスナップショットです。 ヒープ情報を含むダンプには、その時点でのアプリのメモリのスナップショットも含まれます。 ダンプは主に、開発者がアクセスできないマシンからの問題をデバッグするために使用されます。
ダンプ ファイルを保存する必要がある場合は、[ デバッグ] > [名前を付けてダンプを保存] を選択します。
ダンプ ファイルを分析するには、[ファイル] > [Visual Studio で開く] を選択します。 ダンプ ファイルを使用してデバッグを開始するには、[ マネージドのみでデバッグ]、[ ネイティブのみでデバッグ]、[ 混合でデバッグ]、または [マネージド メモリを使用してデバッグ] を選択します。
詳細については、「 ダンプ ファイル」を参照してください。
処理された例外のコードに分割する
デバッガーは、ハンドルされない例外が発生するとコードの実行を中断します。 ただし、処理された例外 ( try/catch
ブロック内で発生する例外など) もバグの原因になる可能性があり、発生した場合は調査が必要になる場合があります。 [ 例外設定] ダイアログ ボックスでオプションを構成することで、処理された例外のコードに分割するようにデバッガーを構成することもできます。
デバッグ > Windows > 例外設定を選択して、このダイアログ ボックスを開きます。
[ 例外設定] ダイアログ ボックスを使用すると、特定の例外に対してコードに分割するようにデバッガーに指示できます。 次の図では、System.NullReferenceException
が発生するたびにデバッガーがコードに割り込みます。 詳細については、 例外の管理を参照してください。
実行フローを変更する
デバッガーがコード行で一時停止したら、マウスを使用して、左側の黄色い矢印ポインターをグラブします。 黄色の矢印ポインターをコード実行パス内の別のポイントに移動します。 次に、F5 またはステップ コマンドを使用して、アプリの実行を続行します。
実行フローを変更することで、異なるコード実行パスをテストしたり、デバッガーを再起動せずにコードを再実行したりすることができます。 詳細については、「 実行ポインターを移動する」を参照してください。
Warnung
多くの場合、この機能に注意する必要があり、ヒントに警告が表示されます。 他の警告も表示される場合があります。 ポインターを移動しても、アプリを以前のアプリケーションの状態に戻すことはできません。
デッドロックと競合状態をデバッグする
マルチスレッド アプリに共通する問題の種類をデバッグする必要がある場合は、多くの場合、デバッグ中にスレッドの場所を表示するのに役立ちます。 これを簡単に行うには、[ ソースにスレッドを表示 ] ボタンを使用します。
ソース コードでスレッドを表示するには:
デバッグ中に、[デバッグ] ツール バーの [ソースにスレッドを表示] ボタン をクリックします。
ウィンドウの左側にある余白を見てください。 この行には、2本の布糸に似たスレッドマーカーアイコン
が表示されます。 スレッド マーカーは、スレッドがこの場所で停止していることを示します。
スレッド マーカーがブレークポイントによって部分的に隠されている可能性があることに注意してください。
ポインターをスレッド マーカーの上に置きます。 データヒントが表示されます。 DataTip は、停止した各スレッドの名前とスレッド ID 番号を示します。
[並列スタック] ウィンドウでスレッドの場所を表示することもできます。
デバッガーをアプリにアタッチする方法について理解を深める (C#、C++、Visual Basic、F#)
実行中のアプリにアタッチするために、デバッガーはデバッグしようとしているアプリとまったく同じビルド用に生成されたシンボル (.pdb) ファイルを読み込みます。 一部のシナリオでは、シンボル ファイルに関する少しの知識が役立ちます。 Visual Studio でシンボル ファイルを読み込む方法は、[ モジュール ] ウィンドウを使用して確認できます。
デバッグ中に [ モジュール ] ウィンドウを開くには、[ デバッグ] > [Windows > モジュール] を選択します。 [モジュール] ウィンドウには、デバッガーがユーザー コードまたはマイ コードとして扱っているモジュールと、モジュールのシンボル読み込み状態が表示されます。 ほとんどのシナリオでは、デバッガーはユーザー コードのシンボル ファイルを自動的に検索しますが、.NET コード、システム コード、またはサード パーティのライブラリ コードにステップ イン (またはデバッグ) する場合は、正しいシンボル ファイルを取得するために追加の手順が必要です。
右クリックして [シンボルの読み込み] を選択すると、[ モジュール ] ウィンドウからシンボル情報を直接 読み込むことができます。
場合によっては、アプリ開発者は、(フットプリントを減らすために) 一致するシンボル ファイルを含まないアプリを出荷しますが、リリースされたバージョンを後でデバッグできるように、ビルド用に一致するシンボル ファイルのコピーを保持します。
デバッガーがコードをユーザー コードとして分類する方法については、「 マイ コードのみ」を参照してください。 シンボル ファイルの詳細については、「 Visual Studio デバッガーでシンボル (.pdb) ファイルとソース ファイルを指定する」を参照してください。
詳細情報
その他のヒントやテクニック、詳細については、次のブログ記事を参照してください。