w3wp.exeがランダムにクラッシュする理由をデバッグする方法
メインの運用サーバーでIISワーカープロセスがクラッシュすることがあります。イベントビューアーから次の情報を取得します。
障害が発生しているアプリケーション名：w3wp.exe、バージョン：7.5.7601.17514、タイムスタンプ：0x4ce7a5f8障害が発生しているモジュール名：KERNELBASE.dll、バージョン：6.1.7601.17651、タイムスタンプ：0x4e211319例外コード：0xe053534f障害オフセット：0x0000b9bc障害が発生しているプロセスID：0x％ 9障害のあるアプリケーションの開始時刻：0x％10障害のあるアプリケーションのパス：％11障害のあるモジュールのパス：％12レポートID：％13
これは本番サーバーでランダムに発生し、このクラッシュを他の場所で再現することはできませんでした。これはIIS 6で発生していました。最近Windows Server 2008に移動し、IIS 7.5でクラッシュもそこで発生しました。
これの根本的な原因を見つける方法は？
Tess Ferrandezのブログには、ステップバイステップガイドが含まれています。
https://blogs.msdn.com/b/tess/archive/2009/03/20/debugging-a-net-crash-with-rules-in-debug-diag.aspx
基本的に、その例外コードでトリガーするようにDebugDiag 1.2 x64を設定し、完全なユーザーダンプを作成します。ダンプが作成されたら、DebugDiagを使用してダンプを分析できます。その特定の例外を除いて、おそらくWinDbg + SOSを使用する必要があります。
より関連する情報のいくつか：
「ほとんどの人がおそらく知っているように、スタックオーバーフローの場合、最も一般的な理由は、ある種の再帰ループにいるためです。そこで、ここで本当に知りたいのは、このスタックにあるものです…それが表示される理由メソッド名ではなくアドレスのみです。これは、debug diagが.netを理解できないためです。ダンプをwindbgに持ってきて分析し、.netスタックを確認する必要があります。
「windbgでsos（。loadby sos mscorwks）をロードして！clrstack onコールスタックを取得するためのアクティブなスタック。」
（.NET 4を実行している場合、sosをロードするコマンドは。loadby sos clrです。 ）
最終的に、あなたが探しているのは、再帰を引き起こしているアプリケーションの問題のあるコードです。 SOSがロードされているときにWinDbgに表示されるメソッド名は、おそらく正しい方向を指すでしょう。
同じ問題がありました。私のコードでは、vb.netコードの次の行がありました
Dim mPath as string = Environment.GetFolderPath（Environment.SpecialFolder.Desktop）
実行時にこのフォルダーにアクセスできないため、ASP.NET全体がクラッシュしました。エラー処理が機能しません。 Clrは単にクラッシュします。
この行を既存のディレクトリに置き換えると、問題が解決しました。