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

  • [アーティクル]

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

手順 1: アプリケーション プールを処理するプロセスのエラーを確認する

イベント ビューアーで、コンソール ツリーで [Windows ログ>システム] を選択すると、次のいずれかのイベントが表示される場合があります。

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

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

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

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

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

これらの設定は、そのアプリケーション プールの [詳細設定] ダイアログ ボックスの [ Rapid-Fail Protection ] セクションで構成できます。 Enabled プロパティの既定値は True です。 Enabled プロパティが True の場合、一定時間内にエラー制限に達すると、アプリケーション プールが停止します。 エラーの制限は、[ 最大エラー 数] プロパティで表されます。 このプロパティの既定値は 5 です。 期間は、 エラー間隔 (分) プロパティで表されます。 また、このプロパティの既定値は 5 です。

[アプリケーション プールの詳細設定] ダイアログ ボックスの [保護] セクション Rapid-Fail スクリーンショット。

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

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

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

  1. デバッグ診断ツール v2 サイトに移動し、[ダウンロード] を選択します。

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

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

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

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

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

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

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

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

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

    フィールド 説明 値
    Offset 式 キャプチャするプロセス Ntdll!ZwTerminateProcess
    アクションの種類 キャプチャされるダンプの種類 フル ユーザー ダンプ
    アクションの制限 キャプチャするダンプの数 10

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

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

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

  10. ルールをアクティブにするには、[完了] を選択 します。

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

注:

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

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

ダンプ ファイルがキャプチャされたら、デバッグ診断 2 分析の開始を>開くことができます。 このアプリケーションを使用すると、キャプチャされたクラッシュ ダンプ ファイルを分析できます。

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

DebugDiag 2 コレクションをもう一度開き、[ツール]>[オプションと設定] の順に選択します。 次に、[オプション & 設定] ダイアログ ボックスで、[デバッグ用のシンボル Search パス (つまり、クラッシュ ルール)] ボックスが 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 プロセスが停止する原因となった未処理の例外についてもチェックするには、「未処理の例外が ASP を引き起こす」を参照してください。.NET FRAMEWORKで予期せず終了する NET ベースのアプリケーション。

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

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

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

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