2

ASP.NET Web サイトが、IIS を死のスパイラルに陥れる WCF サービス メソッドを呼び出そうとするという、特に厄介なバグに遭遇しました。最終的には、関連付けられているアプリ プールがダウンします。未処理の例外を出力する log4net コードには到達しません。

w3wp.exe プロセスがスピンアップして停止するのを見ていたので、次のコマンドを使用してSysInternals から ProcDumpを使用して、終了時にダンプ ファイルを取得することにしました。

procdump -e -t -ma <PID> aspnet.dmp

これにより、VS2010 で開くことができるミニダンプ ファイルが取得され、ヒープ情報が存在することが示されます。これはエキサイティングです：

ミニダンプのまとめ

したがって、この時点で、その特定の Web サイトの bin フォルダーであるシンボル パスを設定しようとします。適切なサーバーからコピーしました。ただし、ネイティブのみでデバッグするオプションしか取得できず、それを行うと、適切なシンボルが見つかりません。

これが私のPDBの場所の設定です:

PDB オプション

コール スタックが Windows DLL のどこかで停止しているように見えるためかどうかはわかりません...? コールスタックウィンドウの画面です。

コール スタック

とにかく、私の究極の質問は、この例外の原因を見つけるための適切な道をたどっているかどうかです。もしそうなら、何が欠けていますか? アンマネージ コードにあるように見えますが、すべてが爆発する前に最後のマネージ コールを見たいと思っています。

また、参考までに、Web サーバーは Win2003 x86、私の PC は Win7 x64 です。

ありがとう！

4

2 に答える 2

2

I came across this too. VS2010 won't do the nice, friendly debugging of a dumpfile of a managed app unless it was a .NET 4.0 executable assembly that crashed.

于 2010-09-18T05:24:04.847 に答える
1

ダンプの分析には常に winDbg を好みます。また、MSFT の Debug Diags を調べることをお勧めします。これは、アプリを監視し、クラッシュの直前にダンプを作成する Windows サービスです。これにより、ダンプに必要な情報が確実に含まれるようになります。ダンプを取得したら、それを WinDbg にロードし、SOS 拡張 DLL のツールを使用して問題を見つけます。

于 2010-08-23T14:52:27.410 に答える