インストーラーを実行しても画面が出ない・進まない — タスクマネージャーの「待機チェーンの分析」で原因プロセスを特定する
症状
業務用ソフトウェア（古いInstallShield系インストーラーを使用する三菱電機製 MELSOFT GX Developer Version8）をWindows 11 Proにインストールしようとした。
SETUP.EXE を実行すると、マウスカーソルの横に読み込み中のリングが2〜3秒だけ表示されて消える。
その後、インストール画面もエラーダイアログも一切表示されず、インストールが先に進まない。
同じ型番の他のWindows 11 Proパソコンでは問題なくインストールできており、この1台だけ症状が出ている。
エラーメッセージが何も出ないため、何が起きているのか推測すらできない、という状態だった。
この記事の結論（先に書きます）
エラーが出ず、画面も出ず、すぐ消えるように見えるインストーラーは、実は裏で起動したまま「別のプロセスの終了を待ち続けている」ことがある。
この「何を待っているか」を突き止める決め手が、タスクマネージャーの「詳細」タブにある「待機チェーンの分析（Analyze wait chain）」 という機能だった。
今回の環境では、インストーラーがオーディオ用の常駐ユーティリティ（CmediaAudioUtility.exe）の終了を待ってデッドロック状態になっていた。
ただし、待っている相手は環境によって変わる。常駐セキュリティソフト、デバイスユーティリティ、別のインストーラーなど、何でもあり得る。
重要なのは特定のプロセス名を覚えることではなく、「待機チェーンの分析で犯人を特定する手順」を身につけることである。
まず試した定石（今回は効果がなかったが、別のケースでは有効）
原因がわからない段階では、インストーラーが進まないときの定番を一通り試した。
以下はいずれも今回の症状には効かなかったが、別の環境では正解になることも多いので、切り分けの手順として記録しておく。
| 試したこと | 結果 | こういうケースには有効 |
|---|---|---|
| イベントビューアーでエラーログ確認 | 関連ログなし | アプリのクラッシュ、MSIエラー |
| 互換モード（Windows 7）+ 管理者実行 | 変化なし | 古いアプリのAPI互換性問題 |
| セキュリティソフト/Defenderの一時無効化 | 変化なし | 誤検知・リアルタイムスキャンの干渉 |
| クリーンブート | 変化なし | 常駐ソフトの干渉（本質に近いが特定には至らず） |
| Windows Installer サービスの開始 | 変化なし | サービス停止が原因のとき |
| TEMPフォルダのクリア | 変化なし | 破損した一時ファイル |
| インストールフォルダを短いパスへ移動 | 変化なし | パスの長さ・全角/括弧の問題 |
| Process Monitor でアクセス追跡 | ログが途中で止まり判断できず | ファイル/レジストリのアクセス拒否 |
ここで重要なのは、「定石を全部試しても直らない＝もっと根本的な別の原因がある」というサインだと気づくことだ。
転機：本当は「クラッシュ」ではなく「動き続けていた」
行き詰まったので、症状そのものを観察し直した。
ここで2つの誤解に気づいた。
誤解1：すぐ消える＝クラッシュ、ではない
タスクマネージャーの「詳細」タブを開いた状態でSETUP.EXEを実行すると、setup.exe が複数（今回は2つ）現れることがわかった。
画面には何も出ないが、プロセス自体は消えずに残っている。
誤解2：エラーが出ない＝失敗していない、ではない
PowerShell で終了まで待って実行し、終了コードを取得した。
$p = Start-Process "<SETUP.EXEのパス>" -PassThru -Wait
Write-Host "Exit Code : $($p.ExitCode)"
Write-Host "Duration : $($p.ExitTime - $p.StartTime)"結果は、終了コード 1（一般的なエラー）／実行時間 約4分20秒だった。
つまりインストーラーは一瞬で死んでいたのではなく、UIを出さないまま数分間動き続け、最後にエラーで終了していた。
「すぐ消えるように見えた」のは、画面に何も描画されないまま裏で待っていたからだった。
「裏で何かを待っている」となれば、何を待っているのかを見ればよい。それを教えてくれるのが次の機能である。
核心：タスクマネージャーの「待機チェーンの分析」
Windowsのタスクマネージャーには、あるプロセスが「別のどのプロセス（やスレッド）の完了を待ってブロックされているか」を表示する機能がある。
これが待機チェーンの分析（Analyze wait chain）だ。応答なし・フリーズの原因プロセスを一発で名指しできる、強力だがあまり知られていない機能である。
手順
- タスクマネージャーを開く（
Ctrl + Shift + Esc） - 「詳細」タブを開く（古い表示では「プロセス」ではなく「詳細」）
- 問題のインストーラーを実行する。
setup.exeなどが一覧に現れる - 該当プロセスを右クリック →「待機チェーンの分析（Analyze wait chain）」
- 表示されるツリーを読む
今回のケースでは、次のように表示された。
setup.exe は別のプロセス (CmediaAudioUtility.exe) を待っています。
setup.exe (PID: 15200) スレッド: 15204
CmediaAudioUtility.exe (PID: 15024) スレッド: 15028これで、インストーラーが CmediaAudioUtility.exe の終了（または応答）を待ったまま止まっていることが確定した。
画面が出ないのは、インストーラーがその先の処理に進めず、UIを描画する段階まで到達できていなかったためだ。
ツリーの読み方
- 一番上が「困っているプロセス」（今回は
setup.exe） - その下にぶら下がるのが「待っている相手」
- 相手がさらに別を待っていれば、芋づる式に下へ伸びる（これが「チェーン＝鎖」の意味）
- チェーンの一番下にいる相手が、たどり着くべき真犯人であることが多い
補足：setup.exe が複数あるときは、待機チェーンが表示される（＝何かを待っている）方を選ぶ。今回も2つ目の setup.exe を分析して相手が判明した。1つ目は短時間で終わる起動用のスタブで、実際にブロックしていたのは後続のプロセスだった。
解決：待っている相手を止める → 切り分け後に環境を戻す
1. 原因プロセスを終了させる
犯人が特定できれば対処は単純だ。待たれている側のプロセスを終了する。
# 例：原因プロセスがオーディオ常駐ユーティリティだった場合
Stop-Process -Name "CmediaAudioUtility" -Force -ErrorAction SilentlyContinueタスクマネージャーから手動で「タスクの終了」をしても同じである。
今回はこの常駐ユーティリティを終了した瞬間、待ち続けていたインストーラーが解放され、インストール画面が表示された。
繰り返すが、ここで止めるプロセス名は環境ごとに異なる。自分の環境で待機チェーンの分析が名指しした相手を止めること。
2. インストール中だけ干渉させない（恒久的に困る場合）
毎回同じ常駐ソフトが邪魔をするなら、インストール作業の間だけ常駐を外す。
- タスクマネージャーの「スタートアップ アプリ」タブで該当ソフトを一時的に無効化 → 再起動 → インストール → 終わったら有効化に戻す
- もしくはクリーンブート（
msconfigで Microsoft以外のサービスとスタートアップを止めて再起動）した状態でインストールする - どうしても常駐が外せない場合は、インストールのたびに手動でそのプロセスを終了する
3. 切り分けのために変えた設定は必ず元に戻す
原因にたどり着くまでに、セキュリティ機能や互換性の設定をいろいろ触ることになる。
これらは今回の原因とは無関係だったので、作業後に必ず元の状態へ戻す。後で別のトラブルの種にしないための後始末である。
- 一時的に無効化したセキュリティソフト／Windows Defender のリアルタイム保護
- 変更した互換モード・DEP（データ実行防止）・UAC などの設定
- 検証用に作成したレジストリキーやクラッシュダンプ設定
- クリーンブート用の
msconfig設定（「通常スタートアップ」に戻す）
戻し忘れを防ぐコツ
どの設定をどう変更したかを、作業中にメモ（テキストファイルや紙）へ書き出しておくと、戻し忘れを防げる。
特にセキュリティ機能（リアルタイム保護、UACなど）を無効のまま放置すると、PCが危険な状態のまま運用されてしまう。
「変更した項目」「変更前の値」「戻したか」の3列でチェックリストにしておくと確実である。
なぜインストーラーが常駐ソフトを「待つ」のか
直接の因果が見えにくいので、起こり得るメカニズムを補足する。
- 共有リソースの取り合い（ミューテックス／ロック）：インストーラーと常駐ソフトが、同じシステム資源・同じDLL・同じレジストリ領域などへのロックを取り合い、相互に解放待ちになる（典型的なデッドロック）
- メッセージ応答待ち：インストーラーが全プロセスへ送る通知（例：設定変更の通知）に、行儀の悪い常駐ソフトが応答を返さず、インストーラーが待たされる
- インストール対象の判定処理：起動時に他プロセスを列挙・問い合わせる過程で、応答しないプロセスにぶつかって止まる
いずれも「インストーラー自身は壊れていない」点が共通している。
だからこそ、エラーも画面も出ず、「他のPCでは普通に入る」という今回のような状況になる。
このテクニックが効く場面（インストーラー以外にも）
「待機チェーンの分析」は、インストーラー専用の機能ではない。
応答なし・フリーズ・終わらない処理の原因切り分け全般に使える。
- 起動しない／反応しないアプリケーション
- 保存・印刷・終了などの操作でフリーズするアプリ
- 「応答なし」と表示されたウィンドウ
- ファイルやフォルダを開こうとすると固まるエクスプローラー
「固まった＝強制終了」と片付ける前に、まず何を待って固まっているのかを見る習慣をつけると、原因にたどり着く速度が大きく変わる。
待機チェーンの分析が使えない・わかりにくいときの代替
タスクマネージャーの表示は簡易的なので、より詳しく見たいときは次が有効。
| ツール | 使い方 | 得意なこと |
|---|---|---|
| リソースモニター（resmon） | resmon 起動 →「CPU」タブ → プロセス右クリック →「待機チェーンの分析」 | タスクマネージャーと同じ機能。CPU使用率と並べて確認できる |
| Process Explorer（Sysinternals） | 対象プロセスのプロパティでスレッド／ハンドルを確認 | どの共有リソース（ロック）で競合しているかまで踏み込める |
| Process Monitor（Sysinternals） | ファイル／レジストリ／プロセス操作を時系列で記録 | アクセス拒否の追跡。ただし出力が膨大で、肝心のイベントが切れて見えることがある |
Process Monitor の「ログが途中で止まる」は、そこでプロセスが終了したとは限らない。フィルタ設定や記録の打ち切りで見えていないだけのこともある。今回もこれで判断を誤りかけた。
舞台裏では、これらはいずれも Windows の Wait Chain Traversal（WCT）という仕組みを使い、スレッドが何の完了を待っているかを OS から取得して表示している。
この件から得られる教訓
- エラーが出ない＝正常、ではない。 終了コードと実行時間を確認すれば「裏で動いて失敗していた」ことがわかる。
-PassThru -Waitで終了コードを取るのは安価で効果が高い - すぐ消える＝クラッシュ、とは限らない。 UIを出さずに待っているだけのこともある
- 定石が全部効かないときは、原因の種類そのものを疑う。 今回は「セキュリティ／互換性の問題」と決めつけて遠回りした
- 「待っている」なら「何を待っているか」を見る。 待機チェーンの分析が最短ルートだった
- 同じ機種・同じOSでも、その1台だけの常駐ソフトの状態で症状が出る。 「他のPCでは入る」は、原因がOSやアプリ本体ではないことを示す重要な手がかり
おまけ：インストールが始まった後の話
待機チェーンの問題を解いてインストーラーが起動した後、製品によっては前提コンポーネントの導入を促されることがある（今回のソフトでは、付属の \EnvMEL\Setup.exe を先に実行するよう案内された）。
これは今回のトラブルとは別の、そのソフト本来の正規インストール手順である。
切り分けで設定を変更した「副作用」と取り違えやすいので、製品付属のインストール手順書を確認して、正しい順序で進めること。
まとめ
インストーラーを実行しても画面が出ず、エラーも出ず、進まない——。
このとき疑うべきは「壊れている」ことよりも「裏で別のプロセスを待っている」ことである。
タスクマネージャーの「詳細」タブでインストーラーを右クリックし、「待機チェーンの分析」を実行すれば、待っている相手を名指しできる。
相手を終了させればインストーラーは解放される。待つ相手は環境によって変わるので、プロセス名ではなくこの調べ方を覚えておきたい。
そして調査のために変更した設定は、原因が判明したら必ず元に戻す。これが安全な後始末になる。