web-dev-qa-db-ja.com

アプリケーションプール 'X'にサービスを提供するプロセスで、Windowsプロセスアクティブ化サービスとの致命的な通信エラーが発生しました

IIS 7.5。の下でASP.NET 4.0アプリケーションを実行しています。1日に数回、アプリケーションプールが予期せずリサイクルされています。これが発生すると、システムログに次のイベントが表示されます。

アプリケーションプール 'X'にサービスを提供しているプロセスで、Windowsプロセスアクティブ化サービスとの致命的な通信エラーが発生しました。プロセスIDは「5768」でした。データフィールドにはエラー番号が含まれます。

OR

アプリケーションプール 'X'にサービスを提供するプロセスが、pingに応答できませんでした。プロセスIDは '1032'でした。

ほとんどの場合、アプリケーションログには、次のような対応するイベントがまったく同時に存在します。

Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b
Faulting module name: clr.dll, version: 4.0.30319.269, time stamp: 0x4ee9ae83
Exception code: 0xc00000fd
Fault offset: 0x00001916
Faulting process id: 0x508
Faulting application start time: 0x01cd4d8958ecf9ad
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 8dcc413b-b98a-11e1-8075-001c23d6d910

したがって、私は IIS Debugging Tools をインストールしてクラッシュルールを設定し、「特定のIIS Webアプリケーションプール」、ファーストチャンスの例外のロギングなし、および「詳細設定」(例外、ブレークポイント、イベント)。

また、次のコマンドラインを使用して、WindowsデバッグツールからADPlusを(同時に)実行しています。

adplus -crash -pn w3wp.exe -NoDumpOnFirst -o c:\logs

ただし、デバッガーを接続しているため、システムログにいくつかの「警告」レベルのメッセージが表示されます(「プロセスサービスアプリケーションプール 'X'に関するメッセージで致命的な通信エラーが発生しました...」)。アプリケーションログで対応するエラーレベルのイベントを取得していません。

私が得ることができた唯一のものは以下です(これらのうち約50個がありました):

[6/18/2012 7:50:25 PM] Thread exited. Exiting thread system id - System ID: 3300. Exit code - 0x800703e9
[6/18/2012 7:50:25 PM] Thread exited. Exiting thread system id - System ID: 4992. Exit code - 0x800703e9
[6/18/2012 7:50:25 PM] Thread exited. Exiting thread system id - System ID: 5456. Exit code - 0x800703e9
[6/18/2012 7:50:25 PM] Thread exited. Exiting thread system id - System ID: 4924. Exit code - 0x800703e9

終了コード0x800703e9は、スタックオーバーフローがどこかにあることを示します。これは、見つかったら簡単に修正できるので幸いです。

ただし、そのためには、WinDbgでクラッシュダンプを開いて "!clrstack"コマンドを使用して問題を特定できるように、クラッシュダンプの詳細情報が必要です。

私の質問は次のとおりです。デバッグツールが正しく構成されていますか、それともイベントログを誤解していますか? 「Windowsプロセスアクティブ化サービスでの致命的な通信エラー」に関するイベントがシステムログに表示されるたびに、アプリプールがリサイクルされているようですが、IISからクラッシュダンプ情報を取得していませんこれらのイベントが発生したときのデバッグツールまたはADPlus。また、何らかの理由で、デバッガーを接続したため、システムログ警告イベントに対応するアプリケーションログに「エラー」イベントが表示されなくなりました。理由は不明です。どういうわけか、CLR情報を含む完全なクラッシュダンプを取得して、問題の場所を特定する必要があります。

もう1つ言えるのは、Windowsエラー報告サービスが実行されていないことです。それが必要かどうかわからない。

助けてくれてありがとう。

19
Scott

アプリケーションログで取得していた例外コードとスレッド終了コードの両方が、スタックオーバーフローがあることを示しています。スレッドがスタックオーバーフローエラーで終了したときにプロセスがクラッシュしないのはなぜでしょうか。とにかく、スタックオーバーフロー例外でのブレークを有効にするには、コマンドは次のとおりです。

sxe sov

アプリケーションプールは32ビットプロセスとして構成されているため、x86バージョンのデバッガーを使用する必要があることに注意してください。

4
seva titov