Visual StudioでC/C++をデバッグしようとすると「The Application is in Break Mode」と表示されるのに、ブレークポイントで止まらずContinueで普通に動く――この症状は、コードよりもVisual Studio側の状態（キャッシュ破損やインストール不整合）が原因になっていることがあります。再現パターンの整理から、効きやすい対処手順を順番に解説します。
症状：Break Modeダイアログが出るのにブレークポイントで停止しない
Visual StudioのC/C++デバッグでは、通常はソースに置いたブレークポイントで実行が停止し、変数・コールスタック・ウォッチなどの情報を確認できます。ところが、次のような状態に陥ると「止まるはずの場所で止まらない」ため、作業が完全に詰まります。
| 項目 | 内容（よくある例） |
|---|---|
| 環境 | Windows 10 + Visual Studio 2022（例：17.12.x、Previewでも発生） |
| 現象 | ブレークポイントを置いてF5実行すると、「The Application is in Break Mode」が突然出る |
| 困る点 | ブレークポイントにヒットせず、Continueでそのまま正常動作してしまう |
| 付随症状 | コールスタックが空、例外設定を追加しても改善しない、別PCでは同じコードが止まる |
この状況で重要なのは、ソースやロジックに問題があるとは限らないことです。特に「同じコードが別PC（古いVSや別環境）だと普通に止まる」「VSが生成した新規プロジェクトでも同様」という条件がそろうと、疑うべきはプロジェクトよりも開発環境（Visual Studio本体・デバッグ周辺コンポーネント・キャッシュ）です。
まず理解：なぜ「Break Mode」なのに“止まった気がしない”のか
Visual Studioのデバッガーは内部的に複数の「デバッグエンジン（コードタイプ）」を使い分けています。代表例は次の通りです。
- Native（ネイティブ：C/C++の通常のデバッグ）
- Managed（.NET：C#など）
- Script（JavaScriptなど）
- 混在（Mixed：ネイティブとマネージドを同時に追う）
「The Application is in Break Mode」のダイアログでよくある文面は、要約すると『アプリはブレーク状態に入ったが、選択中のデバッグエンジンが扱えるコードが実行されていない』という意味です。つまり、デバッガーが何らかの理由で“中断状態”を検知したのに、現在選ばれているエンジンではその場所のコードを表示できず、結果として次のように見えます。
- ブレークポイントで止まらない（ヒットしていない）
- 止まったとしても、該当ソースへ飛べない
- コールスタックが空、もしくは表示が不自然
- Continueすると問題なく動き続ける
この挙動は「例外を止めたい」のではなく、“普通のブレークポイントが機能していない”ケースで起きやすいのが特徴です。Win32 Exceptionsに特定コード（例：0xE008000B等）を追加するのは、あくまでその例外が投げられた瞬間に止めるための設定なので、ブレークポイント自体が効いていない場合は根本解決になりにくいです。
最短で切り分ける：プロジェクトが原因か、VS環境が原因か
まずは「原因がコード側か、環境側か」を短時間で判定します。ここがブレると、無関係な例外設定やソース改修に時間を溶かしがちです。
- Visual Studioで新規の「C++ コンソール アプリ」（またはGUIでも可）を作る
mainの先頭にブレークポイントを置く- F5で実行し、ブレークポイントで停止するか確認する
この“真っさらなテンプレート”でも同症状が出るなら、ほぼ環境要因と考えてよいです。逆に新規プロジェクトでは止まるなら、既存プロジェクト側の設定（成果物のズレ、起動設定、シンボル、最適化など）を重点的に見ます。
まず確認したいチェックリスト
以下のチェックは、再現性のある「ブレークポイントが止まらない」問題で特に効果が高いものです。上から順に潰すと、原因の取りこぼしが減ります。
| チェック項目 | 見る場所・やること | よくある落とし穴 |
|---|---|---|
| Debug構成になっているか | ツールバーのソリューション構成がDebug、Configuration Managerで各プロジェクトもDebug | 一部プロジェクトだけRelease、または別構成の成果物を実行している |
| 最適化の影響 | プロパティの最適化がDebug相当になっているか（通常は無効） | 最適化で行が統合・消滅し、ブレークポイント位置と命令が一致しない |
| 実行しているEXEが正しいか | プロジェクトの「デバッグ」設定でCommand/Working Directoryを確認 | 古いフォルダのEXE、別構成のEXEを起動している |
| シンボル（PDB）の読み込み | デバッグ中に「モジュール」ウィンドウでSymbol Statusを見る | PDB未生成・未配置・パス不一致で、ソースと紐付かない |
| デバッグエンジンがNativeか | （混在プロジェクト等）Attach/起動時のコードタイプがNativeを含む | Managedのみで起動し、C/C++の命令位置を追えない |
| キャッシュ破損 | .vs/bin/obj削除→再生成、設定リセット、Repair | VS更新後にだけ起きる、テンプレでも起きる場合はここが濃厚 |
対処手順：効く可能性が高い順
ここからは、実際に「止まらない」状態から復旧しやすい手順を、効果が出やすい順にまとめます。重要なのは、上から順に、ひとつずつ結果を確認しながら進めることです（複数を同時にやると、どれが効いたのか分からなくなります）。
Debugビルドを徹底的に確認し、Rebuildで成果物を揃える
最初に疑うべきは「Debugで動かしているつもりが、別の成果物を実行している」パターンです。C/C++は最適化やリンクの差で、同じソースでも実行コードが大きく変わり、ブレークポイントが外れる原因になります。
- ツールバーの構成がDebugになっているか確認
- 「ビルド」→「構成マネージャー」で、対象プロジェクトの構成がDebugでビルドされるか確認
- 「ビルド」→「ソリューションのリビルド」を実行（Rebuild）
合わせて、ブレークポイントが赤丸（有効）なのか、白丸＋警告（未解決）なのかも見てください。白丸で「シンボルが読み込まれていない」系のメッセージが出るなら、次の“シンボル確認”の優先度が上がります。
.vs / bin / obj を削除してクリーンビルドする
Visual Studioは補助情報を大量にキャッシュします。キャッシュが破損したり、更新の途中で不整合が起きたりすると、デバッグ情報（ソースと実行コードの紐付け）が狂ってブレークポイントが効かなくなることがあります。
手順
- Visual Studioを完全に終了する（バックグラウンドで残っていないかも確認）
- ソリューション直下で、次のフォルダを削除する：.vs、各プロジェクトのbin、obj
- Visual Studioを起動し直してソリューションを開く
- ビルド（可能ならRebuild）→ F5で再テスト
手作業が面倒なら、ソリューション直下で次のようなPowerShellを使うと削除漏れを減らせます（実行前に必ずVSを閉じ、誤って別フォルダで実行しないよう注意してください）。
Get-ChildItem -Force -Recurse -Directory -Include ".vs","bin","obj" | Remove-Item -Recurse -Forceこれで直る場合は「キャッシュの不整合」が主因です。直ったあとも再発するなら、VS拡張やPreview版の更新がトリガーになっている可能性があるため、後述の“再発防止”も合わせて見直すと安心です。
デバッグ設定（Nativeで動いているか）を確認する
「Break Modeなのにサポートされるコードが実行されていない」という文面が出る場合、そもそもNativeデバッグとして起動・アタッチできていない可能性があります。特に、次のような混在環境で起きやすいです。
- C/C++のEXEを、別のホスト（例：.NETアプリ、サービスランチャー）から起動している
- Attach to Processで、コードタイプがManagedのみになっている
- C++/CLIなどで、Mixed運用の設定が崩れている
| シナリオ | 確認ポイント | 狙い |
|---|---|---|
| C/C++プロジェクトをF5起動 | プロジェクトのプロパティ →「デバッグ」でLocal Windows Debugger相当で起動できているか | 起動時にNativeデバッグエンジンが有効になる状態を作る |
| プロセスにアタッチしてデバッグ | デバッグ →「プロセスにアタッチ」→「アタッチ先」でNativeを含める | “別のコードタイプだけ”で付いている状態を排除する |
| .NETからネイティブDLL/EXEを呼ぶ | （.NET側設定で）ネイティブコードデバッグを有効にできるか確認 | Managed-onlyで止まれない問題を避ける |
ここでのポイントは、例外設定よりも“どのデバッグエンジンで追っているか”です。C/C++のブレークポイントが効かないのに例外コードを追加しても、根本原因（エンジン不一致・シンボル不一致）が残っていると改善しません。
シンボル（PDB）とモジュール状態を確認する
ブレークポイントがヒットしない場合、実は「ヒットしているがソースに紐付かず、別の場所で止まっている」ことがあります。そこで有効なのがモジュールとシンボルの確認です。
見る場所（代表例）
- デバッグ中：デバッグ → ウィンドウ →「モジュール」
- ブレークポイント一覧：デバッグ → ウィンドウ →「ブレークポイント」
- 出力ウィンドウ：デバッグ出力に「Symbols loaded」などのログが出ることがある
| 状態 | 見え方 | 対策の方向性 |
|---|---|---|
| PDBが読み込まれている | モジュールのSymbol Statusが「Symbols loaded」 | ソースの場所・行番号のズレ（最適化、別成果物）を疑う |
| PDBが読み込まれていない | 「Cannot find or open the PDB file」等 | Debug情報生成、出力先、ビルド/配置、シンボルパスを疑う |
| ブレークポイントが未解決 | 白丸、または「現在ヒットしません」表示 | “そのソースが今の実行バイナリに含まれていない”可能性を疑う |
「コールスタックが空」のような症状も、シンボルやデバッグエンジンが噛み合っていないと起きます。ここでシンボル状態が正常なのにおかしい場合は、いよいよ環境側（VS自体）の疑いが強くなります。
Visual Studioの設定をリセットする（設定破損の切り分け）
デバッグ関連のオプションや拡張の影響で挙動が変わることがあります。設定破損の可能性を切るには、既定値へのリセットが手早いです。
- Visual Studioの「ツール」→「設定のインポートとエクスポート」
- 必要なら現在の設定をエクスポートして退避
- 「すべての設定をリセット」を実行（可能ならVisual C++に近いプロファイル）
リセット後にブレークポイントが復旧するなら、原因は設定・拡張の影響である可能性が高いです。拡張機能を多く入れている場合は、いったん無効化して挙動が変わるかを見てもよいでしょう。
最終的に効くことが多い：Visual Studio InstallerのRepair（修復）
ここまでの手順で改善しない場合、今回のようにVisual Studioのインストール修復（Repair）で復旧するケースがあります。とくに「新規C++プロジェクトでも同じ」「Previewでも起きる」「例外設定では直らない」といった条件がそろうと、Repairの優先度は高いです。
実施手順（代表例）
- Visual Studioを終了する
- スタートメニューからVisual Studio Installerを起動する
- 対象のVisual Studio 2022を選び、「その他」からRepair（修復）を実行する
- 完了後、必要ならPCを再起動し、再度デバッグを試す
| Repair前に確認 | 理由 |
|---|---|
| C++のワークロード（Desktop development with C++）が入っているか | C/C++のデバッグに必要なコンポーネントが欠けていると再発しやすい |
| Windows SDKが入っているか | デバッグ・ビルド・シンボル周りの依存が崩れるのを防ぐ |
| Previewと安定版を併用している場合は、どちらで起きるか | 片方だけの不具合なら、チャンネル変更で回避できることがある |
Repairで直る場合、内部のデバッガー関連コンポーネントや、更新で壊れた可能性のあるファイル群が再配置され、Nativeデバッグが正常復帰します。Rollbackができない状況でも、Repairだけで復旧することがあるのがポイントです。
Repairで直るケースにありがちな背景
「なぜ修復で直るのか」を知っておくと、再発時の判断が速くなります。代表的な背景は次の通りです。
- 更新の途中で不整合が発生し、デバッグエンジンや関連DLLの整合が崩れた
- ワークロード追加・削除の過程で、C++デバッグ周りのコンポーネントが欠けた／古い状態で残った
- 拡張機能や設定の影響で、デバッグ起動時のコードタイプ判定が不安定になった
- キャッシュ（.vs等）と本体の組み合わせが悪くなり、シンボル解決やソース紐付けが崩れた
特に「テンプレートプロジェクトでも止まらない」場合、個別プロジェクトの設定をいくら眺めても答えが出ないことが多く、Repairを早めに試す方が結果的に近道になります。
それでも直らない場合の追加アクション
Repairでも改善しないときは、次の順で“環境をさらに疑う”のが現実的です。
- Preview版から安定版へ切り替え、または安定版のみに寄せる（可能なら）
- 拡張機能をいったん全停止し、デバッグ挙動が戻るか確認する
- Visual Studio Installerの「変更（Modify）」でC++ワークロードとSDKを入れ直す
- セキュリティソフトの例外設定（開発フォルダ、デバッガー関連）を検討する
- 最終手段としてアンインストール→再インストール（環境依存の破損を完全に排除）
なお、業務環境などで再インストールが難しい場合は、「新規Windowsユーザープロファイルで同現象が出るか」を試すと、ユーザープロファイル内の設定破損かどうかを切り分けやすくなります。
よくある質問
例外設定にコードを追加したのに直りません。やり方が違いますか？
ブレークポイントが効かない問題に対して、例外設定は“主戦場”になりにくいです。例外設定は、特定の例外が発生した瞬間に止めるための機能であり、ブレークポイントの解決（ソースと実行コードの紐付け）とは別系統です。まずはDebug構成・成果物・シンボル・Nativeデバッグの確認を優先してください。
コールスタックが空になります。これはバグですか？
バグの可能性もありますが、まずは「正しいデバッグエンジンで止まれているか」「シンボルが読み込まれているか」を疑うのが先です。エンジン不一致やシンボル不一致があると、停止していてもソースやスタック情報を復元できず、空に見えることがあります。
同じコードが別PCでは止まります。コード側を修正する必要はありますか？
別PCで再現しないなら、コードより環境差が濃厚です。特にVisual Studioのバージョン・インストール状態・拡張・SDK・セキュリティ設定が違うと、デバッグ挙動は大きく変わります。テンプレートプロジェクトでの再現確認→Repairという流れが有効です。
再発を防ぐにはどうすればいいですか？
次の運用が効きやすいです。
- Previewを常用するなら、安定版の環境も残して“比較できる逃げ道”を作る
- デバッグが急におかしくなったら、まず.vs/bin/obj削除をルーチン化する
- ワークロード追加・削除の直後に異常が出たら、Installerで「変更」や「修復」を早めに試す
- 拡張機能は必要最低限にし、デバッグ周りに影響しそうなものは段階的に導入する
まとめ：ブレークポイントが止まらないときは“順番”が重要
「Break Modeが出るのに止まらない」という症状は、見た目のメッセージに引っ張られて例外設定やコード改修に走りがちです。ですが、実際にはDebug構成の不一致、キャッシュ不整合、Nativeデバッグエンジンの不一致、シンボル未読み込み、そしてVisual Studio本体の破損という順で起きることが多いです。
まずはテンプレートプロジェクトで環境要因かどうかを判定し、.vs/bin/obj削除→設定リセット→Repairまでを一直線で試せるようにしておくと、復旧までの時間を大きく短縮できます。特に、テンプレートでも再現する場合は、Repairが“最終手段”ではなく最短の解決策になることもあります。
コメント