C#のブレークポイント完全ガイド｜設定方法・止まらない原因・条件付きデバッグまで解説

はじめに

C#で不具合の原因を調べるとき、最もよく使うデバッグ機能のひとつがブレークポイントです。ブレークポイントを使うと、プログラムの実行を任意の行で一時停止し、その時点の変数の値、処理の流れ、呼び出し元、例外の発生状況などを確認できます。

「C# breakpoint」「C# ブレークポイント」と検索する人の多くは、ブレークポイントの設定方法を知りたいだけでなく、次のような悩みを抱えていることが多いです。

「ブレークポイントを設定したのに止まらない」
「赤丸が白抜きになる」
「条件付きブレークポイントの使い方が分からない」
「Visual StudioとVS Codeで手順が違って混乱する」
「ASP.NET CoreやUnity、単体テストでブレークポイントが効かない」

この記事では、C#のブレークポイントについて、基本的な設定方法から、止まらない原因、条件付きブレークポイント、便利な応用機能、実践的な使い方までまとめて解説します。

1. C#のブレークポイントとは？デバッグで何ができるのか

C#のブレークポイントとは、プログラムの実行を特定の場所で一時停止させるための目印です。Visual Studio、VS Code、RiderなどのIDEやエディタでソースコード上に設定し、デバッグ実行すると、その行に到達した時点で処理が止まります。

ブレークポイントで停止すると、コードを1行ずつ実行したり、変数の値を確認したり、メソッドの呼び出し元を調べたりできます。C#アプリケーションの不具合調査では非常に重要な機能です。

1-1. ブレークポイントの基本的な役割

ブレークポイントの基本的な役割は、プログラムを「調べたい場所」で止めることです。

例えば、次のようなコードがあるとします。

C#
int price = 1000;
int tax = 100;
int total = price + tax;

Console.WriteLine(total);

totalの値がおかしい場合、int total = price + tax;の行にブレークポイントを設定すれば、その行が実行される直前またはその周辺で処理を止められます。

停止中は、priceやtaxの値を確認できます。想定と違う値が入っていれば、どこで値が変わったのかをさらに追跡できます。

ブレークポイントは、単に「止める」だけではありません。次のような確認にも使えます。

変数の中身を確認する
if文のどちらの分岐に入ったか確認する
for文やforeach文の何回目で問題が起きるか確認する
メソッドの引数や戻り値を確認する
例外が発生する直前の状態を確認する
非同期処理の流れを確認する
外部APIやデータベース処理の前後を確認する

C#のデバッグでは、まずブレークポイントで処理を止めて、そこから原因を絞り込むのが基本です。

1-2. Console.WriteLineデバッグとの違い

C#では、Console.WriteLineを使って値を出力しながらデバッグする方法もあります。

C#
Console.WriteLine($"userId = {userId}");
Console.WriteLine($"count = {items.Count}");

この方法は手軽ですが、確認したい値を出力するコードを毎回書く必要があります。また、出力後にコードを消し忘れることもあります。

一方、ブレークポイントを使うと、ソースコードにログ出力を追加しなくても実行中の状態を確認できます。

主な違いは次のとおりです。

Console.WriteLineはログを出力して確認する方法です。
ブレークポイントは実行を止めて、その場で状態を確認する方法です。

Console.WriteLineは、処理の流れをざっくり確認したいときに便利です。ブレークポイントは、特定の箇所で詳しく状態を調べたいときに向いています。

例えば、処理が何度も実行されるバッチ処理や本番に近い環境ではログ出力が有効です。一方、ローカル開発中に「なぜこの変数がnullになるのか」を調べる場合は、ブレークポイントのほうが効率的です。

1-3. C#開発でブレークポイントを使うべき場面

C#開発でブレークポイントを使うべき代表的な場面は、次のようなケースです。

まず、想定外の値が入っている場合です。例えば、ユーザーID、金額、日付、リスト件数などが期待と異なる場合、値が作られる箇所や変更される箇所にブレークポイントを置くことで原因を追えます。

次に、条件分岐が期待どおりに動かない場合です。if文、switch文、三項演算子などの条件式が正しく評価されているかを確認できます。

また、例外が発生する場合にも有効です。例外が発生する直前で止めることで、null参照、範囲外アクセス、型変換エラー、データベース接続エラーなどの原因を調査しやすくなります。

ASP.NET CoreのWebアプリでは、コントローラー、サービス、ミドルウェア、APIエンドポイントなどにブレークポイントを置くことで、リクエストがどのように処理されているかを追えます。

単体テストでは、テスト対象メソッドやテストコード内にブレークポイントを置くことで、テスト失敗の原因を細かく確認できます。

Unity開発では、C#スクリプトのStart、Update、イベントハンドラなどにブレークポイントを設定して、ゲームオブジェクトの状態や処理順序を調べられます。

1-4. Visual Studio・VS Code・Riderでの違い

C#のブレークポイントは、使用する開発環境によって操作方法が少し異なります。

Visual Studioは、C#開発で最も機能が充実しているIDEです。ブレークポイントの設定、条件付きブレークポイント、ヒットカウント、例外設定、ウォッチ、ローカル、呼び出し履歴、データブレークポイントなど、多くのデバッグ機能を標準で利用できます。

VS Codeは軽量なエディタです。C# Dev KitやC#拡張機能を使うことで、C#のデバッグができます。Visual Studioほど統合機能は多くありませんが、ブレークポイント、条件付きブレークポイント、ウォッチ、コールスタックなどの基本機能は利用できます。

RiderはJetBrains製のIDEで、C#や.NET開発に強い環境です。Visual Studioと同様に高機能なデバッガを備えており、ブレークポイントの管理、条件設定、例外ブレークポイント、ステップ実行などを直感的に操作できます。

どの環境でも基本的な考え方は同じです。ソースコード上にブレークポイントを設定し、デバッグ実行し、停止した時点で状態を確認します。ただし、ショートカットキーやウィンドウ名、設定画面の位置は環境によって異なるため、自分が使っているツールに合わせて覚えることが大切です。

2. C#でブレークポイントを設定する基本手順

C#でブレークポイントを使う基本的な流れは、次のとおりです。

まず、止めたい行にブレークポイントを設定します。次に、デバッグ実行を開始します。プログラムがその行に到達すると処理が停止します。停止後は、変数の値や呼び出し履歴を確認し、必要に応じてステップ実行で処理を追います。

ここでは、主にVisual Studioを例にして解説します。

2-1. Visual Studioでブレークポイントを設定・解除する方法

Visual Studioでブレークポイントを設定するには、ソースコードの左端にある余白部分をクリックします。行番号の左側に赤い丸が表示されれば、ブレークポイントが設定されています。

例えば、次のコードでtotalの値を確認したい場合は、int total = price + tax;の行にブレークポイントを設定します。

C#
int price = 1000;
int tax = 100;
int total = price + tax;

Console.WriteLine(total);

赤い丸が表示された状態でデバッグ実行すると、その行に到達したときに処理が停止します。

解除する場合は、同じ赤い丸をもう一度クリックします。赤い丸が消えれば、ブレークポイントは削除されています。

ブレークポイントを設定できるのは、実行可能なコード行です。コメント行、空行、名前空間宣言だけの行などには通常設定できません。設定したつもりでも、実際には次の実行可能な行に移動することがあります。

2-2. ショートカットキーで設定する方法

Visual Studioでは、カーソルを置いた行でF9キーを押すとブレークポイントを設定または解除できます。

よく使うショートカットキーは次のとおりです。

F9：ブレークポイントの設定・解除
F5：デバッグ実行の開始
Ctrl + F5：デバッグなしで実行
F10：ステップオーバー
F11：ステップイン
Shift + F11：ステップアウト

ショートカットキーを覚えると、マウス操作なしで素早くデバッグできます。特にF9、F5、F10、F11は使用頻度が高いため、C#開発では覚えておくと便利です。

VS CodeやRiderでも同様の操作ができますが、キーマップや設定によってショートカットが異なる場合があります。普段使う環境のショートカットを確認しておきましょう。

2-3. ブレークポイントの有効化・無効化

ブレークポイントは、削除せずに一時的に無効化できます。

無効化したブレークポイントは、設定位置を残したまま停止しない状態になります。Visual Studioでは、ブレークポイントを右クリックして「ブレークポイントの無効化」を選択することで無効化できます。

無効化されたブレークポイントは、通常の赤い丸ではなく、薄い表示や別のアイコンで表示されます。再度有効化すれば、同じ場所で再び停止するようになります。

削除と無効化の違いは重要です。

削除はブレークポイントそのものを消します。
無効化は場所を残したまま一時的に止まらないようにします。

一時的に確認対象から外したいだけなら、削除ではなく無効化が便利です。複雑な調査では、複数のブレークポイントを使い分けることが多いため、有効化・無効化を活用すると整理しやすくなります。

2-4. ブレークポイント一覧ウィンドウで管理する方法

Visual Studioには、ブレークポイントを一覧で管理できるウィンドウがあります。メニューの「デバッグ」から「ウィンドウ」、「ブレークポイント」を開くと、現在設定されているブレークポイントを確認できます。

ブレークポイント一覧では、次のような操作ができます。

設定済みブレークポイントの確認
ブレークポイントの有効化・無効化
ブレークポイントの削除
条件付きブレークポイントの確認
ヒットカウントの確認
ラベル付けによる整理
検索による絞り込み

大きなプロジェクトでは、複数のファイルにブレークポイントを設定することがあります。どこに設定したか分からなくなった場合は、ブレークポイント一覧ウィンドウを確認すると整理しやすくなります。

特に、過去のデバッグで設定したブレークポイントが残っていると、意図しない場所で処理が止まることがあります。デバッグ作業が終わったら、一覧から不要なブレークポイントを削除または無効化しておくとよいでしょう。

2-5. デバッグ実行と通常実行の違い

C#でブレークポイントを使うには、基本的にデバッグ実行する必要があります。

Visual Studioでは、F5を押すとデバッグ実行になります。一方、Ctrl + F5を押すとデバッグなしで実行されます。

デバッグ実行では、ブレークポイント、ステップ実行、ウォッチ、ローカル、呼び出し履歴などのデバッグ機能が利用できます。通常実行では、プログラムは動きますが、ブレークポイントでは停止しません。

「ブレークポイントを設定したのに止まらない」という場合、実はCtrl + F5で実行していた、またはデバッグなしで起動していたというケースがあります。

Visual Studioのツールバーで、実行ボタンが「開始」なのか「デバッグの開始」なのかを確認しましょう。C# breakpointが効かないときは、まずデバッグ実行になっているかを確認するのが基本です。

3. ブレークポイントで止まった後に確認すべきこと

ブレークポイントで処理が止まったら、ただ止まったことを確認するだけでは不十分です。停止時点の状態を調べ、想定と実際の違いを見つけることが重要です。

ここでは、ブレークポイント停止後に確認すべきポイントを解説します。

3-1. 変数の値を確認する

ブレークポイントで停止したら、まず変数の値を確認します。

Visual Studioでは、コード上の変数にマウスカーソルを合わせると、その時点の値が表示されます。

例えば、次のコードでtotalがおかしい場合を考えます。

C#
int price = 1000;
int quantity = 3;
int total = price * quantity;

ブレークポイントで停止した状態で、priceやquantityにカーソルを合わせると、それぞれの値を確認できます。

オブジェクトの場合は、プロパティの中身も展開して確認できます。

C#
var user = new User
{
    Id = 1,
    Name = "Taro",
    Age = 20
};

userにカーソルを合わせると、Id、Name、Ageなどのプロパティを確認できます。

変数の値を見るときは、次の点に注目します。

nullになっていないか
想定した値が入っているか
リストの件数が正しいか
文字列に余計な空白が入っていないか
日付や時刻が期待どおりか
数値の計算結果が正しいか
フラグのtrue/falseが正しいか

不具合の多くは、「想定と違う値」が原因です。まずは変数の値を丁寧に確認しましょう。

3-2. ウォッチ・ローカル・自動変数ウィンドウの使い方

Visual Studioには、変数を確認するためのウィンドウが複数あります。

ローカルウィンドウは、現在のスコープ内にあるローカル変数を一覧表示します。メソッド内の変数や引数をまとめて確認したいときに便利です。

自動変数ウィンドウは、現在実行中の行やその前後で使われている変数を自動的に表示します。今まさに関係している値を素早く確認できます。

ウォッチウィンドウは、自分で指定した式や変数を継続的に監視できます。例えば、user.Name、items.Count、order.TotalPriceのような式を登録しておくと、ステップ実行しながら値の変化を追えます。

ウォッチには単純な変数だけでなく、式も入力できます。

C#
items.Count
user != null
order.TotalPrice > 10000
DateTime.Now

ただし、プロパティやメソッドを評価すると副作用が発生する場合があります。ウォッチでメソッドを呼び出すと、実際に処理が実行される可能性があるため注意が必要です。

基本的には、値の確認にはローカルやウォッチを使い、処理を変化させるような式の評価は避けるのが安全です。

3-3. ステップオーバー・ステップイン・ステップアウトの違い

ブレークポイントで停止した後は、ステップ実行を使って1行ずつ処理を進められます。

ステップオーバーは、現在の行を実行して次の行に進みます。メソッド呼び出しがあっても、そのメソッドの中には入りません。Visual Studioでは通常F10です。

ステップインは、現在の行にあるメソッド呼び出しの中に入ります。メソッド内部の処理を詳しく確認したいときに使います。Visual Studioでは通常F11です。

ステップアウトは、現在入っているメソッドの残りを実行し、呼び出し元に戻ります。メソッド内の確認が終わったときに便利です。Visual Studioでは通常Shift + F11です。

例えば、次のコードがあります。

C#
int total = CalculateTotal(price, quantity);
Console.WriteLine(total);

CalculateTotalの中身を確認したい場合は、ステップインを使います。中身を確認する必要がなく、結果だけ見たい場合はステップオーバーを使います。

ステップ実行の使い分けは、C#デバッグの効率を大きく左右します。すべてのメソッドに入ると時間がかかるため、調べたい処理だけステップインし、それ以外はステップオーバーで進めるのが基本です。

3-4. 呼び出し履歴から処理の流れを追う

呼び出し履歴は、現在の処理がどのメソッドから呼ばれてきたかを確認するための機能です。Visual Studioでは「呼び出し履歴」または「Call Stack」として表示されます。

例えば、次のような呼び出しがあったとします。

C#
Main()
  -> CreateOrder()
    -> CalculateTotal()
      -> ApplyDiscount()

ApplyDiscountでブレークポイントが停止した場合、呼び出し履歴を見ると、どの流れでそのメソッドに到達したかが分かります。

これは、同じメソッドが複数の場所から呼ばれる場合に特に重要です。

例えば、CalculateTotalが注文画面、管理画面、バッチ処理のすべてから呼ばれている場合、どの経路で呼ばれたときに問題が起きているのかを呼び出し履歴で確認できます。

呼び出し履歴を使うと、次のようなことが分かります。

どのメソッドから呼ばれたか
どの順番で処理が進んできたか
想定外の経路で呼び出されていないか
再帰呼び出しが発生していないか
フレームごとの引数やローカル変数の状態

ブレークポイントで止まった場所だけを見るのではなく、そこに至るまでの流れを確認することが大切です。

3-5. 例外発生箇所を特定する

C#で例外が発生している場合、ブレークポイントを使うと発生箇所を特定しやすくなります。

例えば、次のような例外があります。

NullReferenceException
IndexOutOfRangeException
InvalidOperationException
ArgumentException
FormatException
SqlException

例外が発生する直前の行にブレークポイントを置けば、対象の変数やオブジェクトがどのような状態か確認できます。

C#
var name = user.Name;

この行でNullReferenceExceptionが発生する場合、userがnullである可能性があります。ブレークポイントで停止してuserの値を確認すれば、原因を特定できます。

また、Visual Studioの例外設定を使うと、例外がスローされたタイミングで自動的に停止できます。try-catchで捕捉される前に止められるため、例外の発生源を見つけやすくなります。

例外調査では、エラーメッセージだけでなく、停止時点の変数、呼び出し履歴、入力データをあわせて確認することが重要です。

4. C#のブレークポイントが止まらない主な原因と対処法

C#のブレークポイントでよくある悩みが、「設定したのに止まらない」という問題です。Visual Studioで赤丸を置いたのに処理が停止しない場合、いくつかの原因が考えられます。

ここでは、C# breakpointが止まらない主な原因と対処法を解説します。

4-1. DebugビルドではなくReleaseビルドになっている

ブレークポイントが止まらない原因として多いのが、ビルド構成がReleaseになっているケースです。

Debugビルドはデバッグしやすいようにシンボル情報を含み、最適化も抑えられます。一方、Releaseビルドは実行速度を優先して最適化されるため、コードの行と実行位置が一致しにくくなることがあります。

Visual Studioの上部ツールバーにある構成を確認し、ReleaseではなくDebugになっているか確認してください。

対処法は次のとおりです。

ビルド構成をDebugに変更する
ソリューションをクリーンする
再ビルドする
再度デバッグ実行する

Releaseビルドでもデバッグできる場合はありますが、ブレークポイントが期待どおりに動かないことがあります。通常の開発中はDebugビルドで確認するのが基本です。

4-2. デバッグなしで実行している

ブレークポイントは、デバッグ実行していなければ基本的に停止しません。

Visual Studioでは、F5がデバッグ実行、Ctrl + F5がデバッグなしで実行です。Ctrl + F5で起動している場合、ブレークポイントを設定していても止まりません。

対処法は、F5で実行することです。また、メニューから「デバッグの開始」を選んでも構いません。

ASP.NET Coreアプリの場合も、デバッグ実行で起動しているか確認しましょう。ブラウザでURLを直接開いただけでは、Visual Studioのデバッガがアタッチされていない可能性があります。

4-3. 実行しているコードとソースコードが一致していない

ブレークポイントが止まらない場合、今見ているソースコードと実際に実行されているアプリケーションが一致していない可能性があります。

例えば、次のようなケースです。

別のプロジェクトを起動している
古いDLLが実行されている
別のブランチのコードを見ている
ビルド対象に含まれていないファイルを編集している
参照先がプロジェクト参照ではなく古いDLL参照になっている

この場合、ソースコード上ではブレークポイントを置けても、実行中のコードにはその行が存在しないため停止しません。

対処法としては、まずスタートアッププロジェクトを確認します。次に、ソリューション全体をクリーンして再ビルドします。必要に応じて、binフォルダやobjフォルダを削除してから再ビルドすると改善することがあります。

4-4. PDBなどのシンボルファイルが読み込まれていない

C#のブレークポイントが正しく動作するには、PDBファイルなどのシンボル情報が必要です。PDBは、実行中のコードとソースコードの対応関係を持つデバッグ情報です。

シンボルが読み込まれていない場合、Visual Studioではブレークポイントが白抜きになったり、「現在の設定ではブレークポイントにヒットしません」と表示されたりします。

対処法は次のとおりです。

Debugビルドになっているか確認する
プロジェクトのデバッグ情報が生成されているか確認する
ソリューションをクリーンして再ビルドする
モジュールウィンドウで対象DLLのシンボル読み込み状況を確認する
必要に応じてシンボルを手動で読み込む

Visual Studioでは、デバッグ中に「デバッグ」から「ウィンドウ」、「モジュール」を開くと、各DLLのシンボルが読み込まれているか確認できます。

4-5. ブレークポイントが無効化されている

設定したブレークポイントが無効化されていると、その場所では停止しません。

無効化されたブレークポイントは、通常の赤丸ではなく薄い表示になることがあります。ブレークポイント一覧ウィンドウで有効状態を確認しましょう。

対処法は、ブレークポイントを右クリックして有効化することです。また、一覧ウィンドウからまとめて有効化することもできます。

複数のブレークポイントを使っていると、一時的に無効化したものを忘れてしまうことがあります。止まらない場合は、単純に無効になっていないかも確認しましょう。

4-6. 該当コードが実行されていない

ブレークポイントが止まらない最も単純な理由は、その行が実行されていないことです。

例えば、if文の条件に入らない、メソッドが呼ばれていない、イベントが発火していない、APIエンドポイントが呼ばれていない、といったケースです。

C#
if (user.IsAdmin)
{
    // ここにブレークポイントを置いても、
    // IsAdminがfalseなら止まらない
    ShowAdminMenu();
}

この場合、ブレークポイントが悪いのではなく、処理がそこに到達していません。

対処法は、より手前の行にブレークポイントを置いて、処理がどこまで到達しているかを確認することです。メソッドの先頭、条件分岐の直前、イベントハンドラの入口などに置くと原因を追いやすくなります。

4-7. 最適化により処理がスキップ・変更されている

Releaseビルドや最適化が有効な状態では、コンパイラやJITによって処理が最適化されることがあります。

その結果、ソースコード上の行と実際の実行位置が一致しなかったり、変数が最適化で消えたり、ブレークポイントが期待どおりに止まらなかったりすることがあります。

対処法は、Debugビルドに切り替え、コード最適化を無効にすることです。プロジェクト設定で「コードの最適化」が有効になっていないか確認しましょう。

特に、パフォーマンス検証や本番に近い設定でReleaseビルドを使っている場合は注意が必要です。原因調査では、まずDebugビルドで再現するか確認するとよいでしょう。

4-8. 古いビルド成果物が残っている

古いビルド成果物が残っていると、修正したはずのコードが反映されず、ブレークポイントが止まらないことがあります。

Visual Studioでビルドしているつもりでも、実際には古いDLLが参照されている場合があります。特に、複数プロジェクト構成、ローカルNuGetパッケージ、手動コピーしたDLLを使っている場合に起こりやすいです。

対処法は次のとおりです。

ソリューションをクリーンする
ソリューションを再ビルドする
binフォルダとobjフォルダを削除する
参照先DLLの場所を確認する
スタートアッププロジェクトを確認する

それでも解決しない場合は、実行中のプロセスがどのパスのDLLを読み込んでいるかをモジュールウィンドウで確認するとよいでしょう。

4-9. アタッチ先のプロセスを間違えている

既に起動しているプロセスにデバッガをアタッチする場合、アタッチ先を間違えるとブレークポイントは止まりません。

例えば、ASP.NET Coreアプリ、Windowsサービス、Unity、IIS Express、Dockerコンテナ、複数起動している同名プロセスなどでは、どのプロセスにアタッチするかが重要です。

対処法は、Visual Studioの「プロセスにアタッチ」画面で、正しいプロセスを選択することです。

確認すべきポイントは次のとおりです。

プロセス名が正しいか
プロセスIDが正しいか
実行ユーザーが正しいか
対象アプリが本当にそのプロセスで動いているか
マネージコードのデバッグが有効か

複数の同名プロセスがある場合は、起動時刻やコマンドライン、ポート番号などを参考にすると判断しやすくなります。

4-10. ASP.NET・Unity・テストコードで止まらない場合の確認ポイント

ASP.NET Coreでブレークポイントが止まらない場合は、まず対象のエンドポイントが実際に呼ばれているか確認します。ルーティングが違う、HTTPメソッドが違う、別の環境のURLを見ている、ミドルウェアで処理が止まっている、といった原因があります。

また、IIS Express、Kestrel、Docker、Azure App Serviceなど、どの環境で実行しているかも重要です。Visual Studioでデバッグ実行しているプロセスと、ブラウザからアクセスしているアプリが一致しているか確認しましょう。

UnityでC#のブレークポイントが止まらない場合は、Unity EditorとIDEが正しく連携しているか確認します。Visual Studio Tools for UnityやRiderのUnity連携設定、Attach to Unityの対象、スクリプトのコンパイルエラーなどを確認してください。

単体テストで止まらない場合は、テストを通常実行していないか確認します。Visual Studioのテストエクスプローラーでは、「テストのデバッグ」を選択する必要があります。通常の「テストの実行」では、ブレークポイントで停止しないことがあります。

5. 条件付きブレークポイントの使い方

条件付きブレークポイントは、指定した条件を満たしたときだけ停止するブレークポイントです。C#のデバッグでは非常に便利な機能です。

特に、ループ内で特定の値だけ確認したい場合や、大量データの中から問題のあるデータだけで止めたい場合に役立ちます。

5-1. 条件付きブレークポイントとは

通常のブレークポイントは、その行に到達するたびに毎回停止します。

一方、条件付きブレークポイントは、条件式がtrueになった場合だけ停止します。

例えば、次のようなループがあります。

C#
foreach (var user in users)
{
    ProcessUser(user);
}

全ユーザーで停止すると効率が悪いですが、user.Id == 100のときだけ止めたい場合があります。このようなときに条件付きブレークポイントを使います。

条件付きブレークポイントを使えば、不要な停止を減らし、調べたいケースだけに集中できます。

5-2. 変数の値が特定条件のときだけ止める方法

Visual Studioで条件付きブレークポイントを設定するには、ブレークポイントを右クリックし、「条件」を選択します。そこで条件式を入力します。

例えば、次のような条件を設定できます。

C#
user.Id == 100

この条件を設定すると、user.Idが100のときだけ停止します。

文字列の場合は、次のように書けます。

C#
user.Name == "Taro"

nullチェックを含める場合は、次のように書くと安全です。

C#
user != null && user.Name == "Taro"

リストの件数で止めたい場合は、次のように指定できます。

C#
items.Count > 10

条件式は、現在のスコープで評価できる式である必要があります。対象の変数がその行で参照できない場合、条件式は評価できません。

5-3. ヒットカウントを使って指定回数だけ実行後に止める方法

ヒットカウントは、ブレークポイントに到達した回数に応じて停止する機能です。

例えば、for文の100回目だけ止めたい場合に便利です。

C#
for (int i = 0; i < 1000; i++)
{
    Process(i);
}

毎回止まると確認が大変ですが、ヒットカウントを使えば、指定回数に達したときだけ停止できます。

Visual Studioでは、ブレークポイントの設定からヒットカウントを指定できます。

使い方の例は次のとおりです。

10回目に到達したときだけ停止する
10回以上到達したら停止する
指定回数の倍数で停止する

ループ処理、バッチ処理、大量データ処理のデバッグでは、ヒットカウントを使うと効率よく原因を追えます。

5-4. フィルター条件を使ってスレッドやプロセスを絞る方法

マルチスレッド処理や複数プロセスで動くアプリケーションでは、特定のスレッドやプロセスだけでブレークポイントを有効にしたい場合があります。

そのような場合は、フィルター条件を使います。

フィルターでは、プロセスID、プロセス名、スレッドID、スレッド名、マシン名などを条件にできます。

例えば、特定のスレッド名だけで止めたい場合、スレッド名を条件にして停止対象を絞れます。

非同期処理や並列処理では、同じコードが複数のスレッドから実行されることがあります。通常のブレークポイントでは何度も止まりすぎる場合、フィルター条件を使うことで調査しやすくなります。

5-5. 条件式で使える書き方と注意点

条件付きブレークポイントの条件式には、C#の式に近い書き方を使えます。

例えば、次のような式です。

C#
count > 10
name == "admin"
user != null
user.Age >= 20
items.Count == 0
order.Status == OrderStatus.Completed

ただし、条件式には注意点があります。

まず、現在のスコープで参照できる変数しか使えません。別のメソッドのローカル変数や、まだ宣言されていない変数は評価できません。

次に、副作用のある式は避けるべきです。例えば、条件式でメソッドを呼び出すと、状態が変わる可能性があります。

C#
UpdateStatus() == true

このような式は、デバッグのために実際の処理結果を変えてしまう可能性があるため避けましょう。

また、プロパティの評価でも内部で処理が走る場合があります。重い処理や外部アクセスを伴うプロパティを条件に使うと、デバッグが遅くなったり、意図しない動作になることがあります。

条件式は、できるだけ単純で安全なものにするのが基本です。

5-6. 条件付きブレークポイントが動かない原因

条件付きブレークポイントが動かない場合、次のような原因が考えられます。

条件式が現在のスコープで評価できない
変数名を間違えている
null参照が発生している
条件が一度もtrueになっていない
ブレークポイント自体が無効化されている
Debugビルドで実行していない
シンボルが読み込まれていない

例えば、条件式に次のように書いた場合を考えます。

C#
user.Name == "Taro"

もしuserがnullであれば、条件式の評価時に問題が起きる可能性があります。この場合は、次のようにnullチェックを追加します。

C#
user != null && user.Name == "Taro"

また、条件が想定どおりtrueになっているかを確認するために、一度通常のブレークポイントで止めて、ウォッチウィンドウで条件式を評価してみるのも有効です。

5-7. ループ内で使うと遅くなる場合の対策

条件付きブレークポイントは便利ですが、ループ内で使うと処理が遅くなることがあります。

特に、数万回、数十万回実行されるループ内で複雑な条件式を設定すると、毎回条件式を評価するためデバッグ速度が大きく低下します。

対策としては、条件式をできるだけ単純にします。

C#
i == 1000

のような単純な条件は比較的扱いやすいですが、複雑なメソッド呼び出しやLINQ式を条件にすると重くなりやすいです。

また、コード側に一時的な条件分岐を入れて、その中に通常のブレークポイントを置く方法もあります。

C#
if (user.Id == 100)
{
    // ここにブレークポイントを置く
    Console.WriteLine("debug");
}

デバッグ後に削除する必要はありますが、条件付きブレークポイントより安定して確認できる場合があります。

大量データの調査では、ヒットカウント、条件付きブレークポイント、ログ出力を適切に使い分けましょう。

6. ブレークポイントの便利な種類と応用機能

C#のブレークポイントには、通常の行ブレークポイント以外にも便利な種類があります。Visual Studioなどの高機能なIDEでは、状況に応じてさまざまなブレークポイントを使い分けられます。

6-1. トレースポイントで停止せずにログを出す

トレースポイントは、プログラムを停止せずにメッセージを出力する機能です。通常のブレークポイントは処理を止めますが、トレースポイントは停止せずにログのような情報を出せます。

例えば、ループ内で毎回止めたくないが、値だけ確認したい場合に便利です。

C#
foreach (var item in items)
{
    Process(item);
}

このような箇所で、item.Idやitem.Nameを出力するトレースポイントを設定すれば、コードにConsole.WriteLineを追加せずに値を確認できます。

トレースポイントは、ログ出力とブレークポイントの中間のような機能です。処理を止めずに流れを確認したいときに役立ちます。

6-2. 関数ブレークポイントでメソッド呼び出し時に止める

関数ブレークポイントは、特定のメソッドが呼び出されたときに停止するブレークポイントです。

通常のブレークポイントはソースコードの行に設定しますが、関数ブレークポイントはメソッド名を指定して設定します。

例えば、次のメソッドが呼ばれたときに止めたい場合があります。

C#
CalculateTotal

関数ブレークポイントを設定すると、そのメソッドが呼び出されたタイミングで停止できます。

ソースコード上で場所を探しにくい場合や、外部ライブラリ、継承、インターフェース実装などで呼び出し元を調べたい場合に便利です。

ただし、オーバーロードされたメソッドや同名メソッドが複数ある場合は、意図しない箇所で止まることがあります。必要に応じて名前空間やクラス名を含めて指定するとよいでしょう。

6-3. 例外ブレークポイントで例外発生時に止める

例外ブレークポイントは、例外がスローされたタイミングで停止する機能です。

通常、例外はtry-catchで捕捉されるとアプリケーションが継続する場合があります。しかし、例外の発生元を調べたいときは、catchされる前に止めたいことがあります。

Visual Studioの例外設定では、特定の例外がスローされたときに停止するよう設定できます。

例えば、NullReferenceExceptionが発生した瞬間に止めれば、どのオブジェクトがnullだったのか確認しやすくなります。

例外ブレークポイントは、次のような場面で役立ちます。

どこで例外が発生しているか分からない
catchで握りつぶされている例外を見つけたい
ログには出ない例外を調べたい
例外発生時の変数の状態を確認したい

ただし、すべての例外で停止するようにすると、フレームワーク内部の例外でも頻繁に止まることがあります。調査対象の例外に絞って使うと効率的です。

6-4. データブレークポイントで値の変更を検知する

データブレークポイントは、特定の変数やオブジェクトの値が変更されたときに停止する機能です。

例えば、「このプロパティがいつ変更されているのか分からない」という場合に役立ちます。

C#
user.Status = UserStatus.Active;

user.Statusがどこかで予期せず変更される場合、値の変更を検知して停止できれば原因を追いやすくなります。

ただし、C#や.NETでのデータブレークポイントは、環境や対象によって利用条件があります。Visual Studioのバージョン、.NETの種類、デバッグ対象、プロパティかフィールドか、ネイティブコードかマネージコードかによって使える範囲が異なります。

使えない場合は、プロパティのsetterにブレークポイントを置く方法が有効です。

C#
private string _status;

public string Status
{
    get => _status;
    set
    {
        _status = value; // ここにブレークポイントを置く
    }
}

値の変更元を追いたい場合は、setterへのブレークポイントが最も分かりやすいことも多いです。

6-5. 一時ブレークポイントを使う

一時ブレークポイントは、一度だけ停止した後に自動的に削除されるブレークポイントです。

「次にこの行へ来たときだけ止めたい」という場合に便利です。毎回止まる必要がない場合、通常のブレークポイントを設定して後で削除するよりも効率的です。

例えば、初回の初期化処理だけ確認したい場合や、特定の画面遷移後に一度だけ止めたい場合に使えます。

一時ブレークポイントを使うと、確認後にブレークポイントを消し忘れるリスクを減らせます。

6-6. 依存ブレークポイントを使う

依存ブレークポイントは、別のブレークポイントにヒットした後で有効になるブレークポイントです。

例えば、ある初期化処理を通過した後だけ、別の処理で停止したい場合に使えます。

通常のブレークポイントでは、対象行に到達するたびに停止してしまいます。しかし、依存関係を設定すれば、特定の前提条件を満たした後だけ停止できます。

複雑な処理フローを追う場合、特に次のような場面で役立ちます。

初期化後の処理だけ確認したい
特定の画面操作後だけ止めたい
特定のAPI呼び出し後だけ後続処理を追いたい
複数段階の処理で後半だけ調べたい

依存ブレークポイントは、条件付きブレークポイントと組み合わせることで、より精密なデバッグができます。

6-7. ラベルや検索でブレークポイントを整理する

大きなC#プロジェクトでは、ブレークポイントが増えすぎて管理しにくくなることがあります。

そのような場合は、ラベルや検索機能を使って整理します。

例えば、次のように用途別に整理できます。

注文処理調査用
ログイン処理調査用
APIデバッグ用
単体テスト確認用
一時確認用

Visual Studioのブレークポイント一覧では、ブレークポイントにラベルを付けたり、条件やファイル名で検索したりできます。

不要なブレークポイントが残っていると、意図しない場所で停止して作業効率が下がります。デバッグ後は、不要なものを削除し、後で使いそうなものは無効化して整理しておくとよいでしょう。

7. C#開発シーン別のブレークポイント活用例

ここからは、C#開発でよくある場面ごとに、ブレークポイントの活用例を紹介します。

7-1. for文・foreach文の中で特定データだけ止める

ループ処理では、毎回ブレークポイントで止まると非常に効率が悪くなります。

C#
foreach (var user in users)
{
    UpdateUser(user);
}

特定のユーザーだけ確認したい場合は、条件付きブレークポイントを使います。

C#
user.Id == 100

これにより、user.Idが100のときだけ停止できます。

for文の場合は、インデックスで条件を指定できます。

C#
i == 50

大量データの処理では、条件付きブレークポイントやヒットカウントを使うことで、必要なタイミングだけ停止できます。

7-2. if文の分岐条件を確認する

if文が想定どおりに動かない場合は、条件式の直前にブレークポイントを置きます。

C#
if (user.Age >= 20 && user.IsActive)
{
    ShowMenu();
}

この場合、user.Ageとuser.IsActiveの値を確認します。条件式全体がtrueになると思っていたのにfalseになる場合、どちらかの値が想定と違っているはずです。

ウォッチウィンドウに次のような式を入れると分かりやすくなります。

C#
user.Age >= 20
user.IsActive
user.Age >= 20 && user.IsActive

複雑な条件式では、条件を分解して確認することが大切です。

7-3. メソッドの引数と戻り値を確認する

メソッドの動作を確認したい場合は、メソッドの入口と出口にブレークポイントを置きます。

C#
public int CalculateTotal(int price, int quantity)
{
    var total = price * quantity;
    return total;
}

メソッドの先頭では、引数priceとquantityを確認します。戻り値の直前では、totalの値を確認します。

不具合がある場合、引数が間違っているのか、メソッド内部の計算が間違っているのかを切り分けることができます。

引数が既におかしい場合は、呼び出し元に原因があります。引数は正しいのに戻り値がおかしい場合は、メソッド内部に原因があります。

7-4. LINQ処理の途中結果を確認する

LINQは便利ですが、処理がつながっているため途中結果が見えにくいことがあります。

C#
var result = users
    .Where(x => x.IsActive)
    .OrderBy(x => x.Name)
    .Select(x => x.Name)
    .ToList();

このような場合、途中結果を一時変数に分けるとデバッグしやすくなります。

C#
var activeUsers = users.Where(x => x.IsActive).ToList();
var orderedUsers = activeUsers.OrderBy(x => x.Name).ToList();
var result = orderedUsers.Select(x => x.Name).ToList();

それぞれの行にブレークポイントを置けば、どの段階で想定外の結果になっているか確認できます。

LINQのラムダ式内にブレークポイントを置ける場合もありますが、複雑な式では一時変数に分けたほうが分かりやすいです。

デバッグしやすさを考えると、複雑なLINQを1行に詰め込みすぎないことも重要です。

7-5. 非同期処理 async/await の流れを追う

C#のasync/awaitを使った非同期処理では、処理の流れが分かりにくくなることがあります。

C#
public async Task<User> GetUserAsync(int id)
{
    var user = await _repository.FindAsync(id);
    return user;
}

この場合、awaitの前後にブレークポイントを置くと、非同期処理の前後で値がどのように変わるか確認できます。

確認すべきポイントは次のとおりです。

メソッドが呼び出されているか
await前に必要な値が入っているか
await後に戻り値が取得できているか
例外が発生していないか
ConfigureAwaitの影響がないか
呼び出し元でawaitし忘れていないか

非同期処理では、呼び出し履歴が通常の同期処理と違って見えることがあります。Visual Studioの非同期呼び出し履歴やタスク関連の表示を使うと、流れを追いやすくなります。

7-6. ASP.NET Coreのリクエスト処理を追う

ASP.NET Coreでは、リクエストがどのように処理されるかを追うためにブレークポイントを使います。

よく設定する場所は次のとおりです。

Controllerのアクションメソッド
Minimal APIのエンドポイント
MiddlewareのInvokeまたはInvokeAsync
Serviceクラスのメソッド
Repositoryクラスのメソッド
認証・認可処理
例外ハンドリング処理

例えば、Controllerにブレークポイントを置きます。

C#
[HttpGet("{id}")]
public async Task<IActionResult> GetUser(int id)
{
    var user = await _userService.GetUserAsync(id);
    return Ok(user);
}

ここで止まらない場合は、ルーティング、HTTPメソッド、URL、ポート、起動プロファイルを確認します。

APIデバッグでは、ブラウザだけでなく、Postman、curl、Swagger UIなどからリクエストを送ることもあります。どのURLにアクセスしているか、どの環境に向いているかを必ず確認しましょう。

7-7. 単体テスト実行時にブレークポイントで止める

単体テストでブレークポイントを使う場合は、テストをデバッグ実行します。

Visual Studioのテストエクスプローラーでは、対象のテストを右クリックして「デバッグ」を選択します。通常の「実行」では、ブレークポイントで停止しない場合があります。

C#
[Fact]
public void CalculateTotal_ReturnsExpectedValue()
{
    var service = new OrderService();

    var result = service.CalculateTotal(1000, 2);

    Assert.Equal(2000, result);
}

テストコード内、またはテスト対象メソッド内にブレークポイントを置くことで、入力値、実行結果、失敗原因を確認できます。

テストが失敗する場合は、まずテストコード側の前提条件を確認し、その後で実装側の処理を追うと効率的です。

7-8. UnityのC#スクリプトをデバッグする

UnityでC#スクリプトをデバッグする場合は、Unity EditorとIDEを連携させる必要があります。

Visual Studioでは、Unityにアタッチしてデバッグします。RiderでもUnity連携を設定すると、Unity Editorに接続してブレークポイントを使えます。

よくブレークポイントを置く場所は次のとおりです。

Start
Awake
Update
FixedUpdate
OnCollisionEnter
OnTriggerEnter
ボタンのクリックイベント
独自メソッド

例えば、Updateにブレークポイントを置くと毎フレーム停止してしまうため注意が必要です。特定条件のときだけ止めたい場合は、条件付きブレークポイントを使います。

C#
playerHp <= 0

Unityでは、スクリプトのコンパイルエラーがあるとデバッグが正しく動かないことがあります。また、対象のGameObjectにスクリプトがアタッチされているか、処理が実際に呼ばれているかも確認しましょう。

8. ブレークポイント使用時によくあるエラー・疑問

C#のブレークポイントを使っていると、赤丸が白抜きになったり、警告アイコンが出たり、条件式が評価できなかったりすることがあります。ここでは、よくある疑問と対処法を解説します。

8-1. 赤丸が白抜きや警告アイコンになるのはなぜか

Visual Studioでブレークポイントの赤丸が白抜きになっている場合、そのブレークポイントは現在有効にバインドされていない可能性があります。

よくある原因は次のとおりです。

シンボルが読み込まれていない
ソースコードと実行中のコードが一致していない
該当行が実行可能なコードではない
ビルドされていない
別のプロジェクトを実行している
Releaseビルドで最適化されている

白抜きの赤丸は、「ここにブレークポイントはあるが、今の実行環境ではまだ有効になっていない」という状態を表していることが多いです。

デバッグ実行を開始すると有効になる場合もありますが、警告が出ている場合は原因を確認しましょう。

8-2. 「現在の設定ではブレークポイントにヒットしません」の意味

「現在の設定ではブレークポイントにヒットしません」というメッセージは、Visual Studioがそのブレークポイントを実行中のコードに対応付けられていないことを示します。

主な原因は、シンボルファイルが読み込まれていないことです。PDBがない、または実行中のDLLとPDBが一致していない場合に発生します。

対処法は次のとおりです。

Debugビルドにする
ソリューションをクリーンする
再ビルドする
スタートアッププロジェクトを確認する
実行中のプロセスを確認する
モジュールウィンドウでシンボル読み込み状況を確認する
binやobjを削除して再ビルドする

このメッセージが出た場合は、ブレークポイントの設定ミスではなく、実行環境やビルド成果物の不一致を疑うとよいでしょう。

8-3. 条件式が評価できない場合の対処法

条件付きブレークポイントで条件式が評価できない場合、まず変数が現在のスコープに存在するか確認します。

例えば、次の条件式を設定したとします。

C#
user.Id == 100

しかし、その行でuserという変数がまだ宣言されていなければ評価できません。また、userがnullの場合、user.Idの評価で問題が起きる可能性があります。

対処法として、次のようにnullチェックを追加します。

C#
user != null && user.Id == 100

また、プロパティやメソッドの評価に失敗している場合は、条件式を単純にします。

複雑な条件式がうまく動かない場合は、一度通常のブレークポイントで停止し、ウォッチウィンドウで同じ式を評価してみると原因を特定しやすくなります。

8-4. ブレークポイントを削除しても復活する場合

ブレークポイントを削除したはずなのに復活する場合、IDEがデバッグ設定を保存・復元している可能性があります。

Visual Studioでは、ソリューションのユーザー設定にブレークポイント情報が保存されることがあります。また、チーム開発で設定ファイルや拡張機能が影響している場合もあります。

対処法としては、ブレークポイント一覧ウィンドウからすべて削除する、Visual Studioを再起動する、ソリューションのユーザー設定ファイルを確認する、といった方法があります。

ただし、設定ファイルを削除する場合は、他のIDE設定も消える可能性があるため注意してください。

8-5. デバッグ中にブレークポイントを追加してもよいか

多くの場合、デバッグ中にブレークポイントを追加しても問題ありません。

プログラムを実行しながら、気になった行にブレークポイントを追加できます。追加したブレークポイントは、その後その行に到達したときに有効になります。

ただし、既に通過した行に追加しても、処理が再びその行を通らない限り停止しません。その場合は、再実行するか、呼び出し元に戻れる状況であればステップ実行を調整します。

また、実行中にコードを変更する場合は、Hot ReloadやEdit and Continueが利用できる環境かどうかによって挙動が変わります。すべての変更がデバッグ中に反映されるわけではないため、反映されない場合は再ビルドして再実行しましょう。

8-6. 外部ライブラリやNuGetパッケージで止められるか

外部ライブラリやNuGetパッケージでも、条件がそろえばブレークポイントで停止できます。

ただし、通常はソースコードやシンボルが必要です。NuGetパッケージのソースリンクやシンボルが提供されている場合、Visual Studioで外部コードにステップインしたり、ブレークポイントを設定したりできることがあります。

外部ライブラリで止めたい場合は、次の点を確認します。

シンボルが利用できるか
ソースコードが取得できるか
Just My Codeの設定が影響していないか
対象DLLのバージョンが一致しているか
最適化されたコードではないか

ただし、外部ライブラリの内部まで追うと調査範囲が広がりすぎることがあります。まずは自分のコードから渡している引数や、外部ライブラリから返ってくる値を確認するのがおすすめです。

9. ブレークポイントを効率よく使うためのベストプラクティス

ブレークポイントは便利ですが、やみくもに設定すると逆にデバッグが非効率になります。ここでは、C#開発でブレークポイントを効率よく使うための考え方を紹介します。

9-1. 最初に止める場所を決めてからデバッグする

デバッグを始める前に、まず「どこで止めるべきか」を考えましょう。

不具合が起きている場所にいきなりブレークポイントを置くのではなく、処理の入口、値が作られる場所、値が変わる場所、例外が出る直前などを整理します。

例えば、画面に表示される金額が間違っている場合、次のように調査ポイントを分けます。

入力値を受け取る場所
計算処理を行う場所
割引や税計算を行う場所
画面表示用に変換する場所
レスポンスを返す場所

このように処理の流れを分解して、最も原因に近そうな場所からブレークポイントを置くと効率的です。

9-2. 条件付きブレークポイントを使って確認範囲を絞る

ループや大量データ処理では、通常のブレークポイントでは止まりすぎてしまいます。

そのような場合は、条件付きブレークポイントを使って確認範囲を絞ります。

例えば、特定のIDだけ止める場合は次のようにします。

C#
user.Id == 100

エラーになりそうな値だけ止める場合は、次のようにします。

C#
amount < 0

条件付きブレークポイントを使えば、問題が起きるケースに集中できます。デバッグ時間を短縮し、不要な停止によるストレスも減らせます。

9-3. 不要なブレークポイントは無効化・削除する

デバッグを続けていると、ブレークポイントが増えていきます。不要なブレークポイントが残っていると、関係ない場所で何度も停止してしまい、作業効率が下がります。

調査が終わったブレークポイントは削除しましょう。後でまた使う可能性がある場合は、削除ではなく無効化しておくと便利です。

ブレークポイント一覧ウィンドウを使えば、複数のブレークポイントをまとめて管理できます。

デバッグ後に整理する習慣をつけると、次回の調査がスムーズになります。

9-4. ログ出力とブレークポイントを使い分ける

ブレークポイントは、ローカル環境で処理を止めて詳しく確認するのに向いています。一方、ログ出力は、処理を止めずに長時間の動作や本番に近い状況を確認するのに向いています。

ブレークポイントが向いている場面は次のとおりです。

ローカル環境で再現できる
特定の変数を詳しく見たい
処理を1行ずつ追いたい
例外発生直前の状態を見たい

ログ出力が向いている場面は次のとおりです。

本番環境や検証環境で調査する
長時間の処理を確認する
複数ユーザーの操作を追う
デバッグで止めるとタイミングが変わる処理を調べる

どちらか一方だけでなく、状況に応じて使い分けることが大切です。トレースポイントを使えば、コードにログを追加せずに停止なしの出力もできます。

9-5. 再現手順を固定してから原因を追う

不具合調査では、ブレークポイントを置く前に再現手順を固定することが重要です。

再現手順が曖昧なままデバッグすると、毎回違う状態で止まり、原因を見失いやすくなります。

最低限、次の点を整理しましょう。

どの画面で発生するか
どの入力値で発生するか
どのユーザーで発生するか
どの操作順で発生するか
どの環境で発生するか
毎回発生するのか、たまに発生するのか

再現手順が明確になれば、どこにブレークポイントを置くべきかも判断しやすくなります。

特に、ASP.NET Core、非同期処理、マルチスレッド処理、Unityのイベント処理では、再現条件が重要です。まず再現性を確保し、そのうえでブレークポイントを使って原因を追いましょう。

9-6. デバッグ後に設定を整理する

デバッグが終わったら、設定を整理しましょう。

不要なブレークポイントを削除する
一時的に追加したログやデバッグコードを消す
条件付きブレークポイントを解除する
無効化したブレークポイントを確認する
ビルド構成を必要に応じて戻す
変更したIDE設定を確認する

デバッグ用のコードや設定が残っていると、後で別の不具合の原因になることがあります。

特に、Console.WriteLine、一時的なif文、テスト用の固定値、コメントアウトした処理などは消し忘れに注意が必要です。

ブレークポイントはソースコードを変更しないため安全に使いやすいですが、条件付きブレークポイントや例外設定が残っていると、次回のデバッグ時に意図しない停止が発生することがあります。

デバッグ後の整理まで含めて、効率的な開発習慣にしましょう。

まとめ

C#のブレークポイントは、デバッグ作業を効率化するための基本かつ重要な機能です。プログラムを任意の行で停止し、変数の値、条件分岐、呼び出し履歴、例外発生箇所などを確認できます。

Visual Studioでは、行番号の左側をクリックするか、F9キーでブレークポイントを設定できます。F5でデバッグ実行すれば、該当行に到達したときに処理が停止します。停止後は、ウォッチ、ローカル、自動変数、呼び出し履歴、ステップ実行を使って原因を追跡します。

ブレークポイントが止まらない場合は、Debugビルドになっているか、デバッグ実行しているか、ソースコードと実行中のコードが一致しているか、PDBなどのシンボルが読み込まれているかを確認しましょう。ASP.NET Core、Unity、単体テストでは、実行方法やアタッチ先が正しいかも重要です。

また、条件付きブレークポイントを使えば、特定の変数値やヒット回数に応じて停止できます。ループ処理や大量データ処理では、通常のブレークポイントよりも効率的に調査できます。

さらに、トレースポイント、関数ブレークポイント、例外ブレークポイント、データブレークポイント、一時ブレークポイントなどを活用すれば、より高度なデバッグが可能です。

C# breakpointを正しく使いこなすことで、不具合の原因調査にかかる時間を大幅に短縮できます。まずは基本的なブレークポイントの設定とステップ実行に慣れ、必要に応じて条件付きブレークポイントや例外ブレークポイントを使い分けていきましょう。