Cloud Services 仮想マシンでのアプリケーション プールのクラッシュのトラブルシューティング

この記事では、Microsoft Azure Cloud Services の仮想マシン (VM) でのアプリケーション プールのクラッシュを解決する方法について説明します。 アプリケーション プールがクラッシュした場合、アプリケーションは応答を停止します。

手順 1: アプリケーション プールにサービスを提供するプロセスのエラーを確認する

イベント ビューアーでは、コンソール ツリーで Windows Logs>System を選択すると、次のいずれかのイベントが表示されることがあります。

アプリケーション プール '%1' にサービスを提供するプロセスで、Windows プロセス ライセンス認証サービスとの致命的な通信エラーが発生しました。 プロセス ID は '%2' でした。 データ フィールドにはエラー番号が含まれています。

アプリケーション プール '%1' を処理するプロセスが予期せず終了しました。 プロセス ID は '%2' でした。 プロセス終了コードは '%3' でした。

これらのイベントは、アプリケーション プールのクラッシュを明確に示しています。 アプリケーション内で問題が発生したため、アプリケーション プールを終了する必要がありました。 アプリケーション プールが終了すると、対応する w3wp.exe プロセスも終了します。 w3wp.exe プロセス内で保存したキャッシュベースまたはセッションベースの情報はすべて消去されます。

手順 2: 関連するプロセスエラーが原因でアプリケーション プールが自動的に無効にされたかどうかを確認する

理想的には、アプリケーション プールがクラッシュすると、新しい w3wp.exe プロセスが自動的に生成され、受信要求が受け入れられます。 ただし、5 分以内にアプリケーション プールが 5 回以上クラッシュすると、アプリケーション プールは停止状態になります。 アプリケーション プールを起動して実行するには、アプリケーション プールを手動で再起動する必要があります。 同様の状況が発生した場合は、イベント ビューアーのシステム ログで次のイベントが発生します。

アプリケーション プール '%1' は、そのアプリケーション プールにサービスを提供するプロセスで一連の障害が発生したため、自動的に無効になっています。

これらの設定は、そのアプリケーション プールの Advanced Settings ダイアログ ボックスの Rapid-Fail Protection セクションで構成できます。 Enabled プロパティの既定値は True です。 Enabled プロパティが True の場合、特定の時間内にエラー制限に達した後、アプリケーション プールは停止します。 エラー制限は、 Maximum Failures プロパティによって表されます。 このプロパティの既定値は 5 です。 期間は、 Failure Interval (minutes) プロパティで表されます。 また、このプロパティの既定値は 5 です。

手順 3: w3wp.exe プロセス ダンプ ファイルをキャプチャする

アプリケーションがクラッシュしたと判断したら、クラッシュした理由を正確に判断します。 終了する直前に、 w3wp.exe プロセスのダンプ ファイルをキャプチャする必要があります。 このファイルをキャプチャする方法は多数あります。 Windows エラー報告 (WER)、ProcDump DebugDiag を設定して、クラッシュ ダンプ ファイルをキャプチャできます。 この記事では、データをキャプチャする DebugDiag メソッドについて説明します。

DebugDiag をダウンロードしてインストールするには、次の手順に従います。

1. Debug 診断ツール v2 サイトに移動し、ダウンロードを選択します。

2. 必要なダウンロードを選択コンピューター アーキテクチャに適した Microsoft Windows インストーラー (MSI) ファイルのバージョンを選択し、 次へを選択します。

3. ダウンロードした ファイルを開きます。 セットアップ ウィザードで、既定のオプションをそのまま使用し、アプリのインストールを完了します。

DebugDiag 2 Collection アプリケーションを設定するには、次の手順に従います。

1. Startを選択し、「DebugDiag 2 Collection」と入力し、結果の一覧から新しくインストールされたアプリを開きます。

2. [規則の種類の選択] ダイアログ ボックスで、[Crash オプションを選択し、 次へを選択します。

3. [ターゲットの種類の選択] ダイアログ ボックスで、[A 特定の IIS Web アプリケーション プール オプションを選択し、次へを選択。

4. ターゲットの選択 ダイアログ ボックスで、クラッシュしている特定のアプリケーション プールを選択し、次へを選択します。 インターネット インフォメーション サービス (IIS) 管理がインストールされておらず、アプリケーション プールが一覧に表示されないというウィンドウが開いた場合は、OKを選択し、アプリケーション名を手動で入力します。

5. [Advanced 構成 (省略可能)] ダイアログ ボックスで、[ブレークポイント>ブレークポイントの追加を選択。

6. 次の選択を行って新しいブレークポイントを作成し、 OKを選択します。

   フィールド	内容	値
   オフセット式	キャプチャするプロセス	Ntdll!ZwTerminateProcess
   アクションの種類	キャプチャされるダンプの種類	完全なユーザー ダンプ
   アクションの制限	キャプチャするダンプの数	"10"

7. ブレークポイントの構成 ダイアログ ボックスで、新しい Breakpoint 式項目が表示されていることを確認します。 保存して閉じるを選択して Advanced Configuration (省略可能) ダイアログ ボックスに戻り、 Next を選択してブレークポイントをアクティブにします。

8. ダンプの場所と規則の名前の選択 (省略可能) ] ダイアログ ボックスで、Rule Name を入力し、必要に応じて、ユーザーダンプの場所十分な空きディスク領域を持つドライブとディレクトリに変更します。 (各ダンプ ファイルのサイズは、メモリ内の w3wp.exe プロセスによって消費されたものと一致します)。

9. [次へ] を選択します。

10. ルールをアクティブ化するには、 Finish を選択します。

これで、クラッシュ ルールはアクティブな状態になり、 Userdump Count は 0。 問題が発生すると、ダンプ数が直ちに増加し、対応するダンプ ファイルが生成されます。

Note

アプリケーション プールの通常のリサイクルによって、ダンプ ファイルをトリガーすることもできます。 これは、リサイクルすると、アプリケーション プールの対応する w3wp.exe プロセス ID (PID) が変更されるために発生します。 これにより、ダンプ ファイルが生成されます。 このファイルは誤検知です。 そのため、アプリケーション プールのクラッシュを分析するのに役立ちません。 ユーザー ダンプ数の増分が表示されたら、イベント ログを調べて、予期されるクラッシュ イベントが発生したかどうかを確認します。 イベントが想定どおりの場合、キャプチャされたダンプは正しいです。

手順 4: w3wp.exe プロセス ダンプ ファイルを分析する

ダンプ ファイルがキャプチャされたら、 Start>DebugDiag 2 Analysis を開くことができます。 このアプリケーションでは、キャプチャされたクラッシュ ダンプ ファイルを分析できます。

シンボル パスが正しく設定されていることを確認します。 これは 2 部構成のプロセスです。 DebugDiag 2 Analysis で、Settings (歯車アイコン) を選択します。 分析に使用するSymbol検索パスで、_NT_SYMBOL_PATHとMicrosoft パブリック シンボル サーバーが選択されていることを確認します。

DebugDiag 2 コレクションを再度開き、Tools>Options と Settings を選択します。 次に、[ オプションと設定 ] ダイアログ ボックスで、 Symbol Search Path for Debugging (つまりクラッシュ ルール) ボックスが srv*c:\symcache*https://msdl.microsoft.com/download/symbols に設定されていることを確認します。 このパスにより、DebugDiag は Microsoft パブリック シンボル サーバーから必要に応じてシンボルをダウンロードし、 c:\symcache ディレクトリに格納します。

シンボル パスの設定を変更または確認した後、キャプチャしたダンプ ファイルを分析できます。 分析を開始するには、 DebugDiag 2 Analysis に戻り、ダンプ ファイルの名前をダブルクリックします。 レポートが生成されたら、ブラウザーでレポートを開き、ブレークポイント式をトリガーしたスレッドの呼び出し履歴を理解できます。 呼び出し履歴を下から上に読み取り、アプリケーション プールのクラッシュをトリガーしたメソッドまたはコンポーネントを特定します。 正確な例外呼び出し履歴が見つからない場合は、同じダンプ ファイル分析で .NET 呼び出し履歴をさらに確認してください。

手順 5: w3wp.exeまたはWaWorkerHost.exe プロセスで未処理の例外を確認する

また、 w3wp.exe または WaWorkerHost.exe プロセスが停止する原因となった未処理の例外がないか確認するには、「 Unhandled 例外によって ASP が発生する」を参照してください。.NET Framework で予期せず終了する NET ベースのアプリケーション。

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。