.NET MAUI（.NET 9）アプリを Android エミュレーターでデバッグ起動すると、「Waiting for Debugger（デバッガーを待機中）」で止まり続けて先に進まないことがあります。本記事では、原因の考え方と、AVD再作成・adbリセットなど実務で効きやすい対処を手順化して解説します。
「Waiting for Debugger（デバッガーを待機中）」で止まる現象とは
Visual Studio から .NET MAUI（.NET 9）プロジェクトを Android エミュレーター（例：Pixel_7_api_34 / Android API 34）で起動した際、アプリ側に次のようなポップアップが出て、そのまま画面が固まったように見えるケースがあります。
- 「Application … is waiting for the debugger to attach」
- 「デバッガーを待機中（Waiting for Debugger）」
これは、アプリがクラッシュしているというより、“デバッガーが接続されるまで処理を止めて待っている”状態です。通常なら数秒で Visual Studio のデバッガーがアタッチされて消えますが、何らかの理由でアタッチできないと永遠に待機し続けます。
まず押さえるべき原因の方向性（結論）
この症状は、エミュレーター内部の状態不良やadb（Android Debug Bridge）の接続不調で、デバッグ用のプロセスに Visual Studio がうまくアタッチできないときに起きやすいです。特に、エミュレーターのスナップショット（高速起動）やキャッシュ、ホストPCのメモリ/ディスク逼迫、ネットワーク/仮想化の揺らぎが重なると再現しがちです。
| 起きていること | よくある実態 | 効きやすい対処 |
|---|---|---|
| アプリが「待機」している | デバッグ起動フラグが立ったまま、アタッチが来ない | adb再起動、エミュレーターCold Boot/Wipe Data |
| 同じAVDで再発を繰り返す | AVDのスナップショットやデータ破損、ストレージ不足 | AVD削除→再作成、空き容量確保 |
| たまにだけ発生する | ホストPC負荷、VPN/セキュリティ、adbが複数常駐 | PC再起動、VPN/セキュリティ確認、adbの一本化 |
最短で復旧させる「基本の回避策」
まずは、スレッド等でも最も再現性が高い“現場の応急処置”から実施します。目的は、壊れた状態（AVD/adb/デバッグセッション）を一度リセットして正常ルートに戻すことです。
Visual Studio を再起動（最短で効くことがある）
デバッグセッションやデバイス検出が中途半端に残っている場合、Visual Studio の再起動だけで復帰することがあります。まずは最短ルートとして試します。
対象の Android エミュレーター（AVD）を削除して作り直す
「Waiting for Debugger」で止まる状態が、エミュレーター側の破損・不調に起因する場合、AVDの再作成は効果が高いです。特定の AVD（例：Pixel_7_api_34）だけが壊れているパターンは珍しくありません。
- Android Device Manager（または Android Studio の Device Manager）で該当 AVD を削除
- 同等の構成で新規に AVD を作成（同じAPIレベル/同じ端末プロファイルでもOK）
- できれば作成後、最初の起動は “Cold Boot” で行う
この時点で一旦直るケースは多いですが、再発する場合は次章の「恒久寄りの安定化」まで一気に進めるのが効率的です。
再発しやすい人向け：恒久寄りの安定化（エミュレーター/adbの“環境リセット”）
Cold Boot（コールドブート）と Wipe Data（データ消去）を使い分ける
AVDを作り直さなくても、エミュレーターの状態を初期化することで改善することがあります。ポイントは、スナップショット（高速起動）の“悪い状態”を引きずらないことです。
| 操作 | 何をするか | 向いている症状 | 注意点 |
|---|---|---|---|
| Cold Boot | スナップショットを使わずに完全起動 | たまに止まる、起動が不安定、デバッグ接続が揺れる | アプリデータは残る場合が多い |
| Wipe Data | 端末データを消去して初期状態へ | 繰り返し止まる、ログイン/設定周りが壊れた感じがする | 端末内データは消える（初回セットアップから） |
頻繁に再発するなら、まず Wipe Data を試し、それでもダメなら AVD 再作成まで進めるのが現実的です。
adb を再起動して接続状態をリセットする
Visual Studio のデバッグは最終的に adb 経由でアプリに接続します。adb が不調だと「待機」状態から抜けられません。次のコマンドで adb サーバーを再起動します。
adb kill-server
adb start-server
adb devicesadb devices の結果で、エミュレーターが device として認識されているか確認します。もし offline 表示や一覧に出ない場合、エミュレーター側の再起動（Cold Boot）や、USB/仮想ネットワーク周りの不調が疑われます。
Platform-Tools（adb）と Android Emulator を最新化する
Android SDK の Platform-Tools（adb）や Emulator は、更新で安定性が改善されることが多い領域です。特に API 34 系のエミュレーター運用では、古いツールのままだと挙動が怪しくなることがあります。
- Android SDK Manager で Android SDK Platform-Tools を更新
- Android Emulator を更新
- 必要なら System Image（API 34 など）も更新
更新後は、念のため adb 再起動（kill/start）もセットで実施すると、古いサーバー状態を引きずりません。
PCの空きディスク/メモリ不足を解消する（見落とされやすい本命）
エミュレーターはストレージ・メモリ・仮想化リソースを強く消費します。空き容量が減っている環境や、ブラウザ/IDE/コンテナ等を同時に使っている環境では、突然「待機」系の不調が出ることがあります。
- システムドライブの空き容量を増やす（エミュレーターのディスク拡張/スナップショットも含めて消費）
- メモリ消費の大きいプロセスを閉じる（ブラウザタブ、VM、Docker、重いビルドなど）
- エミュレーターの RAM 設定を適正化（盛りすぎるとホストが枯れる）
切り分けの考え方：原因を「エミュレーター起因」か「環境起因」か分ける
闇雲に試すと時間が溶けるので、状況から当たりを付けます。次の表のように、症状から優先順位を付けると効率が上がります。
| 観察ポイント | こうなら疑う | 最初の一手 |
|---|---|---|
| 特定の AVD だけ発生 | AVDデータ破損、スナップショット不調 | Cold Boot → Wipe Data → AVD再作成 |
| どの AVD でも発生 | adb不調、SDK不整合、VS側の不調 | adb再起動、SDK/Emulator更新、VS再起動 |
| PC再起動で直るが再発 | メモリ/ディスク逼迫、バックグラウンド常駐の影響 | リソース見直し、セキュリティ/ VPNの確認 |
| 実機はOK、エミュだけNG | エミュレーター固有の問題 | AVD再作成、Emulator更新、設定見直し |
実務で効くチェックポイント（Visual Studio / MAUI 側）
エミュレーターや adb の問題が多いとはいえ、Visual Studio 側の操作・設定がトリガーになっていることもあります。以下は「やりがち」かつ「戻しやすい」項目です。
「デバッグなしで開始」で症状が変わるか確認する
まず、Ctrl+F5（デバッグなしで開始）で起動し、待機せずに動くかを確認します。
- デバッグなしだと動く → 「デバッガーのアタッチ」周りが怪しい（adb/ポート/セッション）
- デバッグなしでも待機する → 端末側に「待機設定」が残っている可能性（後述のクリア手順）
デバッグターゲットが正しいか（複数デバイスで迷子になりやすい）
Android エミュレーターを複数作っていると、Visual Studio が別のデバイスにデプロイしようとして失敗し、結果として待機が解消されないことがあります。
- ツールバーのターゲットが狙いの AVD になっているか
- 古いエミュレーターが裏で起動していないか（別AVDが常駐）
- 物理端末が同時接続されていないか（意図せずそちらを優先することも）
出力ウィンドウで「どこまで進んでいるか」を見る
Visual Studio の 出力（Output）には、デプロイ→起動→デバッガー接続の流れが断片的に残ります。待機が出た時は、次の観点で見ます。
- ビルドは通っているか
- APK/Bundle のデプロイで止まっていないか
- adb コマンド実行でタイムアウトしていないか
- 「接続」「アタッチ」相当のログが出ていないか
ここで adb のタイムアウトやデバイス検出エラーが見えるなら、対処はほぼ adb/エミュ側に寄せてOKです。
“待機フラグが残る”ケースの対処（知っていると強い）
通常、デバッグ起動時にだけアプリが「デバッガー待ち」になりますが、まれに端末側に「このアプリはデバッガーを待て」という状態が残り、以後ずっと待機することがあります。そんなときは、端末側の状態を明示的にクリアします。
デバッグ待機設定をクリアする
次のコマンドで、端末側の「デバッグ対象アプリ設定」を解除します。
adb shell am clear-debug-appその後、問題のアプリを完全停止してから再起動します。
adb shell am force-stop com.example.yourappパッケージ名（com.example.yourapp）はプロジェクトのアプリIDに合わせてください。Visual Studio の出力ログや、AndroidManifest、プロジェクト設定から確認できます。
アプリを一度アンインストールしてクリーンにする
デバッグ関連の状態がアプリデータと絡んでいる場合、アンインストール→再デプロイが手っ取り早いことがあります。
adb uninstall com.example.yourapp特に、AVDを Wipe Data した直後など「どうせ初期状態」なら、ここまでやると再発率が下がることがあります。
adb が複数存在する問題（Android Studio と共存している人は要注意）
開発PCに Android Studio と Visual Studio を両方入れていると、別々の SDK/Platform-Tools を参照して、adb が二重管理になりがちです。結果として、
- 片方が adb サーバーを起動
- もう片方が別の adb で接続しようとして不整合
- デバイスが見えたり見えなかったりする
といった揺らぎが起き、デバッガーのアタッチが失敗しやすくなります。
対策の方向性は次のとおりです。
- 使う SDK の場所を一本化する（Visual Studio 側の設定が参照する SDK を確認）
- 困ったときは adb を一度 kill/start して、接続元を揃える
- Android Studio を起動したままデバッグしているなら、いったん終了して挙動を見る
ネットワーク/セキュリティ/仮想化が絡むパターン
「毎回ではない」「会社PCでだけ起きる」「VPN接続時だけ起きる」といった場合、エミュレーターそのものより、周辺要因の影響が大きいことがあります。
VPN・プロキシ・セキュリティソフトの影響
adb はローカルでポート通信を使います。環境によっては、セキュリティソフトが “未知のデバッグ通信” を制限し、結果的にアタッチが不安定になることがあります。
- VPNを切った状態で再現するか
- セキュリティソフトの隔離/ブロック履歴が出ていないか
- 企業プロキシ環境で、開発者向けの例外設定が必要になっていないか
この手の要因は「たまたま直ったり再発したり」しがちなので、再現条件をメモしておくと次回の復旧が速くなります。
仮想化基盤（Hyper-V / WHPX など）の揺らぎ
Windows 環境では、Android エミュレーターが仮想化機能（WHPX/Hyper-V 等）に依存します。Windows Update 直後や、他の仮想化ソフト（VM、コンテナ、別のエミュレーター）が同居していると、不安定になることがあります。
- エミュレーターの起動自体が遅い/固まる場合は仮想化やGPU周りも疑う
- 同時に別の仮想化（VM/コンテナ）を走らせているなら一度止めて確認する
- 改善しないときは AVD 再作成 + Cold Boot をセットで実施
それでも直らない場合の「最終手段」：実機デバッグで切り分け
エミュレーターでのデバッグが不安定なとき、物理端末（実機）で同じプロジェクトをデバッグしてみると、原因の切り分けが一気に進みます。
| 結果 | 判断 | 次にやること |
|---|---|---|
| 実機は正常にアタッチできる | エミュレーター/AVD側の問題が濃厚 | AVD再作成、Emulator更新、PCリソース見直し |
| 実機でも待機して止まる | adb/環境/プロジェクト設定側の問題が濃厚 | adb一本化、SDK更新、待機設定クリア、VS設定確認 |
「とりあえず開発を進めたい」という観点でも、実機が手元にあるなら一時的な避難先として優秀です。エミュレーターでの再現と比較しながら、根本原因に当たりを付けられます。
再発防止のための運用ルール（おすすめ）
同じ問題が繰り返し起きるチーム/個人環境では、“不調になりにくい運用”を作っておくと無駄な時間が減ります。
エミュレーターは「壊れたら捨てる」前提で設計する
AVD は便利ですが、長期間使い続けるほど状態が濁りやすい側面があります。次のように割り切ると、復旧が速くなります。
- AVD は用途別に少数に絞る（多すぎると管理が崩れる）
- 不調が出たら Wipe Data で戻す（それでダメなら再作成）
- “いつでも作り直せる”ように、必要な設定はメモしておく
SDK/Emulator/Platform-Tools は定期的に更新する
.NET MAUI（.NET 9）の開発では、IDE（Visual Studio）だけでなく、Android 側のツールチェーンも安定性に直結します。更新を後回しにすると、ある日突然、特定APIや特定AVDでデバッグが崩れることがあります。
ホストPCの余力を確保する（特にディスク）
エミュレーターはディスクを意外と食います。ビルド成果物、NuGetキャッシュ、Androidのシステムイメージ、スナップショット等が積み重なると、いつの間にか逼迫して不調になります。月1回でも良いので「空き容量チェック」をルーチン化すると効果的です。
すぐ使える復旧手順まとめ（コピペ用チェックリスト）
最後に、現場でそのまま使える形に手順をまとめます。時間がないときは上から順に実施してください。
| 優先度 | 手順 | 狙い |
|---|---|---|
| 高 | Visual Studio を再起動 | デバッグセッションの残骸をリセット |
| 高 | エミュレーターを Cold Boot | スナップショット由来の不調を排除 |
| 高 | adb 再起動（kill/start）→ adb devices 確認 | adb の接続不調を解消 |
| 中 | Wipe Data | 端末データ破損/濁りを初期化 |
| 中 | Platform-Tools/Emulator を更新 | 既知不具合や相性問題の回避 |
| 中 | ディスク/メモリの余力を確保 | 負荷起因の不安定さを減らす |
| 低 | adb shell am clear-debug-app → force-stop | 待機フラグが残る系の例外を潰す |
| 低 | AVD 削除→再作成 | AVD固有の破損を“作り直し”で解決 |
| 低 | 実機でデバッグして切り分け | 原因がエミュか環境かを確定させる |
よくある質問
「エミュレーター再作成で直ったのに、またすぐ再発する」のはなぜ？
AVD自体が壊れている場合は再作成で一旦治りますが、根っこに「adb不安定」「PCリソース不足」「VPN/セキュリティの干渉」「仮想化の揺らぎ」が残っていると、別のAVDでも再発します。再発する場合は、adb再起動・ツール更新・空き容量の3点を優先的に疑ってください。
「Waiting for Debugger」が出たままでもアプリの動作確認だけしたい
まずは デバッグなしで開始（Ctrl+F5）を試してください。もしそれでも待機するなら、端末側に待機設定が残っている可能性があるため、adb shell am clear-debug-app を試すと改善することがあります。
この問題は .NET MAUI（.NET 9）特有？
根本は Android 側の「デバッガー待機」機構と、adb/エミュレーター/IDEの連携にあるため、.NET MAUI に限りません。ただし MAUI はホットリロードやデバッグデプロイなど周辺要素が多く、環境の揺らぎが表面化しやすい面があります。だからこそ、エミュレーターを“消耗品”として扱い、ツール更新とリセット手順を持っておくのが有効です。
結局どれが一番効く？
経験則としては、次の組み合わせが最も成功率が高いです。
- Cold Boot（スナップショットを捨てる）
- adb 再起動（接続を作り直す）
- それでもダメなら Wipe Data → AVD再作成
「完全に恒久解決する決定打」が単発で存在するというより、エミュレーター/adb の不調を疑って“作り直し＋環境のリセット/更新”で安定化させる方針が最も現実的です。手順をテンプレ化しておくと、次に起きても数分で復旧できます。
コメント