診断方法IIS致命的な通信エラーの問題
IISと、Asp.NET 1.1で私たちが開発したアプリケーションを使用している顧客がいます。月曜日に4回続けて、「アプリケーションプール 'xxxx'を提供するプロセスが発生しました」というエラーが発生しました。 World Wide Web PublishingServiceとの致命的な通信エラー。プロセスIDは「yyyy」でした。データフィールドにエラー番号が含まれています。」と表示されました。
これを診断する方法について何か考えはありますか？ 私が見つけたリンクのみ 低レベルのデバッグツールのインストールについて話しますが、この種の低レベルの分析に進む前に、誰かがより良いアイデアや適切な代替案を持っているかどうかを知っています。
問題は（私が見ることができるものから）顧客環境にあるものです。同じアプリケーションが少なくとも20または30の異なるサーバー上の他の顧客サイトにインストールされており、問題は発生しないためです。
よろしく
マッシモ
IIS 7で同じ問題が発生しましたが、非常に長い1つのレポートを除いて、すべてが機能するレポートはほとんどなく、IIS7では機能しませんでした（低スペックサーバーでは問題ありませんでした）。
iIS7のアプリケーションプールの事前設定I 「32ビットアプリケーションを有効にする」をtrueに設定そしてすべてがうまく機能しました
同じエラーが発生します。詳細は次のとおりです。
実行中：Windows Server 2003、IIS 6.0/ASP 3.0、2.13 GHz、1 GB RAM
私のウェブサイトはベータ版なので、サイトへの訪問者はほとんどいません。
イベントビューアによると、この警告は3分ごとに3回表示され、その後数時間停止します。
次に、エラーが発生することがあります。
アプリケーションプール 'DefaultAppPool'を提供するプロセスが予期せず終了しました。プロセスIDは '3900'でした。プロセス終了コードは '0x800703e9'でした。
続いて：
アプリケーションプール 'DefaultAppPool'は、そのアプリケーションプールにサービスを提供するプロセスで一連の障害が発生したため、自動的に無効になっています。
これにより、Webサイトを参照するときに「ServiceUnavailable」メッセージが表示されます。
この問題に関する投稿を読みすぎた後、次の手順を実行しました。
レジストリアクセス権の可能性があることを読んだので、モニターをインストールし、すべてのW3SVCアクセス拒否エラーを追跡して許可を付与しました
0x800703e9エラーは、w3wp.exeクラッシュを引き起こすスタックオーバーフローを意味することを読みました。デバッグツールをインストールして、メモリダンプを取得する必要があります。私はそれをしましたが、ダンプを取得できなかったので、新しいデバッグツールをインストールしましたが、まだクラッシュしていません。
私のWebサイトは、サーバーをビジー状態に保つデータマイニングを行っています。
結論：
そこで何が起こっているのかわかりません...しかし、私のサーバーマシンがリソースを遅くする方法であることは知っているので、アップグレードして再インストールします。問題が解決すると確信しています。 ..
この問題は、.netコードがアイドル状態の場合でも常に発生するため、サーバーの問題であり、コードの問題ではありません。
最初の警告「アプリケーションプールにサービスを提供するプロセス...」は時々発生し、時々アプリケーションプールが再起動するため、デバッガーを接続しても役に立ちません。 -プロセスが再起動し続け、デバッガーが無効になります...アプリプールの再起動時に0x800703e9エラー（サービスが利用できなくなる）が発生する可能性があると思います。多くのリソースが必要であり、私のマシンなので遅すぎると0x800703e9になります...前に述べたように、これはスタックオーバーフローですが、これはリソースの不足が原因であり、無限の再帰が原因ではないと思います。
Microsoftが問題であると主張している「レジストリアクセス権」はナンセンスだと思いますが、それが役立つかもしれないので、「ServiceUnavailable」を取得しませんでした（私はまだ警告を受け取ります「Aプロセスサービングアプリケーションプール... "）。
これが誰かを助けることを願っています...
WebサイトがクライアントのWebサーバーに展開されたときに、これと同じ問題が発生しました。 このMicrosoftサポート記事 言います：
「この問題は、NT AUTHORITY\NETWORKSERVICEアカウントに必要なレジストリキーへのアクセス許可がない場合に発生する可能性があります。」
そして、解決策は次のとおりです。「必要なレジストリキーにアクセス許可を設定してから、IIS 6.0」を再起動します。」
リンクされた記事には、これを行うための手順があります。
あなたはすでにこれを知っていると確信していますが、アプリプールには1.1アプリケーションしか含まれていませんよね？フレームワーク（サーバーが利用できないなど）を混在させようとしてプールが停止したときに発生するエラーは覚えていませんが、実際に考えていたよりも一般的であるため、再確認します。
可能性は低いですが、それはどこかで始まります。
編集： This KBの記事には、レジストリのアクセス許可に関連して説明したエラーメッセージもありました。クライアントはどのバージョンのIISを実行していますか？
もう1つの一般的な理由（私の場合のように）-Windowsログの1つがいっぱいです。