問題タブ [windbg]

Microsoft の windbg デバッガーに関連する最大の不満は何ですか?

(注: 洗練されていない UI を無視すれば、windbg が実際にとても気に入っています。)

現在、.DMP (または .MDMP) ファイルを右クリックすると、[開く] ポップアップに Visual Studio 2005 および 2008 が表示されます。どちらの Visual Studio オプションも削除せずに、このリストに WinDbg を追加するにはどうすればよいですか?

「プログラムの選択」オプションを使用したところ、リストに WinDbg が追加されました。残念ながら、WinDbg で .DMP ファイルを開くにはいくつかのコマンド ライン オプションが必要ですが、レジストリにこのエントリが見つからないため、編集するものがありません。

IE7がWebアプリへのアクセスをハングする状況があります。George V. Reillyからの優れた提案に基づいて、WinDbgをインストールしてIEシンボルをダウンロードし、それらのシンボルを使用するようにProcess Explorerをセットアップしてから、ProcessExplorerを使用してハングしたスレッドのスタックトレースを取得しました。

以下にスタックトレースを貼り付けました。IEの内部に精通している人は、何が起こっているのか、またはこれをどのように進めるかについての提案を持っていますか？

マネージ コードのクラッシュ ダンプをデバッグしています。ここで !threads を使用してすべてのスレッドを表示すると、いくつかのスレッドにさまざまな例外を含む Exception フィールド値があります。

私の質問は、どの例外がプロセスのクラッシュを引き起こすルート例外であるかをすばやく特定する方法です。非常に多くのスレッドが例外値に関連付けられている理由 - プロセスのクラッシュを引き起こすスレッド (未処理の例外を含む) は 1 つだけである必要があると思いますが、非常に多くのスレッドが例外を示すのはなぜですか? :-)

前もって感謝します、ジョージ

!threads の一部の出力例を次に示します。FooException と GooException は、私のアプリケーションで定義された例外の種類です。

48 f 14c4 000000001d8bc4a0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093365da0) 49 10 17e8 000000001acc26d0 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093364670) 50 11 135c 000000001acc3180 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (00000000dd707f70) 51 12 1740 000000001aca2ec0 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (00000000937e8a60) 52 13 814 000000001aca3970 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA GooException (000000009336c550) 53 14 6ac 000000001accb010 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093355f58) 54 15 1114 000000001accbac0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA 56 16 d44 000000001accc570 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA GooException (00000000933c0598) 58 17 ff4 000000001accd020 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException ( 00000000a8a39c48) 59 18 780 000000001accdad0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA 60 19 8fc 000000001acce580 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (00000000abd5ff08) 61 1a 2e8 000000001accf030 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (00000000ac163ea0) 62 1b 11e8 000000001d8bd010 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093367c78) 63 1c 1520 000000001d8bd5e0 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA 64 1d 1330 000000001d8be090 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException ( 00000000937d9540) 65 1e 7f8 000000001d8beb40 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (000000009339a038) 66 1f a70 000000001d8bf5f0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (00000000937d8b88) 67 20 150 000000001d8c00a0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA 68 21 1628 000000001d8c0b50 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093355200) 69 22 1148 000000001d8c1600 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA GooException (000000009380ada8) 70 23 16a8 000000001d8c20b0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException ( 0000000093365178) 71 24 1640 000000001d8c2b60 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093343a78) 72 25 1568 000000001d8c3610 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (000000009380cc08)0000000000000000 0000000000162080 0 MTA FooException (0000000093355200) 69 22 1148 000000001d8c1600 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA GooException (000000009380ada8) 70 23 16a8 000000001d8c20b0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093365178) 71 24 1640 000000001d8c2b60 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093343a78) 72 25 1568 000000001d8c3610 b020 有効 000000000000000:000000000000000 0000000000162080 0 MTA FooException (0000000809) 80000000000000000 0000000000162080 0 MTA FooException (0000000093355200) 69 22 1148 000000001d8c1600 200b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA GooException (000000009380ada8) 70 23 16a8 000000001d8c20b0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093365178) 71 24 1640 000000001d8c2b60 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093343a78) 72 25 1568 000000001d8c3610 b020 有効 000000000000000:000000000000000 0000000000162080 0 MTA FooException (0000000809) 80000000000000000 0000000000162080 0 MTA GooException (000000009380ada8) 70 23 16a8 000000001d8c20b0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093365178) 71 24 1640 000000001d8c2b60 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093343a78) 72 25 1568 000000001d8c3610 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (000000009380cc08)0000000000000000 0000000000162080 0 MTA GooException (000000009380ada8) 70 23 16a8 000000001d8c20b0 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093365178) 71 24 1640 000000001d8c2b60 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (0000000093343a78) 72 25 1568 000000001d8c3610 b020 Enabled 0000000000000000:0000000000000000 0000000000162080 0 MTA FooException (000000009380cc08)0000000000000000000000000000162080 0 MTA FOOEXCEPTION（0000009343A78）72 25 1568 00000000000000000000000000000000：00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000162080 0 MTA FOOEXCEPTION（0000009343A78）72 25 1568 00000000000000000000000000000000：0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

ここで、私たちの Web アプリで厄介な問題が発生します。(Asp.net 2.0 Win サーバー 2008)

ウェブサイトのメモリ使用量は、かなり静的なレベルにとどまると予想されますが、どんどん増えていきます。(状態に保存される少量のデータがあります)。

問題が何であるかを知りたくて、私は System.GC.Collect(); を実行しました。数回、メモリ ダンプを取得し、このメモリ ダンプを WinDbg にロードしました。

DumpHeap -Stat を実行すると、メモリ内にぶら下がっている特定のタイプの数値が異常に大きくなります。

0000064280580b40 713471 79908752 支払いオプション

したがって、この型に対して DumpHeap -MT を実行すると、オブジェクト参照のスタックが得られます。これらのランダムな数を選択して !gcroot を実行すると、コマンドが戻ってきて、参照が保持されていないことが報告されます。

私には、GC がこれらのアイテムを収集するのはまさにこのときですが、何らかの理由で未処理のままになっています。

何が起こっているのか説明できる人はいますか?

WindbgまたはVisualStudioを使用してダンプファイルを分析するときに、どのシンボルファイルが使用されるかに興味があります。アプリケーションがユーティリティライブラリを使用していて、ユーティリティライブラリに関連するプライベートシンボルファイルがあるとします。アプリケーションにクラッシュダンプがある場合、完全な呼び出しスタックを分析するためにユーティリティライブラリのシンボルが必要です。ただし、ビルド/ランタイム/デバッグ環境に、異なるバージョンのユーティリティライブラリがインストールされている場合があります。これは（確かに）異なるバージョンのユーティリティライブラリシンボルです。

アプリケーションをビルド（リンク）するためのバージョン（バージョンAなど）のユーティリティライブラリ（および関連するシンボル）があり、クラッシュが発生したときに実行時に別のバージョン（バージョンBなど）のユーティリティライブラリ（および関連するシンボル）を使用するとします。クラッシュダンプを分析するときに、Windbgでユーティリティライブラリ（および関連するシンボル）の別の異なるバージョン（バージョンCなど）を使用します。

私の質問は、クラッシュが実行時に生成される場合、バージョンBのシンボルを使用してクラッシュダンプを生成します（ダンプをシンボル情報で埋めるため）？しかし、Windbgデバッグ環境で異なるバージョンのシンボルCを使用すると、シンボルの不一致の問題が発生しますか？また、ビルドに使用されるライブラリのバージョンは重要ではありませんか？私の理解はすべて正しいですか？

よろしくお願いします、ジョージ

私が取り組んでいるC＃/。NETアプリケーションは、遅いメモリリークに悩まされています。私はSOSでCDBを使用して何が起こっているのかを判断しようとしましたが、データが意味をなさないように思われるので、あなたの1人が以前にこれを経験したことがあると期待していました。

アプリケーションは64ビットフレームワークで実行されています。データを継続的に計算してリモートホストにシリアル化し、ラージオブジェクトヒープ（LOH）にかなりの打撃を与えています。ただし、一時的なものと予想されるLOHオブジェクトのほとんどは、計算が完了してリモートホストに送信されたら、メモリを解放する必要があります。しかし、私が見ているのは、メモリの空きブロックでインターリーブされた多数の（ライブ）オブジェクト配列です。たとえば、LOHからランダムなセグメントを取得します。

明らかに、私のアプリケーションが各計算中に長寿命で大きなオブジェクトを作成している場合は、これが当てはまると思います。（これを行い、ある程度のLOHフラグメンテーションがあることを受け入れますが、ここでは問題ではありません。）問題は、上記のダンプで確認できる非常に小さい（1056バイト）オブジェクト配列であり、コードでは確認できません。作成されており、何とか根付いたままです。

また、ヒープセグメントがダンプされたときに、CDBがタイプを報告しないことに注意してください。これが関連しているかどうかはわかりません。マークされた（<-）オブジェクトをダンプすると、CDB/SOSはそれを正常に報告します。

オブジェクト配列の要素はすべて文字列であり、文字列はアプリケーションコードから認識できます。

また、！GCRootコマンドがハングして戻ってこないため、GCルートを見つけることができません（一晩放置しようとしたこともあります）。

したがって、これらの小さな（<85k）オブジェクト配列がLOHに配置される理由について誰かが光を当てることができれば、非常にありがたいです。.NETはどのような状況で小さなオブジェクト配列をそこに配置しますか？また、これらのオブジェクトのルートを確認する別の方法を知っている人はいますか？

アップデート1

昨日遅くに私が思いついたもう1つの理論は、これらのオブジェクト配列は最初は大きく、縮小されて、メモリダンプに明らかな空きメモリのブロックが残っているというものです。私が疑わしいのは、オブジェクト配列が常に1056バイトの長さ（128要素）、参照用に128 * 8、32バイトのオーバーヘッドであるように見えることです。

ライブラリまたはCLR内の安全でないコードが、配列ヘッダーの要素数フィールドを破損している可能性があります。私が知っているちょっとしたロングショット...

アップデート2

Brian Rasmussen（受け入れられた回答を参照）のおかげで、問題は文字列インターンテーブルによって引き起こされたLOHの断片化として識別されました！これを確認するためのクイックテストアプリケーションを作成しました。

アプリケーションは最初に、ループ内の一意の文字列を作成して逆参照します。これは、このシナリオでメモリがリークしないことを証明するためだけのものです。明らかにそうすべきではなく、そうではありません。

2番目のループでは、一意の文字列が作成され、インターンされます。このアクションは、それらをインターンテーブルにルートします。私が気づかなかったのは、インターンテーブルがどのように表現されているかです。これは、LOHで作成された一連のページ（128個の文字列要素のオブジェクト配列）で構成されているようです。これはCDB/SOSでより明白です。

LOHセグメントのダンプを取ると、リークしているアプリケーションで見たパターンが明らかになります。

ワークステーションが32ビットで、アプリケーションサーバーが64ビットであるため、オブジェクト配列のサイズは（1056ではなく）528であることに注意してください。オブジェクト配列はまだ128要素の長さです。

したがって、この話の教訓は、非常に慎重なインターンを行うことです。インターンしている文字列が有限集合のメンバーであることがわからない場合、少なくともCLRのバージョン2では、LOHの断片化が原因でアプリケーションがリークします。

私たちのアプリケーションの場合、逆シリアル化コードパスに、非マーシャリング中にエンティティ識別子をインターンする一般的なコードがあります。これが原因であると強く疑っています。ただし、同じエンティティが複数回逆シリアル化された場合に、識別子文字列の1つのインスタンスのみがメモリに保持されるようにしたかったので、開発者の意図は明らかに良かったです。