システム

【C#】DLLデバッグ入門：Visual Studio設定からプロセスアタッチまでブレークポイントを確実に止める方法

2025-04-30更新日: 2025-04-30

DLLをデバッグするには、ビルド設定をDebugにしてpdbを生成し、呼び出しアプリかプロセスにブレークポイントを張るだけで十分です。

ソリューション内に両方あるならスタートアップを実行側に設定し、単体ならプロジェクトのデバッグコマンドに実行ファイルを指定するか「プロセスにアタッチ」を選びます。

Just My Codeを無効にすればソースへ正確にステップインでき、配置先が同じならシンボルも自動で読み込まれます。

目次から探す

Debugビルドとシンボルファイルの基本
DLLと呼び出しアプリを同一ソリューションでデバッグ
DLL単体プロジェクトから外部EXEを起動してデバッグ
実行中プロセスにアタッチしてDLLをデバッグ
DLLが動的にロードされるケースのデバッグ
ブレークポイントを確実に止めるテクニック
例外設定でDLL内エラーを素早く捕捉
Just My CodeとSource Linkの設定
Visual Studioのウィンドウを使った効果的な確認方法
マルチスレッド環境でのDLLデバッグ
ネイティブコードと混在するDLLのデバッグ
リモートデバッグとクラウド環境
CI/CDでのデバッグ支援
よくあるトラブルシューティング
まとめ

Debugビルドとシンボルファイルの基本

C#でDLLをデバッグする際に最も重要なポイントの一つが、ビルド設定とシンボルファイルの管理です。

ここでは、Visual StudioでのDebugビルドの設定確認から、シンボルファイル(PDBファイル)の役割、さらにはReleaseビルドでのシンボル活用について詳しく解説します。

Debug設定の確認

Visual StudioでDLLプロジェクトをデバッグする場合、まずはビルド構成が「Debug」になっているかを確認しましょう。

Debugビルドは、デバッグに必要な情報を含むため、ブレークポイントが正しく機能し、ステップ実行や変数の監視が可能になります。

Debugビルドの確認手順

Visual Studioのメニューバーから「ビルド」→「構成マネージャー」を開きます。
「アクティブなソリューション構成」が「Debug」になっていることを確認します。
DLLプロジェクトの「ビルド」列にチェックが入っていることを確認します。
プロジェクトのプロパティを開き、「ビルド」タブで「出力パス」が適切に設定されているかも確認してください。

Debugビルドでは、最適化が無効化され、デバッグ用のシンボル情報が生成されます。

最適化が有効だと、コードの実行順序が変わったり、変数が最適化されてウォッチできなくなることがあるため、デバッグ時は必ず最適化をオフにしてください。

Debugビルドの設定例

Visual Studioのプロジェクトプロパティで「ビルド」タブを開くと、以下のような設定が確認できます。

「最適化を有効にする」：オフにする(チェックを外す)
「デバッグ情報の生成」：フルまたはpdb-onlyを選択
「出力パス」：通常はbin\Debug\など

これらの設定が正しくないと、ブレークポイントが効かない、ステップ実行ができないなどの問題が発生します。

PDBファイルとは

PDBファイル(Program Databaseファイル)は、Visual Studioが生成するデバッグシンボルファイルです。

DLLやEXEの実行ファイルに対応して作成され、ソースコードの行番号や変数名、関数名などの情報を含んでいます。

PDBファイルの役割

ブレークポイントの位置特定

実行ファイルのどの命令がソースコードのどの行に対応しているかを示します。

これにより、Visual Studioは正確にブレークポイントを設定できます。

コールスタックの表示

例外発生時やステップ実行時に、関数呼び出しの履歴をソースコードの関数名や行番号で表示します。

変数の値の表示

ローカル変数やパラメータの名前と値をデバッガーに提供し、ウォッチや即時ウィンドウでの評価を可能にします。

PDBファイルの配置場所

通常、PDBファイルはDLLと同じフォルダに配置されます。

Visual Studioのビルド設定で「出力パス」をDLLの出力先に設定しておくと、自動的にPDBファイルも同じ場所に生成されます。

もしPDBファイルが見つからない場合や、Visual Studioがシンボルを読み込めない場合は、以下の点を確認してください。

DLLとPDBのバージョンが一致しているか
Visual Studioの「ツール」→「オプション」→「デバッグ」→「シンボル」でPDBファイルのパスが正しく設定されているか
PDBファイルがビルド時に生成されているか

PDBファイルがないとどうなるか

PDBファイルがないと、Visual Studioはソースコードの行番号情報を取得できません。

そのため、ブレークポイントは「無効」になり、ステップ実行も正しく動作しません。

コールスタックもアドレス表示のみとなり、変数の値も表示できなくなります。

Releaseビルドでのシンボル活用

通常、Releaseビルドは最適化が有効で、デバッグ情報は生成されません。

しかし、場合によってはReleaseビルドでもデバッグを行いたいことがあります。

例えば、本番環境で発生した問題を再現して調査したい場合などです。

ReleaseビルドでPDBを生成する設定

Visual Studioのプロジェクトプロパティで、Release構成の「ビルド」タブを開き、以下の設定を行います。

「最適化を有効にする」：通常はオンのままにします(オフにするとパフォーマンスが落ちます)
「デバッグ情報の生成」：pdb-only または full に設定します

これにより、最適化は有効なままPDBファイルが生成され、ある程度のデバッグ情報が得られます。

Releaseビルドのデバッグの注意点

最適化によりコードの実行順序が変わるため、ステップ実行が直感的でない場合があります
変数がレジスタに割り当てられたり、最適化で消去されることがあるため、ウォッチできない変数が出てきます
インライン展開された関数はコールスタックに表示されないことがあります

ReleaseビルドでのPDB活用例

ReleaseビルドのPDBファイルを使うことで、例外発生時のスタックトレースにソースコードの行番号を表示したり、クラッシュダンプ解析時にシンボル情報を利用できます。

これにより、本番環境での問題解析が効率的になります。

以上のように、DebugビルドとPDBファイルの管理はDLLデバッグの基礎です。

Debugビルドでの開発中は必ずPDBファイルを生成し、DLLと同じ場所に配置してください。

Releaseビルドでも必要に応じてPDBを生成し、問題解析に役立てましょう。

これらの基本を押さえることで、Visual StudioでのDLLデバッグがスムーズに進みます。

DLLと呼び出しアプリを同一ソリューションでデバッグ

スタートアッププロジェクトの設定

Visual StudioでDLLと呼び出し元アプリケーションを同一ソリューションに含めてデバッグする場合、まずはスタートアッププロジェクトを正しく設定する必要があります。

スタートアッププロジェクトとは、デバッグ開始時に実行されるプロジェクトのことです。

ソリューションエクスプローラーで呼び出し元アプリケーションのプロジェクトを右クリックします。
メニューから「スタートアッププロジェクトに設定」を選択します。

これにより、デバッグ開始時に呼び出し元アプリケーションが起動し、その中でDLLが読み込まれます。

DLLプロジェクトはスタートアップには設定しません。

DLLはライブラリなので単独で実行できず、呼び出し元アプリケーションのプロセス内で動作します。

複数のスタートアッププロジェクトを同時に起動したい場合は、ソリューションのプロパティから「複数のスタートアッププロジェクト」を選択し、必要なプロジェクトを「開始」に設定しますが、DLLのデバッグでは通常呼び出し元アプリケーションのみをスタートアップに設定します。

出力パスの共有

DLLプロジェクトのビルド出力(DLLファイルとPDBファイル)が呼び出し元アプリケーションの実行ファイルと同じフォルダに配置されていることが重要です。

これにより、呼び出し元アプリケーションが最新のDLLを読み込み、Visual Studioが正しいシンボル情報を参照できます。

DLLプロジェクトのプロパティを開き、「ビルド」タブの「出力パス」を呼び出し元アプリケーションの出力ディレクトリに設定します。

例えば、呼び出し元アプリケーションの出力パスがbin\Debug\であれば、DLLプロジェクトの出力パスも同じbin\Debug\に設定します。

この設定により、DLLのビルド時にDLLファイルとPDBファイルが呼び出し元アプリケーションの実行フォルダにコピーされます。

Visual StudioはこのフォルダからDLLを読み込み、PDBファイルを使ってデバッグ情報を取得します。

プロジェクト	出力パス例
呼び出し元アプリ	`bin\Debug\`
DLLプロジェクト	`bin\Debug\`(共有)

もし出力パスが異なる場合、呼び出し元アプリケーションが古いDLLを読み込んでしまい、ブレークポイントが効かないことがあります。

出力パスの共有はDLLデバッグの基本です。

ブレークポイントとステップ実行

呼び出し元アプリケーションとDLLが同一ソリューション内で正しく設定されていると、Visual StudioのブレークポイントはDLLのソースコード上でも有効になります。

DLLの関数に呼び出しがあると、設定したブレークポイントでプログラムが停止し、ステップ実行や変数の監視が可能です。

ブレークポイントが効かない場合のチェックポイント

DLLのPDBファイルが呼び出し元アプリケーションの実行フォルダに存在しているか
DLLプロジェクトがDebugビルドでビルドされているか
Visual Studioの「マイコードのみを有効にする」設定がオフになっているか(外部コードのステップインを許可)
ブレークポイントが赤い丸で中抜きになっていないか(無効状態)

ステップ実行のポイント

呼び出し元アプリケーションのコードからDLLの関数にステップインすると、DLLのソースコードに移動して詳細な処理を追えます。

逆にステップアウトすると呼び出し元に戻ります。

また、ブレークポイントに条件を設定して特定の状況でのみ停止させたり、ヒットカウントを指定して複数回目の呼び出しで停止させることも可能です。

これにより複雑な処理の中でも効率的にデバッグできます。

サンプルコード例

以下は、同一ソリューション内に呼び出し元アプリケーションとDLLがある場合の簡単な例です。

// DLLプロジェクト内のクラス
public class Calculator
{
    // 足し算を行うメソッド
    public int Add(int a, int b)
    {
        // ここにブレークポイントを設定可能
        return a + b;
    }
}
// 呼び出し元アプリケーションのMainメソッド
class Program
{
    static void Main(string[] args)
    {
        Calculator calc = new Calculator();
        int result = calc.Add(3, 5);
        System.Console.WriteLine($"計算結果: {result}");
    }
}

この例では、CalculatorクラスのAddメソッドにブレークポイントを設定し、呼び出し元のMainメソッドからステップインできます。

DLLのPDBファイルが正しく配置されていれば、Visual StudioはAddメソッドの中で停止し、変数aやbの値をウォッチできます。

計算結果: 8

このように、同一ソリューション内でDLLと呼び出し元アプリケーションを管理し、スタートアッププロジェクトと出力パスを適切に設定することで、DLLのブレークポイントが確実に機能し、効率的なデバッグが可能になります。

DLL単体プロジェクトから外部EXEを起動してデバッグ

コマンドパスの指定方法

DLL単体のプロジェクトから外部の実行ファイル(EXE)を起動してデバッグする場合、Visual Studioのプロジェクトプロパティで「デバッグ」タブを開き、「コマンド」欄に呼び出し元となるEXEのパスを指定します。

具体的には以下の手順で設定します。

ソリューションエクスプローラーでDLLプロジェクトを右クリックし、「プロパティ」を選択します。
「デバッグ」タブを開きます。
「コマンド」欄に、呼び出し元EXEのフルパスを入力します。例：C:\Projects\MyApp\bin\Debug\MyApp.exe
必要に応じて「コマンド引数」や「作業ディレクトリ」も設定します。

この設定により、DLLプロジェクトのデバッグ開始時に指定したEXEが起動し、そのプロセス内でDLLが読み込まれます。

Visual StudioはDLLのPDBファイルを参照してブレークポイントを有効にします。

パスは絶対パスでも相対パスでも構いませんが、相対パスの場合はDLLプロジェクトのディレクトリを基準に解釈されるため注意してください。

引数と作業ディレクトリの設定

呼び出し元EXEにコマンドライン引数を渡したい場合は、「デバッグ」タブの「コマンド引数」欄に入力します。

複数の引数はスペースで区切ります。

また、EXEの実行時の作業ディレクトリを指定することも重要です。

作業ディレクトリは、EXEがファイルを相対パスで参照する際の基準となるフォルダです。

ここを正しく設定しないと、ファイル読み込みエラーや設定ファイルの不一致が発生することがあります。

作業ディレクトリは「作業ディレクトリ」欄にフルパスまたは相対パスで指定します。

通常は呼び出し元EXEの出力フォルダ(例：bin\Debug)を指定します。

設定項目	内容例
コマンド	`C:\Projects\MyApp\bin\Debug\MyApp.exe`
コマンド引数	`-config config.json -verbose`
作業ディレクトリ	`C:\Projects\MyApp\bin\Debug`

これらの設定を正しく行うことで、DLLを呼び出すEXEが期待通りに起動し、DLLのブレークポイントで停止できる環境が整います。

ブレークが止まらないときのチェックリスト

DLLのブレークポイントが効かずに止まらない場合、以下のポイントを順に確認してください。

PDBファイルの存在と一致

DLLのPDBファイルが呼び出し元EXEの実行フォルダに存在し、DLLのバージョンと一致しているか確認します。

ビルド後にDLLやPDBが古いものに差し替わっていないかも注意してください。

Debugビルドであること

DLLプロジェクトがDebug構成でビルドされているか確認します。

Releaseビルドでは最適化によりブレークポイントが効かないことがあります。

Visual Studioのシンボル設定

「ツール」→「オプション」→「デバッグ」→「シンボル」で、PDBファイルのパスが正しく設定されているか確認します。

必要に応じてシンボルキャッシュをクリアしてください。

マイコードのみの設定

Visual Studioの「デバッグ」→「オプション」→「デバッグ」→「全般」で「マイコードのみを有効にする」がオンになっていると、外部DLLのコードにステップインできません。

これをオフにしてみてください。

DLLが正しく読み込まれているか

デバッグ中に「モジュール」ウィンドウを開き、対象DLLが読み込まれているか確認します。

読み込まれていなければ、呼び出し元EXEがDLLを参照していない可能性があります。

32bit/64bitの不一致

呼び出し元EXEとDLLのプラットフォームターゲット(x86/x64/AnyCPU)が一致しているか確認します。

異なる場合、デバッグが正常に動作しません。

ブレークポイントの状態

ブレークポイントが赤い丸で中抜き(無効)になっていないか確認します。

無効の場合はシンボルが読み込まれていないか、ソースコードとDLLの不整合が考えられます。

キャッシュやビルドのクリーン

ビルドのクリーンと再ビルドを行い、古いDLLやPDBが残っていないか確認します。

Visual Studioのキャッシュが影響することもあるため、IDEの再起動も試してください。

これらのチェックを行うことで、多くの場合ブレークポイントが効かない問題を解決できます。

特にPDBファイルの配置とビルド構成の整合性は最重要ポイントです。

実行中プロセスにアタッチしてDLLをデバッグ

アタッチ手順の流れ

Visual Studioで既に実行中のプロセスにアタッチしてDLLをデバッグする場合、以下の手順で操作します。

Visual Studioを起動し、DLLのソースコードが含まれるプロジェクトを開きます。プロジェクトはDebugビルドであることを確認してください。
メニューバーの「デバッグ」から「プロセスにアタッチ」を選択します。
「プロセスにアタッチ」ダイアログが表示されるので、デバッグ対象のプロセスを一覧から探します。プロセス名やPID(プロセスID)を参考に選択してください。
必要に応じて「表示するプロセスの種類」を「すべてのプロセス」や「マネージコード」などに切り替え、対象プロセスが見つかりやすいようにします。
対象プロセスを選択し、「アタッチ」ボタンをクリックします。
アタッチが成功すると、Visual Studioのデバッガーがそのプロセスに接続されます。DLLのPDBファイルが正しく読み込まれていれば、DLL内のブレークポイントで停止可能です。
ブレークポイントを設定し、動作を確認します。必要に応じてステップ実行や変数ウォッチを行います。

この方法は、すでに起動しているアプリケーションやサービスに対して後からデバッグを行いたい場合に有効です。

シンボルが読み込まれないときの対処

アタッチ後にDLLのブレークポイントが無効(中抜きの赤丸)になったり、「シンボルが読み込まれていません」というメッセージが表示される場合は、以下の点を確認してください。

PDBファイルの場所

DLLのPDBファイルが実行中のプロセスが読み込んでいるDLLと同じバージョンで、かつアクセス可能な場所にあるか確認します。

通常はDLLと同じフォルダに配置します。

Visual Studioのシンボル設定

「ツール」→「オプション」→「デバッグ」→「シンボル」で、PDBファイルのパスが正しく設定されているか確認します。

必要に応じてシンボルキャッシュをクリアし、再読み込みを試みます。

モジュールウィンドウの確認

「デバッグ」→「ウィンドウ」→「モジュール」を開き、対象DLLが読み込まれているか、シンボルが読み込まれているかを確認します。

読み込まれていない場合は、右クリックメニューから「シンボルの読み込み」を手動で行います。

ビルド構成の整合性

DLLがDebugビルドでビルドされているか、実行中のDLLとソースコードが一致しているかを確認します。

バージョン違いがあるとシンボルが一致しません。

32bit/64bitの不一致

Visual Studioのデバッガーが対象プロセスのプラットフォーム(x86/x64)に対応しているか確認します。

異なる場合はアタッチできてもシンボルが正しく読み込まれません。

これらの対処を行うことで、シンボルの読み込み問題を解決し、DLLのブレークポイントを有効にできます。

サービスやIISプロセスへのアタッチ

WindowsサービスやIIS(Internet Information Services)で動作しているプロセスに対してDLLのデバッグを行う場合、通常のアタッチ手順に加えていくつか注意点があります。

サービスへのアタッチ

サービスは管理者権限で実行されていることが多いため、Visual Studioも管理者権限で起動してください。そうしないとサービスプロセスにアタッチできません
サービスのプロセス名はsvchost.exeやサービス名そのものの場合があります。サービスのPIDをタスクマネージャーやsc queryexコマンドで調べてからアタッチすると確実です
サービスが起動していない場合は、サービス管理ツールやコマンドで起動してからアタッチします

IISプロセスへのアタッチ

IISのワーカープロセスは通常w3wp.exeという名前です。複数のアプリケーションプールがある場合は、どのw3wp.exeが対象かPIDで特定してください
IISのアプリケーションプールが64bitか32bitかを確認し、Visual Studioのデバッガーも対応したモードで起動します
IISのプロセスにアタッチする前に、対象のWebアプリケーションをリクエストしてプロセスを起動させておくとよいです
IISの設定で「デバッグを有効にする」オプションがある場合はオンにしてください
Visual Studioを管理者権限で起動し、「プロセスにアタッチ」から対象のw3wp.exeを選択してアタッチします

これらのポイントを押さえることで、サービスやIIS上で動作するDLLのデバッグが可能になります。

特に権限周りとプロセスの特定が重要です。

DLLが動的にロードされるケースのデバッグ

Reflectionロードの検出

C#アプリケーションでは、System.Reflection名前空間の機能を使ってDLLを動的にロードすることがあります。

例えば、Assembly.LoadやAssembly.LoadFrom、Assembly.LoadFileなどのメソッドを使うケースです。

このような動的ロードは、通常の静的参照とは異なり、Visual Studioの標準的なデバッグ設定だけではDLLの読み込みタイミングやブレークポイントの有効化が難しくなります。

動的にロードされるDLLをデバッグする際は、まずどのタイミングでDLLがロードされているかを検出することが重要です。

これには以下の方法があります。

AppDomain.AssemblyLoadイベントの利用

アプリケーションのAppDomainに対してAssemblyLoadイベントを登録すると、DLLがロードされるたびに通知を受け取れます。

これにより、動的にロードされたDLLの名前やパスをログに出力して確認できます。

Visual Studioのモジュールウィンドウの活用

デバッグ中に「デバッグ」→「ウィンドウ」→「モジュール」を開くと、現在読み込まれているDLLの一覧が表示されます。

動的にロードされたDLLもここに表示されるため、ロード状況をリアルタイムで監視できます。

ログ出力の追加

動的ロードを行うコードにログを埋め込み、どのDLLがいつロードされたかを記録する方法も有効です。

AssemblyLoadイベントのサンプルコード

using System;
using System.Reflection;
class Program
{
    static void Main()
    {
        AppDomain.CurrentDomain.AssemblyLoad += OnAssemblyLoad;
        // 動的にDLLをロード
        Assembly asm = Assembly.LoadFrom("MyDynamicLibrary.dll");
        Console.WriteLine("DLLをロードしました。");
    }
    private static void OnAssemblyLoad(object sender, AssemblyLoadEventArgs args)
    {
        Console.WriteLine($"Assemblyロード検出: {args.LoadedAssembly.FullName}");
    }
}

Assemblyロード検出: MyDynamicLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
DLLをロードしました。

このように、AssemblyLoadイベントを使うと、動的にロードされたDLLの検出が容易になります。

AssemblyResolveハンドラの活用

動的ロード時にDLLが見つからない場合、AppDomain.AssemblyResolveイベントを利用してカスタムの解決処理を実装できます。

これにより、DLLのパスが標準の検索パスにない場合でも、任意の場所からDLLを読み込むことが可能です。

AssemblyResolveイベントは、アセンブリのロードに失敗した際に発生し、イベントハンドラで適切なAssemblyオブジェクトを返すことで解決します。

AssemblyResolveイベントの設定例

using System;
using System.IO;
using System.Reflection;
class Program
{
    static void Main()
    {
        AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve;
        // 動的にDLLをロード(パスが標準外)
        Assembly asm = Assembly.Load("MyDynamicLibrary");
        Console.WriteLine("DLLをロードしました。");
    }
    private static Assembly OnAssemblyResolve(object sender, ResolveEventArgs args)
    {
        Console.WriteLine($"AssemblyResolve発生: {args.Name}");
        // DLLのカスタムパスを指定
        string assemblyPath = Path.Combine(@"C:\CustomLibs", new AssemblyName(args.Name).Name + ".dll");
        if (File.Exists(assemblyPath))
        {
            return Assembly.LoadFrom(assemblyPath);
        }
        return null; // 解決できなければnullを返す
    }
}

AssemblyResolve発生: MyDynamicLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
DLLをロードしました。

この方法を使うと、動的ロード時のDLLの場所を柔軟に制御でき、デバッグ時にDLLの読み込み失敗を防げます。

デバッガーのローディングイベント

Visual Studioのデバッガーは、DLLがロードされるタイミングで通知を受け取ることができます。

これを利用して、動的にロードされるDLLのデバッグを効率化できます。

モジュールウィンドウの活用

「デバッグ」→「ウィンドウ」→「モジュール」では、ロードされたDLLの一覧が表示され、シンボルの読み込み状況も確認できます。

動的ロードされたDLLが表示されたら、右クリックで「シンボルの読み込み」を手動で行うことも可能です。

ブレークポイントの設定

DLLがロードされる前にブレークポイントを設定できない場合は、AppDomain.AssemblyLoadイベントやAssemblyResolveイベントのハンドラ内にブレークポイントを置く方法があります。

これにより、DLLロード直後の処理を捕捉できます。

デバッガーのイベントハンドラ

Visual Studioの拡張機能やマクロを使い、DLLロード時に自動的に特定の処理を行うことも可能ですが、通常はモジュールウィンドウの監視と手動操作で十分です。

ロードイベントでのブレークポイント例

AppDomain.CurrentDomain.AssemblyLoad += (sender, e) =>
{
    System.Diagnostics.Debugger.Break(); // DLLロード時にブレーク
};

このコードをDLLをロードする前に実行しておくと、DLLがロードされるタイミングでデバッガーが停止し、詳細な調査が可能になります。

動的にロードされるDLLは、通常の静的参照とは異なるため、ロードタイミングの把握やシンボルの読み込み管理が重要です。

AssemblyLoadやAssemblyResolveイベントを活用し、Visual Studioのモジュールウィンドウと組み合わせることで、動的ロードDLLのデバッグを効果的に行えます。

ブレークポイントを確実に止めるテクニック

条件付きブレークポイント

条件付きブレークポイントは、特定の条件が満たされたときだけプログラムの実行を停止させる機能です。

大量のループや頻繁に呼び出されるメソッド内で、特定の変数の値や状態に応じて停止したい場合に非常に便利です。

条件付きブレークポイントの設定方法

ブレークポイントを設定したい行の左側の余白をクリックしてブレークポイントを設置します。
ブレークポイントの赤い丸を右クリックし、「条件(C)…」を選択します。
「条件」ダイアログで、停止させたい条件式を入力します。C#の式で記述し、例えばcount == 10やuserName == "admin"などが指定可能です。
「OK」をクリックして条件を保存します。

class Program
{
    static void Main()
    {
        for (int i = 0; i < 100; i++)
        {
            // ここに条件付きブレークポイントを設定
            Console.WriteLine($"ループカウンタ: {i}");
        }
    }
}

この例で、i == 50という条件付きブレークポイントを設定すると、ループが50回目に達したときだけ停止します。

ループカウンタ: 0
...
ループカウンタ: 49
// ここで停止
ループカウンタ: 50
...

条件付きブレークポイントを使うことで、無駄な停止を避け、効率的にデバッグできます。

ヒットカウントとフィルター

ヒットカウントは、ブレークポイントが何回目のヒット(到達)で停止するかを指定する機能です。

例えば、100回目の呼び出しで停止したい場合に使います。

フィルターは、特定のスレッドやプロセス、マシンでのみブレークポイントを有効にする設定です。

ヒットカウントの設定方法

ブレークポイントを右クリックし、「ヒットカウント(H)…」を選択します。
「ヒットカウント」ダイアログで以下のいずれかを選択します。

「等しい」：指定した回数に達したときに停止
「大なりまたは等しい」：指定回数以上で停止
「毎」：指定回数ごとに停止(例：10回ごと)

回数を入力し、「OK」をクリックします。

フィルターの設定方法

ブレークポイントを右クリックし、「フィルター(F)…」を選択します。
「フィルター」ダイアログで、以下の条件を指定できます。

プロセスID(PID)
スレッドID
マシン名

条件を入力し、「OK」をクリックします。

class Program
{
    static void Main()
    {
        for (int i = 0; i < 1000; i++)
        {
            Console.WriteLine($"処理番号: {i}");
        }
    }
}

このコードで、ヒットカウントを「毎100回」に設定すると、100回、200回、300回…のタイミングで停止します。

フィルターはマルチスレッドや複数プロセスが関わる環境で特定のスレッドだけを対象にしたい場合に有効です。

アクション付きブレークポイント

アクション付きブレークポイントは、停止せずに特定のメッセージを出力したり、カスタムのスクリプトを実行したりできるブレークポイントです。

プログラムの動作を妨げずに状態を監視したい場合に役立ちます。

アクション付きブレークポイントの設定方法

ブレークポイントを右クリックし、「アクション(A)…」を選択します。
「アクション」ダイアログで、出力したいメッセージを入力します。変数の値を表示したい場合は{変数名}の形式で埋め込み可能です。
「実行を停止する」のチェックを外すと、停止せずにメッセージだけ出力します。
「OK」をクリックして設定を保存します。

class Program
{
    static void Main()
    {
        for (int i = 0; i < 5; i++)
        {
            // ここにアクション付きブレークポイントを設定
            Console.WriteLine($"カウンタ: {i}");
        }
    }
}

例えば、i={i}というメッセージをアクションとして設定し、「実行を停止する」のチェックを外すと、ブレークポイントで停止せずに出力ウィンドウに以下のように表示されます。

i=0
i=1
i=2
i=3
i=4

これにより、プログラムの流れを妨げずに変数の値を追跡でき、パフォーマンスに影響を与えずにデバッグが可能です。

これらのテクニックを活用することで、ブレークポイントをより柔軟かつ確実に活用でき、効率的なデバッグが実現します。

条件付きブレークポイントやヒットカウント、アクション付きブレークポイントは特に複雑な処理や大量のループ処理の中で威力を発揮します。

例外設定でDLL内エラーを素早く捕捉

例外設定ダイアログの使い方

Visual Studioでは、例外が発生した際にプログラムの実行を自動的に停止させるための「例外設定」機能があります。

DLL内で発生したエラーを素早く捕捉し、原因を特定するためにこの機能を活用しましょう。

例外設定ダイアログは以下の手順で開きます。

メニューバーの「デバッグ」→「例外設定」を選択します。

または、ショートカットキーCtrl + Alt + Eでも開けます。

「例外設定」ウィンドウが表示され、例外の種類ごとにチェックボックスが並んでいます。
ここで、捕捉したい例外の種類にチェックを入れます。例えば、「Common Language Runtime Exceptions(マネージ例外)」や「C++ Exceptions(ネイティブ例外)」などがあります。
チェックを入れた例外が発生すると、Visual Studioは例外発生時点でプログラムを停止し、スタックトレースや変数の状態を確認できます。

例外設定は細かく分類されており、特定の例外タイプだけを捕捉することも可能です。

例えば、System.NullReferenceExceptionだけを捕捉したい場合は、例外設定ウィンドウの検索ボックスに例外名を入力して絞り込み、該当例外にチェックを入れます。

最初のチャンス例外を有効にする

例外には「最初のチャンス例外(First Chance Exception)」と「二度目のチャンス例外(Second Chance Exception)」があります。

最初のチャンス例外は、例外が発生した直後にデバッガーが通知を受けるもので、プログラム内でキャッチされる前の状態です。

最初のチャンス例外を有効にすると、例外が発生した瞬間に停止できるため、例外がどこで発生したかを詳細に調査できます。

これにより、例外がキャッチされて処理される前の状態を確認でき、原因の特定が容易になります。

最初のチャンス例外の有効化方法

例外設定ウィンドウで、捕捉したい例外のチェックボックスをオンにします。
チェックボックスの右側にある「最初のチャンス例外を停止する」オプションが有効になります。
これにより、例外が発生した時点でプログラムが停止し、スタックトレースやローカル変数の状態を確認できます。

注意点として、最初のチャンス例外を有効にすると、例外が頻繁に発生する場合はデバッグが頻繁に停止し、作業が煩雑になることがあります。

必要な例外だけに絞って設定することをおすすめします。

マネージ／ネイティブ混在例外の扱い

C#のDLLを含むアプリケーションでは、マネージコード(.NET)とネイティブコード(C++など)が混在することがあります。

この場合、例外もマネージ例外とネイティブ例外が混在し、それぞれの例外設定を適切に行う必要があります。

マネージ例外の設定

「Common Language Runtime Exceptions」にチェックを入れることで、マネージコード内の例外を捕捉できます
例外の種類を細かく指定して、特定の例外だけを捕捉することも可能です

ネイティブ例外の設定

「C++ Exceptions」や「Win32 Exceptions」などの項目にチェックを入れて、ネイティブコードの例外を捕捉します
ネイティブ例外は、アクセス違反(Access Violation)やスタックオーバーフローなど、マネージコードでは捕捉できない例外が含まれます

混在デバッグのポイント

Visual Studioのデバッグ設定で「マネージコードとネイティブコードの両方をデバッグする」オプションを有効にします

これは、プロジェクトのプロパティの「デバッグ」タブで「ネイティブコードのデバッグを有効にする」にチェックを入れることで設定できます。

混在環境では、例外がどちらのコードで発生しているかを正確に把握し、適切な例外設定を行うことが重要です
ネイティブ例外はマネージ例外とは異なり、例外の詳細情報が少ない場合があるため、クラッシュダンプ解析やネイティブデバッガーの活用も検討してください

これらの例外設定を活用することで、DLL内で発生するエラーを素早く検出し、原因の特定や修正を効率的に行えます。

特に最初のチャンス例外の活用とマネージ／ネイティブ混在環境での適切な設定は、複雑なデバッグシナリオで効果を発揮します。

Just My CodeとSource Linkの設定

Just My Codeのオン・オフで変わる挙動

Visual Studioの「Just My Code(JMC)」機能は、ユーザーが書いたコード(自分のコード)にフォーカスしてデバッグを行うための設定です。

JMCがオンの場合、Visual Studioは外部ライブラリやフレームワークのコードを「外部コード」として扱い、ステップインやブレークポイントの挙動を制限します。

Just My Codeがオンの状態

ステップインの制限

自分のコード以外(外部DLLやフレームワークのコード)にはステップインできません。

これにより、デバッグ時に不要な外部コードの詳細に入り込むことを防ぎ、効率的に自分のコードの問題に集中できます。

ブレークポイントの挙動

外部コード内のブレークポイントは無効化されるか、停止しないことがあります。

自分のコード内のブレークポイントは通常通り機能します。

例外の扱い

例外が外部コードで発生しても、JMCがオンだと停止しない場合があります。

自分のコードに影響がある例外のみを捕捉する動作になります。

Just My Codeがオフの状態

ステップインの自由度

外部コードにも自由にステップインでき、詳細な処理を追跡可能です。

特に、外部ライブラリの動作を理解したい場合や、DLLのソースコードがある場合に有効です。

ブレークポイントの有効化

外部コード内のブレークポイントも有効になり、停止できます。

例外の捕捉範囲拡大

外部コードで発生した例外も捕捉し、デバッグが可能です。

JMCの設定場所

Visual Studioのメニューから「ツール」→「オプション」→「デバッグ」→「全般」にある「Just My Codeを有効にする」のチェックボックスでオン・オフを切り替えられます。

外部コードでのステップイン許可

JMCがオンの場合でも、特定の外部コードにステップインしたいケースがあります。

例えば、自分でビルドしたDLLのソースコードがある場合や、外部ライブラリのソースを参照したい場合です。

ステップインを許可する方法

シンボルの読み込みを確認

外部DLLのPDBファイルが正しく読み込まれていることが前提です。

Visual Studioの「デバッグ」→「ウィンドウ」→「モジュール」で対象DLLのシンボルが読み込まれているか確認します。

JMCの例外設定

「ツール」→「オプション」→「デバッグ」→「全般」で「Just My Codeを有効にする」をオフにするのが最も確実ですが、オンのままでも「外部コードのステップインを許可する」設定を利用できます。

ソースサーバーやSource Linkの活用

ソースコードがリモートにある場合、Source Linkを使ってソースを取得し、外部コードのステップインを可能にします。

ブレークポイントの手動設定

外部コードのソースファイルを開き、ブレークポイントを設定すると停止することがあります。

注意点

JMCをオフにすると、デバッグ時に大量の外部コードに入り込む可能性があり、デバッグが煩雑になることがあります。

必要な範囲で設定を切り替えるのが望ましいです。

Source Linkでリモートリポジトリからシンボル取得

Source Linkは、Visual Studioの機能で、ビルド時にソースコードのリモートリポジトリ(GitHubやAzure DevOpsなど)へのリンク情報をPDBファイルに埋め込みます。

これにより、デバッグ時にリモートのソースコードを自動的に取得し、外部DLLの詳細なコードを参照できます。

Source Linkの仕組み

ビルド時にPDBファイルにリモートリポジトリのURLやコミットIDなどの情報が埋め込まれます
デバッグ時にVisual StudioがPDBを読み込み、必要なソースファイルをリモートからダウンロードします
ソースコードがローカルにない場合でも、リモートの正確なバージョンのコードを表示できます

Source Linkの有効化方法

プロジェクトのcsprojファイルにSource Linkパッケージを追加します。例えば、GitHubの場合はMicrosoft.SourceLink.GitHubをNuGetでインストールします。
ビルド時にSource Linkが有効になるように設定します。通常はパッケージを追加するだけで有効です。
Visual Studioの「ツール」→「オプション」→「デバッグ」→「全般」で「ソースリンクを有効にする」にチェックを入れます。
シンボル設定で、Microsoftのシンボルサーバーやカスタムシンボルサーバーを指定し、PDBファイルを取得できるようにします。

Source Link利用時のメリット

外部DLLのソースコードをローカルに持っていなくても、正確なソースを参照できます
バージョン管理されたソースコードとデバッグ情報が一致するため、誤差のないデバッグが可能です
チーム開発やオープンソースライブラリのデバッグに非常に便利

注意点

リモートリポジトリが公開されている必要があります。プライベートリポジトリの場合は認証設定が必要です
ネットワーク環境によってはソース取得に時間がかかることがあります

Just My Codeの設定とSource Linkの活用を組み合わせることで、DLLのデバッグ効率が大幅に向上します。

JMCで自分のコードに集中しつつ、必要に応じて外部コードの詳細を参照し、Source Linkでリモートソースをシームレスに取得できる環境を整えましょう。

Visual Studioのウィンドウを使った効果的な確認方法

Call Stackでスタックフレームを追う

Call Stackウィンドウは、現在の実行中のスレッドにおける関数呼び出しの履歴を表示します。

デバッグ中に例外が発生したり、ブレークポイントで停止した際に、どの関数から現在の関数が呼び出されたかを確認できるため、問題の発生箇所を特定するのに非常に役立ちます。

Call Stackの基本操作

Visual Studioのメニューから「デバッグ」→「ウィンドウ」→「コールスタック」を選択して表示します
一番上のスタックフレームが現在実行中の関数です。下に行くほど呼び出し元の関数になります
スタックフレームをダブルクリックすると、その関数のソースコードの該当行にジャンプします
複数スレッドがある場合は、スレッドごとにCall Stackを切り替えて確認できます

Call Stackの活用例

void Main()
{
    MethodA();
}
void MethodA()
{
    MethodB();
}
void MethodB()
{
    // ここでブレークポイントを設定
    int x = 10;
}

MethodBでブレークポイントがヒットしたとき、Call StackにはMethodB → MethodA → Mainの順に表示されます。

これにより、どの経路でこの関数に到達したかが一目でわかります。

WatchとQuickWatchによる変数ウォッチ

Watchウィンドウは、デバッグ中に特定の変数や式の値を監視するための機能です。

複数の変数を登録しておくことで、プログラムの状態を継続的に確認できます。

Watchウィンドウの使い方

「デバッグ」→「ウィンドウ」→「ウォッチ」→「ウォッチ1」などを選択して表示します
監視したい変数名や式を入力します。例えば、countやmyObject.Property、list.Countなどが指定可能です
実行をステップ実行すると、変数の値がリアルタイムで更新されます

QuickWatchの使い方

ソースコード上で変数や式を選択し、右クリックメニューから「クイックウォッチ」を選択します
ポップアップウィンドウで変数の詳細な値やプロパティを確認できます
その場で式を編集して評価することも可能です

WatchとQuickWatchの違い

機能	Watchウィンドウ	QuickWatch
利用方法	常に表示して複数の変数を監視可能	一時的に変数や式を確認するためのポップアップ
登録数	複数の変数や式を登録可能	1回の操作で1つの変数や式を評価
評価の編集	可能	可能

Immediate Windowでの式評価

Immediate Windowは、デバッグ中に任意の式を評価したり、メソッドを呼び出したりできる強力なツールです。

変数の値を調べるだけでなく、コードの一部を実行して動的に状態を変更することも可能です。

Immediate Windowの使い方

「デバッグ」→「ウィンドウ」→「即時ウィンドウ」を選択して表示します
変数名や式を入力してEnterキーを押すと、その結果が表示されます
例えば、myList.CountやmyObject.ToString()などを評価できます
代入文も実行可能で、count = 100のように変数の値を変更できます

int count = 5;
// ブレークポイントで停止中にImmediate Windowで以下を入力
count + 10

このように、即時ウィンドウはデバッグ中の柔軟な操作に役立ちます。

AutosとLocalsの違い

AutosとLocalsはどちらもデバッグ中に変数の値を表示するウィンドウですが、表示される内容に違いがあります。

ウィンドウ名	表示内容の特徴
Autos	現在の行と直前の行で使用されている変数や式を自動的に表示。必要最低限の変数を絞って表示するため、状況に応じた変数の値を効率的に確認できます。
Locals	現在のスコープ(メソッドやブロック)内のすべてのローカル変数とパラメータを表示。変数が多い場合は一覧が長くなるが、全体を把握しやすい。

使い分けのポイント

Autosは、現在のコードの流れに関連する変数だけを自動で表示するため、素早く重要な変数の値を確認したいときに便利です
Localsは、スコープ内のすべての変数を網羅的に確認したい場合に使います。特に複雑なメソッド内で全体の状態を把握したいときに役立ちます

これらのVisual Studioのウィンドウを効果的に使い分けることで、DLLのデバッグ時にプログラムの状態を詳細かつ効率的に把握できます。

スタックの流れを追い、必要な変数を監視し、即時に式を評価することで、問題の原因を素早く特定できるようになります。

マルチスレッド環境でのDLLデバッグ

スレッドウィンドウの基本操作

マルチスレッド環境でDLLをデバッグする際、Visual Studioの「スレッド」ウィンドウは非常に重要なツールです。

このウィンドウでは、現在のプロセス内で動作しているすべてのスレッドの一覧を確認でき、スレッドの状態やスタックトレースを個別に追跡できます。

スレッドウィンドウの表示方法

デバッグ中にメニューから「デバッグ」→「ウィンドウ」→「スレッド」を選択します
または、ショートカットキーCtrl + Alt + Hで開けます

スレッドウィンドウの主な機能

スレッド一覧の表示

スレッドID、名前(設定されていれば)、状態(実行中、停止中、待機中など)が一覧で表示されます。

スレッドの切り替え

任意のスレッドを選択して右クリックし、「スレッドの切り替え」を選ぶと、そのスレッドのコンテキストに切り替わり、Call Stackや変数の内容がそのスレッドの状態に更新されます。

スレッドの名前変更

スレッドにわかりやすい名前を付けることができ、複雑なマルチスレッド環境での識別が容易になります。

スレッドを右クリックして「名前の変更」を選択します。

スレッドの停止・再開

特定のスレッドを一時停止させたり、再開させたりすることも可能です。

これにより、問題のあるスレッドだけを集中して調査できます。

スレッドウィンドウ活用例

例えば、複数のスレッドが同時に動作している場合、問題のあるスレッドを特定し、そのスレッドのCall Stackを確認して原因を追跡できます。

Parallel Stacksでの可視化

Visual Studioの「Parallel Stacks」ウィンドウは、マルチスレッドのコールスタックを視覚的に表示し、スレッド間の関係や並行処理の流れを把握しやすくするツールです。

Parallel Stacksの表示方法

デバッグ中に「デバッグ」→「ウィンドウ」→「Parallel Stacks」を選択します

Parallel Stacksの特徴

スタックフレームのグループ化

同じ関数を呼び出している複数のスレッドがまとめて表示され、どの関数が複数スレッドで共有されているかが一目でわかります。

スレッドの分岐と合流の可視化

並行処理の分岐点や合流点を視覚的に確認でき、複雑なスレッドの流れを理解しやすくなります。

スレッドの選択と詳細表示

任意のスタックフレームをクリックすると、そのスレッドの詳細なCall Stackや変数情報にジャンプできます。

Parallel Stacksの活用例

例えば、複数のスレッドが同じメソッドを呼び出している場合、Parallel Stacksでそのメソッドのノードを選択し、どのスレッドがどの呼び出し経路をたどっているかを視覚的に追跡できます。

これにより、デッドロックや競合状態の原因解析が効率化されます。

コンテキストスイッチの追跡

マルチスレッド環境では、スレッド間のコンテキストスイッチ(CPUがあるスレッドから別のスレッドに切り替わること)が頻繁に発生します。

これを追跡することで、パフォーマンス問題や競合状態の原因を特定しやすくなります。

コンテキストスイッチの確認方法

スレッドウィンドウでの状態確認

スレッドの状態が「待機中」や「実行中」などに変化する様子を観察し、どのタイミングでスレッドが切り替わっているかを把握します。

イベントトレースツールの利用

Visual Studioの「診断ツール」やWindowsの「Windows Performance Recorder(WPR)」などを使い、詳細なコンテキストスイッチのログを取得できます。

デバッグログの活用

アプリケーション内でスレッドの開始・終了や重要な処理の前後にログを出力し、スレッドの切り替わりを間接的に追跡します。

コンテキストスイッチの影響

頻繁なコンテキストスイッチはCPUのオーバーヘッドを増やし、パフォーマンス低下の原因となります。

また、スレッド間の競合やデッドロックの兆候を示すこともあります。

コンテキストスイッチ追跡の活用例

例えば、DLL内で複数スレッドが共有リソースにアクセスしている場合、スレッドウィンドウや診断ツールでコンテキストスイッチの頻度を確認し、ロックの競合や待機時間の長さを分析します。

これにより、問題のあるコード箇所を特定し、適切な同期処理の改善につなげられます。

マルチスレッド環境でのDLLデバッグは、スレッドの状態や呼び出し関係を正確に把握することが鍵です。

Visual StudioのスレッドウィンドウやParallel Stacks、コンテキストスイッチの追跡機能を活用し、複雑な並行処理の問題を効率的に解決しましょう。

ネイティブコードと混在するDLLのデバッグ

マネージ／ネイティブデバッグを有効にする

C#で開発したDLLがC++などのネイティブコードと連携している場合、マネージコード(.NET)とネイティブコードの両方を同時にデバッグする必要があります。

Visual Studioでは「混合モードデバッグ」と呼ばれ、これを有効にすることでマネージコードとネイティブコードの間をシームレスに行き来しながらデバッグできます。

混合モードデバッグの有効化手順

Visual StudioでDLLプロジェクトのプロパティを開きます。
「デバッグ」タブを選択します。
「デバッグの種類」または「デバッグモード」のドロップダウンから「マネージとネイティブ」を選択します。
プロジェクトをDebug構成でビルドし、デバッグを開始します。

この設定により、マネージコードのブレークポイントとネイティブコードのブレークポイントの両方が有効になり、ステップ実行も両方のコード間でスムーズに行えます。

注意点

混合モードデバッグはパフォーマンスに影響を与えるため、通常は問題解析時のみ有効にします
ネイティブコードのシンボル(PDBファイル)が正しく読み込まれていることが重要です
64bit環境の場合、マネージとネイティブの両方のビット数が一致している必要があります

C++/CLIでのクロスステップ

C++/CLIは、マネージコードとネイティブコードを橋渡しするための言語で、混在DLLの開発に使われます。

C++/CLIを使うと、マネージコードからネイティブコードへ、またはその逆へ簡単に呼び出しが可能です。

クロスステップの概要

Visual Studioの混合モードデバッグを使うと、C++/CLIのコード内でマネージコードとネイティブコードの間を行き来しながらステップ実行できます。

例えば、マネージコードからC++/CLIのネイティブ関数にステップインし、その後さらに純粋なネイティブC++コードにステップインすることが可能です。

クロスステップのポイント

C++/CLIのソースコードにブレークポイントを設定し、マネージコードから呼び出すと、ブレークポイントで停止します
ステップイン(F11)を使うと、マネージコード→C++/CLI→ネイティブコードの順に遷移できます
逆にステップアウト(Shift+F11)で元のコードに戻ることも可能です

サンプルコード例

// C++/CLIマネージクラス
public ref class ManagedWrapper
{
public:
    int CallNative(int x);
};
// ネイティブ関数
int NativeFunction(int x)
{
    return x * 2;
}
int ManagedWrapper::CallNative(int x)
{
    // ここでブレークポイントを設定可能
    return NativeFunction(x);
}

この例では、C#などのマネージコードからManagedWrapper::CallNativeを呼び出し、ネイティブ関数NativeFunctionにステップインできます。

シンボルサーバーとソースサーバーの設定

混合モードデバッグでは、マネージコードとネイティブコードの両方のシンボル(PDBファイル)とソースコードが必要です。

特に外部ライブラリや共有DLLをデバッグする場合、シンボルサーバーとソースサーバーを活用すると効率的です。

シンボルサーバーの概要

シンボルサーバーは、PDBファイルをネットワーク経由で管理・配布する仕組みです。

Visual Studioはシンボルサーバーから必要なPDBを自動的にダウンロードし、デバッグ時に利用します。

シンボルサーバーの設定方法

Visual Studioの「ツール」→「オプション」→「デバッグ」→「シンボル」を開きます。
「Microsoft Symbol Servers」などの既定のシンボルサーバーにチェックを入れます。
必要に応じてカスタムシンボルサーバーのURLを追加します。
シンボルキャッシュの保存先フォルダを指定します。

ソースサーバーの概要

ソースサーバーは、PDBファイルに埋め込まれた情報を使って、リモートのソースコードリポジトリからソースファイルを取得する仕組みです。

これにより、ローカルにソースコードがなくても正確なソースを参照できます。

ソースサーバーの利用方法

ソースサーバー対応のPDBを使用する必要があります。多くのオープンソースや社内ビルド環境で対応が進んでいます
Visual Studioの「ツール」→「オプション」→「デバッグ」→「全般」で「ソースサーバーを有効にする」にチェックを入れます
シンボルサーバーと組み合わせて利用すると、PDBとソースコードの両方を自動取得できます

効果的な活用例

社内でビルドした混合DLLを共有する際、シンボルサーバーにPDBを配置し、ソースサーバーでソースコードを管理すると、他の開発者が簡単にデバッグできるようになります
MicrosoftのシステムDLLやランタイムのデバッグ時にも、Microsoftのシンボルサーバーとソースサーバーを利用して詳細な解析が可能です

マネージとネイティブが混在するDLLのデバッグは複雑ですが、Visual Studioの混合モードデバッグを有効にし、C++/CLIのクロスステップを活用しつつ、シンボルサーバーとソースサーバーを適切に設定することで、効率的かつ正確なデバッグが実現します。

リモートデバッグとクラウド環境

msvsmonの構成

Visual Studioのリモートデバッグは、開発マシンとは別の環境で動作しているアプリケーションやDLLをデバッグするための機能です。

リモートデバッグを行うには、対象マシンにリモートデバッガーサービスであるmsvsmon.exe(Microsoft Visual Studio Remote Debugger)をセットアップします。

msvsmonのセットアップ手順

リモートデバッガーの入手

Visual StudioのインストールメディアやMicrosoftの公式サイトから、対象のOSとVisual Studioのバージョンに対応したリモートデバッガーをダウンロードします。

例：Remote Tools for Visual Studio 2022

リモートマシンへのインストール

ダウンロードしたリモートデバッガーをリモートマシンに展開またはインストールします。

インストール不要のZIP版もあります。

msvsmon.exeの起動

リモートマシン上でmsvsmon.exeを起動します。

初回起動時にネットワークの種類(プライベート/パブリック)を選択し、ファイアウォールの例外設定を促されることがあります。

認証モードの設定

msvsmonのメニューから「ツール」→「オプション」を開き、認証モードを設定します。

Windows認証(推奨)：開発マシンとリモートマシンが同一ドメイン内にある場合に使用
No Authentication(非推奨)：ドメイン外や簡易環境で使用。セキュリティリスクがあるため注意

接続の待機

msvsmonは接続待機状態になり、Visual Studioからの接続を受け入れます。

Visual Studio側の設定

Visual Studioの「デバッグ」→「プロセスにアタッチ」から「リモート」タブを選択し、リモートマシンの名前またはIPアドレスを指定します
対象プロセスを選択してアタッチします

これにより、リモート環境で動作するDLLやアプリケーションのデバッグが可能になります。

ファイアウォール例外の設定

リモートデバッグを行う際、Windowsファイアウォールやネットワークのセキュリティ設定が通信をブロックすることがあります。

msvsmonが正常に動作するためには、適切なファイアウォール例外を設定する必要があります。

ファイアウォール例外のポイント

msvsmon.exeの通信を許可

リモートマシンのファイアウォールでmsvsmon.exeの受信通信を許可します。

通常は起動時に自動で例外設定を促されますが、手動で設定する場合は以下の手順です。

ポートの開放

msvsmonはデフォルトでTCPポート4020～4030の範囲を使用します。

これらのポートをファイアウォールで開放してください。

ネットワークプロファイルの確認

リモートマシンのネットワークが「プライベート」または「ドメイン」ネットワークに設定されていることを確認します。

パブリックネットワークではファイアウォールが厳しく、通信が遮断されやすいです。

手動でのファイアウォール例外設定手順(Windows Defender Firewallの場合)

「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「詳細設定」を開きます。
「受信の規則」→「新しい規則」を選択。
「プログラム」を選択し、msvsmon.exeのパスを指定。
「接続を許可する」を選択。
適用するプロファイル(ドメイン、プライベート)を選択。
規則に名前を付けて完了。

Azure上のプロセスにアタッチ

クラウド環境、特にMicrosoft Azure上で動作するアプリケーションやDLLのデバッグもVisual Studioのリモートデバッグ機能で可能です。

Azureの仮想マシン(VM)やApp Serviceに対してリモートデバッグを行う際のポイントを説明します。

Azure仮想マシンでのリモートデバッグ

VMへのリモートデバッガーの配置

Azure VMにmsvsmon.exeをインストールまたは展開し、起動します。

ネットワーク設定

Azureのネットワークセキュリティグループ(NSG)で、msvsmonが使用するポート(通常4020～4030)を開放します。

ファイアウォール例外

VMのWindowsファイアウォールでmsvsmon.exeの通信を許可します。

Visual Studioからの接続

Visual Studioの「プロセスにアタッチ」からAzure VMのパブリックIPまたはDNS名を指定し、接続します。

Azure App Serviceでのリモートデバッグ

リモートデバッグの有効化

AzureポータルのApp Service設定で「リモートデバッグ」をオンにし、Visual Studioのバージョンを選択します。

Visual Studioからの接続

Visual Studioの「クラウドエクスプローラー」や「サーバーエクスプローラー」からApp Serviceに接続し、プロセスにアタッチします。

制限事項

App Serviceのリモートデバッグはマネージコードのみ対応で、ネイティブコードのデバッグはできません。

また、パフォーマンスに影響があるため、本番環境での使用は注意が必要です。

msvsmonの適切な構成とファイアウォール例外の設定を行い、Azure上のプロセスにアタッチすることで、クラウド環境でもVisual Studioの強力なデバッグ機能を活用できます。

これにより、リモート環境で発生するDLLの問題も効率的に解析・修正が可能です。

CI/CDでのデバッグ支援

ビルドパイプラインでのPDB出力保存

継続的インテグレーション／継続的デリバリー(CI/CD)環境でDLLをビルドする際、デバッグを効率化するためにPDBファイル(デバッグシンボル)をビルド成果物として保存することが重要です。

これにより、ビルド済みのDLLに対応する正確なシンボル情報を後から参照でき、問題発生時の解析が容易になります。

PDBファイルの保存設定

ビルドスクリプトの修正

CI/CDパイプラインのビルドステップで、Debug構成またはRelease構成であってもPDBファイルを生成するように設定します。

例：dotnet build --configuration Release /p:DebugType=portable

これにより、ReleaseビルドでもPDBが生成されます。

アーティファクトとしての保存

ビルド完了後、DLLとPDBファイルをアーティファクトとしてCI/CDサーバーに保存します。

これにより、後からダウンロードしてデバッグに利用可能です。

バージョニングの管理

ビルド番号やコミットハッシュを含むフォルダ構成で保存し、どのビルドに対応するPDBかを明確にします。

例：Azure DevOpsのYAML例

- task: DotNetCoreCLI@2

  inputs:
    command: 'build'
    projects: '**/*.csproj'
    arguments: '--configuration Release /p:DebugType=portable'

- task: PublishBuildArtifacts@1

  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'

このようにPDBを含めた成果物を保存しておくことで、トラブル発生時に正確なデバッグ情報を利用できます。

シンボルサーバーの自動公開

PDBファイルを単に保存するだけでなく、シンボルサーバーに自動的に公開することで、開発チーム全体で効率的にデバッグ情報を共有できます。

シンボルサーバーはPDBファイルを管理し、Visual Studioが必要に応じて自動的にシンボルを取得できる仕組みです。

シンボルサーバーの構築例

Azure Artifacts Symbol Server

Azure DevOpsの一部として提供されており、PDBファイルをアップロードして管理可能です。

NuGetベースのシンボルサーバー

NuGetパッケージとしてPDBを配布し、Visual Studioでシンボルを取得できます。

OSSのSymbol Server

例えば、SymbolSourceやMyGetなどの外部サービスを利用する方法もあります。

CI/CDでの自動公開設定

ビルドパイプラインの最後に、生成したPDBファイルをシンボルサーバーにアップロードするステップを追加します
アップロード時にバージョン情報やコミットIDをメタデータとして付与し、正確な対応付けを行います

Visual Studioの設定

「ツール」→「オプション」→「デバッグ」→「シンボル」で、シンボルサーバーのURLを登録します
必要に応じて認証情報を設定し、シンボルの自動取得を有効にします

これにより、開発者はローカルにPDBを持っていなくても、Visual Studioが自動的にシンボルを取得してデバッグが可能になります。

ReleaseビルドにおけるSource Linkの活用

Releaseビルドは最適化が有効でデバッグが難しいことが多いですが、Source Linkを活用することで、リモートのソースコードと正確に対応したデバッグが可能になります。

Source Linkの概要

Source LinkはPDBファイルにGitリポジトリのURLやコミットIDなどの情報を埋め込みます
デバッグ時にVisual Studioがこの情報を使い、リモートリポジトリから該当するソースコードを自動的に取得します

ReleaseビルドでのSource Link設定

プロジェクトのcsprojにSource Linkパッケージを追加します。例：Microsoft.SourceLink.GitHub
Release構成でもDebugTypeをportableやembeddedに設定し、PDBを生成します

<PropertyGroup Condition="'$(Configuration)'=='Release'">
  <DebugType>portable</DebugType>
  <EmbedUntrackedSources>true</EmbedUntrackedSources>
  <PublishRepositoryUrl>true</PublishRepositoryUrl>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.1.1" PrivateAssets="All"/>
</ItemGroup>

Visual Studioでの利用

「ツール」→「オプション」→「デバッグ」→「全般」で「ソースリンクを有効にする」にチェックを入れます
シンボルサーバーと組み合わせて利用すると、PDBとソースコードの両方をリモートから取得可能です

メリット

ローカルにソースコードがなくても、正確なバージョンのソースを参照できるため、Releaseビルドのデバッグが容易になります
チーム全体で同じソースコードを共有しやすくなり、トラブルシューティングの効率が向上します

CI/CD環境でPDBの出力と保存、シンボルサーバーへの自動公開、そしてReleaseビルドでのSource Link活用を組み合わせることで、DLLのデバッグ体験を大幅に向上させられます。

これにより、ビルドからデバッグまでの一連の流れがスムーズになり、問題解決のスピードアップにつながります。

よくあるトラブルシューティング

ブレークポイントが赤い丸で中抜きになる

Visual Studioでブレークポイントを設定した際に、赤い丸の中央が空洞(中抜き)になっている場合、これは「無効なブレークポイント」を意味します。

つまり、Visual Studioがその場所でブレークポイントを有効にできていない状態です。

主な原因と対処法

シンボルファイル(PDB)が読み込まれていない

DLLやEXEのPDBファイルが存在しない、または読み込まれていないと、ブレークポイントは無効になります。

→ 対象DLLのビルドがDebug構成であるか確認し、PDBファイルがDLLと同じフォルダにあるかチェックします。

→ Visual Studioの「デバッグ」→「ウィンドウ」→「モジュール」でシンボルの読み込み状況を確認し、必要なら手動でシンボルを読み込みます。

ソースコードとビルド済みDLLの不整合

ソースコードの内容とビルド済みDLLが異なるバージョンの場合、ブレークポイントは正しく機能しません。

→ 最新のソースコードで再ビルドし、DLLとPDBを更新してください。

最適化が有効になっている

Releaseビルドなどで最適化が有効だと、コードの順序が変わりブレークポイントが効かないことがあります。

→ Debugビルドでビルドするか、Releaseビルドでも「デバッグ情報の生成」を有効にし、最適化をオフにしてみてください。

プラットフォームの不一致

32bitと64bitのビルドターゲットが異なると、ブレークポイントが無効になることがあります。

→ 呼び出し元アプリケーションとDLLのプラットフォーム設定を一致させてください。

No symbols loadedメッセージ

デバッグ中に「No symbols loaded for this document」や「シンボルが読み込まれていません」というメッセージが表示されることがあります。

これはVisual Studioが対象のDLLやEXEのシンボル情報(PDBファイル)を読み込めていない状態です。

原因と対策

PDBファイルが存在しないか場所が違う

PDBファイルがDLLと同じフォルダにない、またはビルド時に生成されていない可能性があります。

→ Debugビルドでビルドし、PDBファイルがDLLと同じ場所にあるか確認します。

Visual Studioのシンボルパス設定が不適切

シンボルファイルの検索パスにPDBの場所が含まれていない場合、読み込みに失敗します。

→ 「ツール」→「オプション」→「デバッグ」→「シンボル」でPDBのパスを追加し、キャッシュをクリアして再読み込みを試みます。

DLLのバージョン不一致

実行中のDLLとPDBのバージョンが異なると、シンボルは読み込まれません。

→ 最新のDLLとPDBを使用しているか確認し、ビルドとデプロイの整合性を保ちます。

32bit/64bitの不一致

Visual Studioのデバッガーが対象プロセスのプラットフォームに対応していない場合もシンボルが読み込めません。

→ プロジェクトのプラットフォーム設定を確認し、Visual Studioのデバッグ設定も合わせてください。

32bit／64bitミスマッチ

DLLと呼び出し元アプリケーションのビット数(32bitまたは64bit)が一致していないと、デバッグが正常に動作しません。

特に以下の問題が発生します。

DLLが読み込まれない

64bitアプリケーションが32bit DLLを読み込もうとすると失敗しますし、その逆も同様です。

ブレークポイントが効かない

プロセスのビット数とVisual Studioのデバッガーのビット数が合っていないと、シンボルが正しく読み込まれず、ブレークポイントが無効になります。

対処方法

ビルド設定の統一

呼び出し元アプリケーションとDLLの両方を同じプラットフォームターゲット(x86またはx64)でビルドします。

→ Visual Studioの「構成マネージャー」でプラットフォームを確認・統一してください。

AnyCPUの注意点

AnyCPUでビルドされたマネージDLLは、呼び出し元のプロセスのビット数に依存します。

呼び出し元が64bitなら64bitで動作しますが、ネイティブDLLとの連携がある場合は注意が必要です。

Visual Studioのデバッガー設定

64bitプロセスをデバッグする場合は、Visual Studioが64bitデバッガーを使用しているか確認します。

→ 「ツール」→「オプション」→「デバッグ」→「全般」で「ネイティブコードのデバッグを有効にする」などの設定も確認してください。

プロセスの確認

デバッグ対象のプロセスが32bitか64bitかをタスクマネージャーなどで確認し、適切な環境でデバッグを行います。

これらのトラブルはDLLデバッグで頻繁に遭遇しますが、シンボルファイルの管理、ビルド構成の整合性、Visual Studioの設定を見直すことで多くの場合解決可能です。

問題が発生したらまずはこれらのポイントを順にチェックしてください。

まとめ

この記事では、C#で開発したDLLのデバッグを確実に行うための設定や手法を詳しく解説しました。

DebugビルドやPDBファイルの重要性、Visual Studioのスタートアップ設定やプロセスアタッチ、動的ロード時の対処法、ブレークポイントの高度な使い方、例外設定、Just My CodeやSource Linkの活用、マルチスレッドや混在コードのデバッグ、リモートデバッグ、CI/CD環境でのデバッグ支援、そしてよくあるトラブルの解決策まで幅広くカバーしています。

これらを活用することで、DLLの問題を効率的かつ正確に解析できるようになります。