IISのアプリケーションプールが即停止する場合、まず疑うべき原因は大きく4つです。起動直後のクラッシュ、アプリケーションプールIDや権限の不整合、起動監視のタイムアウト、ASP.NET Coreの実行環境や配布内容の不整合です。特に「Rapid-Fail Protectionで止まっている」ケースは多いのですが、これは既定で5分間に5回ワーカープロセスが異常終了したときにプールをサービスから外す保護機能で、根本原因そのものではありません。(Microsoft Learn)
もう1つ重要なのは、「即停止」に見えても、本当にアプリケーションプールが Stopped になっているとは限らないことです。IISのStart Modeは既定でOnDemand、Idle Timeoutは既定で20分なので、未使用時にワーカープロセス（w3wp.exe）だけが終了し、次のアクセスで再起動する挙動は普通に起こります。最初にやるべきことは、プール自体が停止しているのか、初回アクセス時に落ちているのかを切り分けることです。(Microsoft Learn)
IISのアプリケーションプールが即停止するときに、最初に見分けたいこと
現場では、見え方で大まかに絞ると復旧が速くなります。次の整理は、IISのStart Mode、Idle Timeout、Rapid-Fail Protection、ASP.NET Coreの起動方式を踏まえた実務向けの目安です。(Microsoft Learn)
| 見え方 | 可能性が高い原因 | 最初に見る場所 |
|---|---|---|
| IIS Managerで開始してもすぐ停止する | ID不正、資格情報不整合、起動直後クラッシュ | アプリケーションプールのID設定、Event Viewer の System |
Startedにはなるが、初回アクセスで落ちる・503になる | Rapid-Fail Protection、ASP.NET Core起動失敗、web.config不整合 | System の WAS、Application の Application Error / .NET Runtime |
| 放置後に「また止まった」ように見える | Idle Timeout、OnDemand、ウォームアップ不足 | Idle Timeout、Start Mode、サイトの Preload Enabled |
| 更新や再配置の直後から発生した | Hosting Bundle不足、配布漏れ、x86/x64不一致 | Hosting Bundle、配置先フォルダー、web.config、32-bit設定 |
まず確認するログと設定
設定を触る前に、Event Viewerを先に見るのが基本です。SystemログのWASにはワーカープロセスの異常終了が出やすく、ApplicationログのApplication Errorや.NET Runtimeには、w3wp.exeの例外コード、障害モジュール、スタック情報の手掛かりが残ります。ASP.NET Coreの起動エラーはイベントログに出る場合があり、必要ならstdoutログも併用できます。(Microsoft Learn)
| 確認箇所 | 何を見るか | ここで分かること |
|---|---|---|
| System ログ | WASの警告やエラー | ワーカープロセスが落ちたか、IIS側が停止扱いにしたか |
| Application ログ | Application Error、.NET Runtime | 例外コード、障害モジュール、アプリ内例外の有無 |
| アプリケーションプール設定 | Identity、Start Mode、Idle Timeout、Ping Enabled | 設定不整合か、停止の見間違いか |
| 配置先フォルダー | web.config、発行ファイル、ログフォルダー権限 | 配布漏れ、構成ミス、書き込み権限不足 |
この4か所を先に見ておくと、「設定の問題なのか」「アプリが起動時にクラッシュしているのか」「更新の影響なのか」がほぼ絞れます。闇雲にRapid-Fail Protectionを無効化したり、権限を管理者に上げたりする前に、まず証拠を集めるのが近道です。(Microsoft Learn)
原因別に見る、IISのアプリケーションプールが即停止する主なパターン
Rapid-Fail Protectionで停止している
Rapid-Fail Protectionが有効な状態では、既定で5分間に5回ワーカープロセスがクラッシュすると、IISはそのアプリケーションプールをサービスから外し、503を返すようになります。つまり、ここで本当に調べるべきなのは「Rapid-Fail Protectionを切る方法」ではなく、なぜw3wp.exeが連続で落ちているのかです。(Microsoft Learn)
確認は、SystemログのWAS、ApplicationログのApplication Error、.NET Runtimeの順が効率的です。Application Errorではw3wp.exeの障害モジュールや例外コード、.NET Runtimeではアプリ側の例外やスタックトレースが手掛かりになります。原因が見えないときは、Windows Error ReportingやDebugDiagでクラッシュダンプを採取したほうが、設定をいじり続けるより早いです。(Microsoft Learn)
同じプールに複数アプリを載せていると、1つの障害で影響範囲が広がり、切り分けもしにくくなります。少なくとも問題調査中はアプリごとにプールを分けるほうが安全です。ASP.NET Coreのインプロセスホスティングでも、1つのアプリを1つのプールに割り当てる前提で考えるのが無難です。(Microsoft Learn)
アプリケーションプールのIDが不正、または権限が足りない
IIS 7.5以降では、新しいアプリケーションプールは既定でApplicationPoolIdentityを使います。これは仮想アカウントで、ローカルのファイル権限は IIS AppPool\<プール名> の形式で付与できます。物理パスに読み取り権限がない、ログ出力先に書き込み権限がない、といった基本的な権限不足でも、起動直後の失敗や初回アクセス時の停止につながります。(Microsoft Learn)
ローカルフォルダーのACLを付け直すときは、たとえば次のように設定します。
icacls C:\sites\MyWebApp /grant "IIS AppPool\MyPool:(OI)(CI)RX"アプリがログや一時ファイルを書き込むなら、対象フォルダーには書き込み権限も必要です。権限を付ける相手をUsersやEveryoneに広げるのではなく、そのプールだけに付けるのが基本です。(Microsoft Learn)
IdentityをSpecificUserにしている場合は、ユーザー名・パスワード・アカウント状態を真っ先に見直します。IISのプロセスモデルではSpecificUserに資格情報を持たせ、既定のログオン種別はBatchです。パスワード変更後の入れ直し漏れや、ドメインポリシー変更後のログオン関連権限の問題は、即停止の定番です。(Microsoft Learn)
見落としやすいのがネットワーク共有です。ApplicationPoolIdentityは、リモートリソースに対してはアプリケーションプール名ではなくサーバーのコンピューターアカウントでアクセスします。たとえばWEB01上のIISからファイルサーバーへアクセスするなら、共有先で DOMAIN\WEB01$ を許可する必要があることがあります。UNCパスや統合認証を使う接続先がある場合は、ここを必ず確認してください。(Microsoft Learn)
もう1つの落とし穴がLoad User Profileです。IISは既定ではWindowsのユーザープロファイルを読み込まないため、ユーザープロファイル配下のパスや一部コンポーネントを前提にした処理は、起動時に失敗することがあります。アプリがその前提を持つなら、Load User Profileの見直しも候補に入ります。(Microsoft Learn)
起動時間やヘルスチェックの設定で落ちている
IISのプロセスモデルでは、startupTimeLimitは既定で90秒、Ping Enabledは既定で有効、Ping Intervalは30秒、Ping Maximum Response Timeは90秒です。初回起動に時間がかかるアプリでは、この監視に引っかかって「開始したのにすぐ落ちる」ように見えることがあります。(Microsoft Learn)
このパターンで効くのは、単純なタイムアウト延長よりもウォームアップの設計です。Application Initializationを使い、アプリケーションプールのStart ModeをAlwaysRunning、サイトのPreload EnabledをTrueにすると、起動時やリサイクル時に事前リクエストを流して初期化を前倒しできます。起動が重いアプリでは、こちらのほうが安定しやすいです。(Microsoft Learn)
反対に、「アクセスがないと止まる」だけなら、原因はクラッシュではなくIdle Timeoutかもしれません。既定値は20分なので、常時ウォームな状態を求めるアプリではIdle Timeoutを0にして挙動を見直す価値があります。“止まっている”のか、“アイドルで落としている”のかは、ここで明確に分けてください。(Microsoft Learn)
デバッグ中だけ落ちる場合は、ヘルスチェックが邪魔をしていることもあります。その場合は一時的にPing Enabledを無効化するか、Ping Maximum Response Timeを延ばして切り分けます。ただし、これは恒久対策ではなく、原因の見極め用として使うのが安全です。(Microsoft Learn)
更新・配布・ASP.NET Coreの実行環境不整合で起きている
ASP.NET CoreアプリをIISで動かす場合、IISとの橋渡しをするASP.NET Core Moduleは.NET Hosting Bundleで導入されます。Hosting Bundleが未導入、またはIISより先にBundleを入れていてモジュール登録が不完全な場合、起動に失敗することがあります。IIS導入後にBundleを修復し、IISを再起動すると改善するケースがあります。(Microsoft Learn)
IISの再起動は、次の手順でWASごと再起動すると確実です。
net stop was /y
net start w3svcこの手順は、IIS関連サービスを含めて再起動するときの方法として案内されています。(Microsoft Learn)
更新直後に止まるなら、まず配布先の中身を疑います。web.configがない、壊れている、発行物の一部が配置されていない、IISの物理パスと実際の配置先がずれている、といった配布ミスは非常に多い原因です。特に自動デプロイの失敗後は、「更新は成功したように見えるのに起動しない」状態になりやすいです。(Microsoft Learn)
x86 / x64 の不一致も見逃せません。32ビットで発行したアプリは、アプリケーションプール側で32ビットアプリの有効化が必要になることがあります。逆にアーキテクチャが合っていないと、ワーカープロセスが起動できず、そのままアプリが立ち上がらないことがあります。(Microsoft Learn)
ASP.NET Coreの起動トラブルでは、stdoutログが有効です。起動時エラーの詳細をファイルに出せるので、イベントログだけでは足りないときの補助になります。ただし、ログ出力先フォルダーにアプリケーションプールIDの書き込み権限がないと、それ自体が新たな失敗要因になります。まずはログフォルダーのACLを確認してください。(Microsoft Learn)
すぐ復旧したいときの実務的な手順
急ぎの復旧では、次の順番で進めると遠回りしにくくなります。(Microsoft Learn)
- 本当に
Stoppedなのかを確認する
IIS Managerでプール状態を見て、開始直後に止まるのか、初回アクセス時だけ落ちるのか、しばらく未使用後に消えるだけなのかを切り分けます。OnDemandとIdle Timeoutの挙動を先に除外すると、不要な調査を減らせます。(Microsoft Learn) - Event Viewerを
System→Applicationの順で見るWAS、Application Error、.NET Runtimeを確認し、w3wp.exeのクラッシュか、アプリ内例外か、IIS側の監視停止かを把握します。ここで原因の手掛かりが出ることが多いです。(Microsoft Learn) - IDと権限を最優先で見直す
ApplicationPoolIdentityなら物理パスやログ出力先のACL、SpecificUserなら資格情報とアカウント状態を確認します。UNCパスや共有フォルダーを使っているなら、共有先でコンピューターアカウント側の権限も見ます。(Microsoft Learn) - 起動が重いアプリはタイムアウトとウォームアップを調整する
startupTimeLimitやPingの設定を見直し、必要ならAlwaysRunningとPreload Enabled、Application Initializationで初期化を前倒しします。常時起動が必要ならIdle Timeoutも確認します。(Microsoft Learn) - ASP.NET CoreならHosting Bundle・
web.config・アーキテクチャを確認する
Hosting Bundleの有無、IIS導入順の問題、配布先のファイル不足、x86/x64の不一致をまとめて確認します。必要ならBundle修復後にWASごと再起動します。(Microsoft Learn) - 繰り返すならダンプを取る
ログだけで原因が分からない停止は、WERまたはDebugDiagでクラッシュダンプを取得し、落としているモジュールや例外を特定します。ここまで進めば、再発防止までつながりやすくなります。(Microsoft Learn)
やってはいけない対処
Rapid-Fail Protectionだけを無効化して終わるのは避けたい対処です。連続クラッシュからサーバーを守る機能を外しているだけで、アプリが落ちる原因は残ります。まずはWASやApplication Errorで根本原因を追うべきです。(Microsoft Learn)
管理者権限や広すぎるACLで無理やり通すのも危険です。権限の問題は、IIS AppPool\<プール名>や必要なサービスアカウントに対して、必要最小限で付けるほうが再発防止にもつながります。(Microsoft Learn)
Idle TimeoutやOnDemandの挙動を“即停止”と誤認するのもよくある失敗です。実際には正常動作なのに、監視だけが増えて本当の問題を見失うことがあります。まずはStoppedなのか、w3wp.exeがアイドルで落ちただけなのかを分けて考えてください。(Microsoft Learn)
複数アプリを1つのプールにまとめたまま調査するのも非効率です。影響範囲が広がり、どのアプリが落としているのか分かりにくくなります。問題調査中は、少なくとも対象アプリを独立したプールに切り出したほうが追いやすくなります。(Microsoft Learn)
迷ったら、まずこの順番で確認する
最短ルートは、Event ViewerでWASとApplication Errorを見る → アプリケーションプールIDとACLを確認する → startupTimeLimit / Ping / Idle Timeoutを見直す → ASP.NET CoreならHosting Bundle・web.config・配布先・32bit設定を確認する、の順です。ここまでで原因が見えなければ、設定変更を増やすよりダンプ取得に進んだほうが早いです。再発する停止ほど、勘で触るより「どの瞬間に何が落ちたか」を証拠で押さえることが復旧の近道になります。(Microsoft Learn)
コメント