ASP.NETページから呼び出されたDLLで例外が発生した後、IIS7アプリケーションプールがシャットダウンするのはなぜですか？

Question

私は投稿ASP.NET application pool shutdown problemとIIS 7.5: problem with Application poolを読んだが、私の質問に答えなかった。

私はコードビハインドでBINディレクトリ経由で提供されたDLLからクラスをインスタンス化し、このインスタンスのメソッドを呼び出すC＃ASP.NETページがあります。 DLL内部のメソッドはDataRowオブジェクト内に存在しない列のためにSystem.ArgumentExceptionをスローします。

Source: ASP.NET 2.0.50727.0 
Application ID: /LM/W3SVC/1/ROOT/... 
Process ID: 9476 
Exception: System.ArgumentException 
Message: Column 'someColumn' does not belong to table. 
StrackTrace: 

ASP.NETページ内の呼び出し元のコードは、一般的なtry-catchブロック内のメソッド呼び出しをラップ：イベントログに次のエラーが表示されます。ページをリクエストすると、IISインスタンスの対応するアプリケーションプールがクラッシュし、Webサイトが使用できなくなります（エラー503）。私は手動でアプリケーションプールを再起動する必要があり、サイトは再び動作します。今私の質問は、このようなアクセスしようとしたときにスローされSystem.ArgumentExceptionとして、なぜ、比較的「単純な」例外では

try 
{ 
    SomeExternalClass someExternalClass = new SomeExternalClass(); 
    someExternalClass.SomeMethod(someId); 
} 
catch(Exception ex) 
{ 
    // "smp" is an instance of "StatusMessagePanel", a control we use on all pages 
    // to show error information, basically a div container with an icon. 
    smp.ShowError(ex.Message); 
} 

：

更新 としては、背後にASP.NETコードからtry catchブロックを要求しました存在しないDataRow列は、ウェブサイト全体をクラッシュさせますか？また、ASP.NETページの一般的なtry-catchブロックは役に立ちません。これは、Webサイト全体を完全に利用できないようにするものではありませんか、それとも間違った前提ですか？私はこれが基本的に（II）サーバーをダウンさせることができるとは決して考えなかったでしょう。

アクセスする前に列の存在をチェックする必要があると私に伝えてくれることを期待して、これについて知りましたが、レガシーコードが変更されましたが、これは上記のように私の質問ではありませんなぜその結果が非常に激しいのかを知る。

アップデート2

DLL内で呼び出されている問題の方法try-catchブロックに包まれているスレッドを開始：それはかつて私に起こった

[...] 
try 
{ 
    ThreadStart starter =() => CreateReport(...) 
    Thread thread = new Thread(starter); 
    thread.Start(); 
    if(!thread.Join(TimeSpan.FromMinutes(15))) 
    { 
     // Log some timeout warning 
    } 
    else 
    { 
     // Log information about successful report generation 
    } 
} 
catch(Exception ex) 
{ 
    // Log error information 
} 

Answer 1

ほとんどの場合、リンクされた質問に記載されているように、アプリケーションプールはIIS's Rapid Fail Protection機能によって自動的にシャットダウンされています。イベントログを確認すると、処理されていない複数の例外が連続してスローされることがあります。

設定可能な時間間隔（デフォルトは5分で5分）で未処理の例外が十分に処理されると、AppPoolがシャットダウンされ、503 Service Unavailable応答が発生します。

この機能の背後にある理由は、アプリケーションに障害がある場合、後続の要求ごとに自動的に再起動し、リソースを消費し、データを破壊する可能性があるからです。

これは私が期待していた "デフォルト"の動作ではないことを認めなければなりません。

Rick Stahls explanationをご覧ください。もう少し深いです。

これを本当に修正するには、例外をキャッチするか、例外がスローされないようにする必要があります（@leppieが示唆するように）。処理されない例外は、実行中のプロセス全体（IISではなく単一の要求/ワーカープロセス）を破棄することになっています。つまり、エラーを隠すことなく、単にアプリケーションをハングアップさせないためです。これは.NET 2.0で変更されたことを

は

注：
http://msdn.microsoft.com/en-us/library/ms228965.aspx
http://support.microsoft.com/kb/911816

更新
上記のあなたの更新に基づいて、それがスローされた場合、私は、あなたの例外が実際にキャッチされるとは思いませんCreateReport()から。その方法は、別のスレッドで実行されている：

がまだ存在しない場合は、CreateReport()の体内でのtry-catchを必要とする：

public static void CreateReport() { 
    try { 
     throw new Exception("reducto"); 
    } catch { 
     Console.WriteLine("done did."); 
    } 
} 

Answer 2

。実際のエラー（私の場合）はプールをシャットダウンするスタックオーバーフローでした。

IISはあまりにも多くのリソースを消費することから保護していたようです。

私はDebugDiagを使用して問題を発見しました。私が始めたのはここ

は次のとおりです。http://www.webdebug.net/index.php/2012/12/collect-iis-crash-dump-with-debugdiag/

I'd like to understand why an exception in an external DLL can cause the IIS application pool to shutdown, even if the exception is being caught inside the DLL and also when calling the DLL's method from within the code behind of the ASP.NET page.

外部DLLはまた、あなたのアプリケーションプールで実行します。このDLLの重大なクラッシュもアプリケーションプールをクラッシュさせます。いくつかの例外を処理することはできませんし、stackoverflow例外もその一つです。件名はdisc3です。hereたぶんあなたの場合に起こることです。