it-swarm-ja.tech

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でクラッシュもそこで発生しました。

これの根本的な原因を見つける方法は?

6
shashi

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

6
Greg Askew

Get ProcDump を設定し、w3wp.exeプロセスがクラッシュしたときにダンプを生成するように構成します。ダンプを取得したら、Visual Studioまたは Windbg でそれを検査します。

3
friism

同じ問題がありました。私のコードでは、vb.netコードの次の行がありました

Dim mPath as string = Environment.GetFolderPath(Environment.SpecialFolder.Desktop)

実行時にこのフォルダーにアクセスできないため、ASP.NET全体がクラッシュしました。エラー処理が機能しません。 Clrは単にクラッシュします。

この行を既存のディレクトリに置き換えると、問題が解決しました。

0
mark stulens