Windows 11 自作PCをアイドル放置すると OS は生きているのにアプリが操作不能 ― イベント ビューアには毎回「svchost.exe のハング」。再起動も異常に長い。この厄介な“ソフトロック”を、サービス単位の切り分けとダンプ採取で原因を特定し、USB オーディオ（MOTU M2）再インストールとポート変更で解決した実例と手順を公開します。
症状の全体像と再現条件
一定時間（数十分～数時間）放置すると、デスクトップやマウス操作は応答するのにアプリの新規起動や既存ウィンドウの操作が効かなくなる「ソフトロック」状態に陥ることがあります。イベント ビューアの アプリケーション ログには毎回、Application Hang（イベント ID 1002） として「svchost.exe（バージョン 10.0.26100.4343…）が応答を停止しました」と記録。続いて WinSrvExt の遅延、最終的に BugCheck（強制再起動を伴う場合あり）まで連鎖するパターンが見られます。
このケースの本質は「svchost.exe がホストするサービスのどれかが止まっている」ことです。svchost.exe 自体は“容器”であり、容器の中身（サービス）を特定できなければ前進しません。本記事は、一般論に終始せず、実際に USB オーディオインターフェース（MOTU M2）ドライバ／ポートの相性へと到達・解消した手順を、再現可能な形でまとめました。
起点となる観察ポイント
- エラーの周期性：信頼性モニターで AppHangXProcB1 が約 15 分間隔で 2 回連続 → 直後にソフトロックに移行。
- 再起動の遅さ：ログオフや再起動指示後に 5～10 分以上待たされる（バックグラウンドのサービス停止待ち）。
- DISM / SFC / BIOS 更新済みでも再発：OS 整合性やファーム更新だけでは解けない、ドライバ／周辺機器起因の疑いが濃い。
結論（先に知りたい人向け）
段階的な切り分けの結果、svchost.exe（Windows Audio サービス）→ audiodg.exe（Audio Device Graph Isolation）の鎖でハングが伝播していたことが判明。MOTU M2 の旧インストール／特定 USB ポートとの相性がトリガーで、ドライバの完全再インストール＋背面 I/O（チップセット直結）の別ポートへ接続することで解消しました。
全体ロードマップ（先に全貌を把握する）
| 手順 | 目的・実施内容 | 補足 / ポイント |
|---|---|---|
| 1. 問題サービスの特定 | タスク マネージャで svchost.exe の PID を確認し、tasklist /svc や Process Explorer で「どのサービスをホストしているか」を紐づける。 | イベント ログの PID は 16 進。10 進へ変換して突き合わせる。 |
| 2. 信頼性モニター／イベント ビューア | 時系列で Application Hang と AppHangXProcB1 の出現順・間隔を確認。 | 15 分間隔で 2 回 → ソフトロックという周期性有無を観察。 |
| 3. クリーン ブート | Microsoft 以外のサービスとスタートアップを停止し再現性を確認。 | 再現すれば OS/ハード寄り、収まればドライバ/常駐が濃厚。 |
| 4. システム整合性チェック | sfc → DISM → chkdsk の順で破損とディスク異常を排除。 | 根本原因が別でも、診断のノイズを減らせる。 |
| 5. クラッシュ ダンプ採取 | WER の LocalDumps で svchost.exe のフルダンプ、CrashOnCtrlScroll で手動クラッシュを取得。 | ソフトロックは自動ダンプが落ちにくい。手動取得で確実に証跡を残す。 |
| 6. ドライバと直近更新の見直し | デバイス マネージャで警告、GPU/チップセット/オーディオを更新。Windows Update 影響も考慮。 | svchost.exe_Audiosrv → audiodg.exe がハング源のサイン。 |
| 7. USB オーディオの切り分け | MOTU M2 を物理的に外す → 24 時間監視で再発有無を判定。最新版で再インストールし、別ポートへ。 | 旧インストール破損・ハブ経由・特定ポート相性のいずれかが典型因子。 |
| 8. 長期動作テスト | 48 時間以上のアイドル運転で安定性を確認。 | 信頼性モニターの「赤×」が止まれば収束。 |
svchost.exe は“容器”。まず中身（サービス）を突き止める
svchost.exe は多数のサービスをまとめてホストするプロセスです。エラーに書かれた「svchost.exe が応答を停止」はゴールではなくスタート。どのサービスの svchost が落ちたのかを、PID を手がかりに特定します。
PID 突き合わせ手順
- イベント ビューア（Windows ログ → アプリケーション → Application Hang 1002）の詳細に表示される PID（16 進） を控える。
- PowerShell で 10 進へ変換する。
'0x00001A2C' -as [int] # または [Convert]::ToInt32('1A2C',16) - 該当タイミングで動いていた svchost を列挙する。
tasklist /svc /fi "imagename eq svchost.exe"PID とサービス名の対応を確認し、疑わしいグループ（例：Audiosrv、AudioEndpointBuilder）をメモ。
Process Explorer があれば、svchost のプロパティ → Services タブでも即座に確認できます。
信頼性モニターで「周期性」を掴む
信頼性モニター（perfmon /rel）は、イベントを時系列に俯瞰するのに最適です。このケースでは AppHangXProcB1 が約 15 分ごとに 2 回現れ、直後に UI 応答だけ残してソフトロックへ移行するパターンが見られました。周期性はサービスの内部タイマーやスリープ復帰、USB 省電力などの定期処理が関与しているサインです。
クリーン ブートでサードパーティ干渉を除外
msconfigを起動 → サービス タブで「Microsoft のサービスを隠す」にチェック → 残りをすべて無効化。- タスク マネージャ → スタートアップ タブで無効化。
- 再起動後、同条件で放置し再現有無を確認。
ここで症状が消えるなら、常駐アプリやドライバが原因階層にいると判断できます。消えないならハード／OS コアへ寄っていきます。
OS 整合性の標準三点セット
診断のノイズを除去するため、以下をこの順番で実行します。
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
chkdsk C: /f /r
chkdsk は再起動後に実行されるため、所要時間を見積もって実施してください。記憶域に物理エラーがあると、ハング検出が遅延し二次災害（再起動の長時間化）を招きます。
ソフトロックでも証跡を残す：ダンプ採取の実践
アプリが固まっても自動的にダンプが落ちないことは珍しくありません。手動で svchost.exe のフルダンプと、システム手動クラッシュ（完全メモリダンプ）を仕込んでおきます。
WER LocalDumps（svchost.exe 用）
mkdir C:\CrashDumps
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\svchost.exe" /v DumpType /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\svchost.exe" /v DumpFolder /t REG_EXPAND_SZ /d C:\CrashDumps /f
DumpType=2 はフル。ハング直後にタスク マネージャの該当 svchost.exe を右クリック → ダンプ ファイルの作成でも取得できます。
CrashOnCtrlScroll（完全メモリダンプ）
USB/PS2 キーボードから Ctrl + Scroll Lock ×2 で手動クラッシュ（BugCheck 0xE2）を発生させ、C:\Windows\MEMORY.DMP を生成します。レジストリ準備は次の通り。
reg add "HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters" /v CrashOnCtrlScroll /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters" /v CrashOnCtrlScroll /t REG_DWORD /d 1 /f
システムのプロパティ → 詳細設定 → 起動と回復で「デバッグ情報の書き込み」を 完全メモリ ダンプ（または自動/カーネルでも可）に設定。注意：レジストリ編集は自己責任で。事前に復元ポイントを作成してください。
イベント ログをコマンドで素早く読む
wevtutil qe Application /q:"*[System[Provider[@Name='Application Hang'] and (EventID=1002)]]" /f:text /c:5
直近 5 件の Application Hang をテキストで確認できます。svchost.exe_Audiosrv と紐づく audiodg.exe（Audio Device Graph Isolation）の関与が読み取れるなら、オーディオ ドライバ層を優先的に疑います。
ドライバ／更新の見直し：オーディオと USB を最優先
- デバイス マネージャ：「サウンド、ビデオ、およびゲーム コントローラー」「ユニバーサル シリアル バス コントローラー」配下の警告アイコン有無を確認。
- チップセット/GPU/オーディオ：最新版へ更新。特にオーディオは ベンダー提供の専用ドライバを適用（汎用 USB Audio Class では機能/電源管理が最適化されないことがある）。
- Windows Update：直近の品質更新を適用/ロールバック双方で再現性を確認。更新後に再発するなら、ドライバ再インストールで整合を取り直す。
USB オーディオ（MOTU M2）での実際の解決手順
本件では、MOTU M2 を外すと 24 時間放置でも再発しないことを確認。以下で恒久対応へ進みました。
手順 A：完全アンインストール
- 「アプリと機能」から MOTU 関連エントリをアンインストール → 再起動。
- デバイス マネージャで MOTU M2 を「デバイスのアンインストール（ドライバー ソフトウェアを削除）」。
- PowerShell（管理者）で残骸 INF を整理（例）：
pnputil /enum-drivers | Select-String -Pattern "MOTU|audio|usbaudio" # 見つかった oemXX.inf をアンインストール（例） pnputil /delete-driver oem42.inf /uninstall /force
手順 B：最新版の再インストール
- PC をシャットダウンし、USB ケーブルを外した状態で起動。
- ベンダーの最新インストーラを実行（Windows 11 / WHQL 版）。
- 案内に従い、背面 I/O の USB-A 3.x（チップセット直結）へ接続。前面ポート、USB ハブ、モニター経由、バスパワー不足のハブは避ける。
- デバイス マネージャ → USB ルート ハブ（USB 3.0/3.1/3.2） → 電源の管理で「電力節約のためにコンピューターでこのデバイスの電源をオフにできるようにする」のチェックを外す（必要に応じて）。
- 電源オプション → 詳細設定 → USB 設定 → USB のセレクティブ サスペンド設定を「無効」にして挙動を比較（省電力は下がるが安定度が上がることがある）。
- サウンド設定 → デバイスのプロパティ → 排他モードのチェック（アプリに独占を許可）を用途に合わせて調整。DAW 主体の場合は ASIO ドライバ使用を前提に。
手順 C：監視と確認
- 信頼性モニターで 48 時間、赤×が出ないか確認。
- イベント ビューアの アプリケーション ログで Application Hang が途絶えていることを確認。
- 念のため、
audiodg.exeの CPU 使用率の暴走やクラッシュがないかタスク マネージャで観察。
以上で本環境は安定化し、ソフトロックは再発していません。
なぜオーディオが「svchost のハング」に見えるのか
Windows Audio（Audiosrv）は svchost.exe 配下のサービスとして動作し、実際のミキシングや DSP は audiodg.exe（ユーザーモードの Audio Device Graph Isolation）に委任します。ベンダー ドライバは プロパティ ハンドラーや APO（Audio Processing Object） として audiodg.exe にプラグインされ、ここでの応答停止やハングは svchost 側のサービス停止待ち（ハング）として波及しがちです。USB の省電力やハブ経由でのバスパワー不足も相まって、一定間隔での復帰処理や再初期化が失敗 → 15 分周期の AppHang という形で見えることがあります。
診断を加速する実用スニペット集
サービス & プロセスの突き合わせ
Get-CimInstance Win32_Service | Where-Object { $_.ProcessId -gt 0 } |
Select-Object Name, DisplayName, ProcessId |
Sort-Object ProcessId
最近のハングを素早く確認
wevtutil qe Application /q:"*[System[(EventID=1002)]] and *[EventData[Data='svchost.exe']]" /f:text /c:10
監視用ハートビート（ロック検出の補助）
while ($true) { Add-Content C:\Temp\heartbeat.log (Get-Date); Start-Sleep 60 }
ログの更新が止まった時刻とイベントの時刻を突き合わせると、ロック発生の境界が明瞭になります。
再発防止のコツ（オーディオ機器を使う PC 向け）
- USB ポートの選定：背面 I/O のチップセット直結ポートを第一候補に。Type-C ハブやディスプレイのハブは避ける。
- ケーブル品質：低品質・長尺ケーブルは信号品質と給電を同時に悪化させる。付属ケーブルや信頼できる短尺ケーブルを使用。
- ドライバ署名＆自動更新の制御：ベンダーが Windows 11 用 WHQL を提供していない場合、デバイス マネージャで「ドライバーの自動更新を許可しない」を選び、安定版で固定する。
- 復元ポイントの常用：大型アップデートやドライバ更新前に手動作成。戻せる選択肢を常に確保。
- ログの衛生管理：Application/System ログを定期クリアし、異常の初出タイミングを把握しやすくする。
- 電源設定の見直し：高パフォーマンス系プランをベースに、USB セレクティブ サスペンドや PCI Express の省電力を状況に応じて調整。
トラブルが続く場合の追加打ち手
- BIOS 設定：XHCI ハンドオフ、ErP、USB パワーシェア等の設定で給電が変わることがある。初期値に戻して比較。
- 別 OS での再現確認：ポータブル Windows や別 SSD を用意し、最小構成ドライバ＋オーディオのみで再現するか確認（ハード/ソフト切り分け）。
- ストレージ/メモリ健全性：NVMe の S.M.A.R.T.、メモリテストなど物理層の検査を平行して実施。
- 別 PC/ポート検証：同機器を他 PC に接続して安定なら PC 側。逆なら機器側の不調が疑われる。
ケーススタディの要約（MOTU M2）
| 観測 | 解釈 | 対処 | 結果 |
|---|---|---|---|
| svchost.exe の Application Hang（1002）が周期的に発生、再起動が長い | svchost 配下サービス（Audiosrv）/ audiodg.exe が停止待ち | LocalDumps と CrashOnCtrlScroll を準備。PID から Audiosrv を特定 | 原因階層がオーディオに収束 |
| MOTU M2 を外すと 24 時間再発せず | 外部要因（USB オーディオ）依存 | 完全アンインストール → 最新版で再インストール | 再発が一時的に止まる |
| 前面ポートで稀に波形乱れ/ハング | 前面配線/ハブ経由の相性 | 背面 I/O の USB-A（チップセット直結）に変更 | 48 時間以上安定、収束 |
よくある質問（FAQ）
Q. svchost.exe を止めてもいい？
いいえ。svchost.exe は多数の基本サービスをホストしています。犯人探しは「svchost を止める」ではなく「どのサービスの svchost か」を PID で特定します。
Q. audiodg.exe が高負荷になる／落ちる。
ベンダー APO の不整合、排他モード、サンプルレート不一致、USB 省電力、古い ASIO/カーネルミキサーの干渉が典型要因。最新ドライバ、排他/共有の見直し、USB ポート変更で改善が見込めます。
Q. 再起動に時間がかかるのはなぜ？
停止できないサービスを OS が長時間待機しているため。イベント ログの サービス制御マネージャと併せ、どのサービス停止で長時間化しているか追跡します。
チェックリスト（貼っておける簡易版）
- イベント 1002（Application Hang）の PID を控え、10 進変換 →
tasklist /svcでサービス名を特定。 - 信頼性モニターで発生周期を確認（15 分 × 2 → ロックのようなパターン）。
- クリーン ブートで再現性を確認（ドライバ/常駐か OS/ハードか）。
- SFC → DISM → chkdsk を完走させる。
- LocalDumps（svchost.exe）と CrashOnCtrlScroll を準備し、証跡を残す。
- オーディオと USB を最優先で見直す：ドライバ再インストール、背面 I/O 直結ポートに変更、USB 省電力の影響を排除。
- 48 時間の安定監視で収束を確認。
まとめ
「svchost.exe のハング」は最終的な症状であり、真犯人はその配下のサービスです。今回の事例では、Windows Audio（Audiosrv）→ audiodg.exe → USB オーディオ ドライバの経路でハングが連鎖し、MOTU M2 の旧インストール/特定ポート相性が根因でした。サービス単位の特定→ダンプ採取→周辺機器の切り離しという 3 本柱を押さえると、同種のトラブルでも高確度で原因に到達できます。再発防止としては、USB ポート選定、ドライバ署名と自動更新の制御、復元ポイント作成、ログ衛生管理の 4 点をルーチン化すると効果的です。
コメント