何らかの理由で、アプリケーション プールが数日に 1 回クラッシュし続けます。最大の問題は、このプールに関する管理イベントにエラーや警告に関するログがないことです。(他のプールにはいくつかの警告がありますが、クラッシュし続けるのはこのプールだけです)。私が行った変更は、数日待った場合にのみ機能するかどうかをテストできます。
コードを問題が発生していない段階に戻そうとしましたが、これは役に立たないようです。
ほとんどのクラッシュは、IIS が非アクティブのためにサイトをシャットダウンするほど非アクティブではありませんが、サイトがあまりビジーではないときに発生します。
Windows サーバー 2008 R2 (SP 1)、IIS ビルド 7.5.76、Umbraco、SQL サーバー 2008
IIS ログ: プールの一部のリサイクルのみを表示 (3 時間に 1 回) 迅速な障害検出: 無効
この問題を解決するには、どこから始めればよいですか?
WER (Windows エラー報告) は、無効にされていない限り、クラッシュ ダンプを作成しているはずです。クラッシュ レポートのデフォルトの場所は c:\ProgramData\Microsoft\Windows\WER\ReportQueue\ ですが、私が覚えている限り、クラッシュの Windows イベント ログ エントリには、ダンプ ファイル (アプリケーション イベント ログ）。VSにポップして、何が問題なのかを確認してください。
DebugDiag のインストールを試すこともできますが、個人的には本番サーバーでの使用を強くお勧めしません。これは、他のアプリケーションにも影響を与える不可逆的な方法で、WER 構成を独自の目的で台無しにするためです。
標準的なアプローチは、トレース ログ ファイルの作成を開始することです。アプリケーションのすべての重要なポイントで、詳細なログ メッセージを書き込みます。リクエストの開始時、終了時、途中のどこか、DB 操作の実行時などです。少しの間、余裕を持って。次に、再びクラッシュしたときに、ログファイルをチェックして、クラッシュ前に最後に行っていたことを確認します。詳細が不十分な場合は、ログを追加して繰り返します。
影響を最小限に抑えるために、リスク アプリケーションを別のアプリケーション プールで実行することから始めます。
x 分間に 5 つのエラーが発生した後、アプリケーション プールの再起動を停止する iss プロパティがあります。
この設定を増やしてみると、これがどのくらいの頻度で発生しているか、問題が発生した場合は問題が継続するかどうかがわかります。
それがwcfサービスの場合、トレースログを有効にすることができます（これはかなり多くのログを記録し、おそらくあなたのエラーさえも記録します）。
調べる場所については、スタック オーバーフローとマルチスレッド コードを確認することをお勧めします。
これらはどちらも、イベント ログに情報が含まれない状況を引き起こす可能性があります。