質問: 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に表示されるメソッド名は、おそらく正しい方向を指すでしょう。