問題タブ [memory-dump]

リークを追跡するためにいくつかのユーザー モード メモリ ダンプを分析しており、リークの候補がいくつかありますが、!heap -flt s xx コマンドを実行すると、ダンプにこれらのエントリが表示され続けます。 .

私は何を得る

行ですが、行が何であるかはよくわかりません

本当に意味。これらのダンプは、ヒープ トレースの +ust フラグでキャプチャされました。

同じ .net 3.5 アプリケーションの 2 つのバージョンの前後比較をしようとすると、使用するツールによっては一貫性のない結果が得られます。

typeperf - これは信頼できると思いますが、次のように述べています。

• v1: 244MB / 260MB (プライベート バイト / ワーキング セット)
• v2: 281MB / 296MB

Process Explorerでは、パフォーマンス グラフに次の数値が表示されます。

• v1: 283MB (プライベート バイト)
• v2: 262MB

そのため、typeperf は v2 がより多くのメモリを消費したと言っていますが、Process Explorer は反対のことを主張しています。

これらはすべて別々の測定値であり、異なる実行ですが、数値は驚くほど確実に再現可能です。

前述の 2 つのツールに加えて、 Process Explorer から完全なメモリ ダンプを取得し、ファイル サイズのみを確認しました (WinDbg を実行したり、その他の方法で分析したりする時間がありませんでした)。

• v1: 484MB (完全なダンプ ファイル サイズ)
• v2: 480MB

また、アプリを.net Memory Profilerから実行すると、ネイティブ メモリ、.net メモリ、および合計メモリの両方が、v1 よりも v2 の方が低くなります。

したがって、それは世界の他の地域に対して typeperf であるようです (WinDbg 分析はまだ未解決です)。

誰が正しいのか、どうすればわかりますか?

Eclipse Memory Analyzer (MAT とも呼ばれます)を使用して、Android アプリのメモリ使用量を分析しています。android.graphics.Bitmapヒープの大部分を使用して、クラスの奇妙なインスタンスを見つけることがあります。問題は、このビットマップのソースが見つからないことです。 filenameもresourceIDも何もありません。ビットマップについて見つけることができるすべての情報は次のとおりです。

画像ピクセルの配列を持つフィールドがあるmBufferと思います。しかし、それは PNG ではなく、内部の Android 形式です。

質問: このビットマップで表されるイメージをメモリ ダンプから表示するにはどうすればよいですか?

デバッガーのないコンピューター (クライアントのコンピューターなど) でのテスト中に、プログラムの状態を壊した可能性があるが実際にはクラッシュしていないバグに遭遇した場合、Windows タスク マネージャー (右クリック) を使用してメモリ ダンプを取得できることがわかっています。プロセス名で、ダンプ ファイルを作成します)。

これらを WinDbg で使用してメモリ内をのぞくことができますが、プログラムとの対話を継続できるように、ダンプをメモリに復元できることが最も便利です。これは可能ですか？もしそうなら、どのように？それを復元できるツールはありますか、それとも自分で作成する必要がありますか。

64ビットマシンからの64ビットw3wpプロセスのメモリダンプがあります。WinDbgで開き、psscorまたはsosで分析すると、正常に動作します。

ただし、DebugAnalyzerツールを使用しようとしています。それを開いて「分析の実行」を押すと ボタンをクリックすると、ダイアログボックスに表示されるエラーメッセージは次のとおりです。

シンボルパスは正しく（WinDbgが使用するものと同じ）、64ビットバージョンのDebugAnalyzerを使用しています。w3wpプロセスで使用される.NETバージョンは.NET4です。

mscorwks.dllマシンのどこにも見つかりませんがmscordacwks.dll、シンボルパスにあります。しかし、WinDBGはそれを必要としないようであるため、それが問題であるかどうかはわかりません。

このツールを使用した経験や、トラブルシューティングの手順を提案した人はいますか？

未処理の例外用に作成されたDLLから、なんとか作成したダンプファイルがあります。

n = 4 のようなことint* tt = new int[4]; return int[n];をすると、ダンプ ファイルを取得し、それを開いて、エラーが発生した行を確認できます。これは、リリース exe から直接、およびリリース DLL の両方で可能でした。

これは簡単なエラーで、メモリ ダンプの作成をテストするために入力しただけです。

現在、900kb のダンプ ファイルがあり、イベント ログには、エラーが .DLL に起因することが示されていますが、ファイルを開いても、ソース コードは表示されません。

コールスタックは

KERNELBASE.dll!RaiseException() + 0x3d bytes
clr.dll!RaiseTheExceptionInternalOnly() + 0x18f bytes
clr.dll!IL_Throw() + 0xe2 bytes
000007fe81f65fd7()
00000000034d1610()
000000002d06ecb8()
436f93ce00050011()
436f93cf00110012()
000000002d06ec50()
00006d930c4f7680( )
clr.dll!InlinedCallFrame::`vftable'()
000000002d06f3d8()

これは、DLLのどこからエラーが発生しているのかを理解するのにまったく役立ちません。これをデバッグする際のもう 1 つの問題は、ライブ PC でのみ発生し、私のデバッグ システムでは発生しないことです。これをデバッグする方法を見つけるのを手伝ってくれる人はいますか? DLLの呼び出しで発生するようですが、毎回ではなく、2回ごとにのみ発生します（1回目の試行の場合もあれば、5回目の試行の場合もあります）。ここで何が起こっているのか、私は完全に迷っています。

編集: Microsoft シンボルをロードしてコール スタックを更新しましたが、これがどこから来ているのかはまだわかりません。

現在、実稼働環境で .NET Windows サービス アプリケーションを監視し、メモリ ダンプを収集できるソリューションを探しています。いくつかの特定のしきい値に基づいて、自由に、アプリケーションのクラッシュに基づいてそれらを収集したいと思います。これを達成するためのさまざまな方法を認識しています。

1. DebugDiag
2. Procdump
3. WERを通じて
4. ADプラス
5. WinDbgなど

メソッドの中には、オプション #3 など、クラッシュ時の収集を容易にするものもあれば、#1 や #2 など、パフォーマンス カウンターに基づいてトリガーできるものもあります。非侵襲的なデバッガーであれば、コレクションを実現するのに役立ちますが、アタッチするとパフォーマンスにどのような影響があるかわかりません。たとえば、-e スイッチを指定して Procdump を使用して、未処理の例外のメモリ ダンプを収集した場合、監視対象のアプリケーションのオーバーヘッドはどのくらいになるでしょうか? 実稼働環境について言及していることに注意してください。

メモリ ダンプ収集用の非侵襲的デバッガを接続することによるパフォーマンスへの影響を説明するソースまたは方法を教えていただければ幸いです。理想的には、それは私の期待を超えていますが、定量的な尺度になるでしょう.

PS: アプリケーションが完全にフリーズしているディスクにメモリ ダンプが書き込まれるまでの時間については言及していません。それは別のことです。

Advanced .NET Debugging の本を読んでいて、とても気に入っています。ただし、例にはいくつか問題があります。読んだことがある人が助けてくれたら本当にうれしいです。

2 つの質問があります。

1. どのバージョンの .NET Framework がビルドされた例ですか? 私はそれらをwindbg(x86)で実行できず、windbg(x64)でロードするので、フレームワークの64ビットバージョンだと思います。しかし、どのフレームワークですか？2.0、3、3.5、4?

2. 第 2 章で説明したように型ハンドル (メソッド テーブル) を見ると、異なる結果が得られました (私の結果と本が示す内容を以下に示します)。もちろん、アドレスが違うという話ではありません。たとえば、メソッド テーブルを追加すると、Flags2 フィールド、NumMethods フィールドに異なる値が表示されます。理由がわかりません。56 ページで、著者は、オブジェクトには 4 つの整数があるため、オブジェクトのサイズは 0x14 (私のマシンでも同じ) であると述べています。しかし、02TypeSample.cs のリストには、x、y、z の 3 つの整数しか表示されません。私のマシンでは、dd は例では 7 を示しているのに 4 つのメソッドを示しています。また、コンパイラがデフォルト ctor を生成したとも書かれています。

   「最初に覚えておくべきことは、コンストラクターを明示的に定義していなくても、C# コンパイラーがデフォルトのコンストラクターを自動的に生成したことです。

   リストすると、TypeSample には 3 つの整数をパラメーターとして取る ctor があることがわかります。私、本、または例に何か問題があります。それは何ですか？;)

したがって、それぞれ独自の AppPool が割り当てられた一連の ASP.net Web アプリがあります。

これにより、w3wp.exe の複数のインスタンスがメモリに常駐します。

私は、そのうちの 2 人が 1 日の間に RAM の使用量を着実に増やしている理由を突き止めようとしています。

「デバッグ診断ツール」が役立つかもしれないというこの提案を見つけました：

インストール済みのものをダウンロードし、それを使用してプロセスの完全なダンプを作成しようとしました。

何らかの理由で失敗しました。

しかしその後、使用されたメモリ (プライベート バイト) が約 600Mb から約 90Mb に減少したことに気付きました。

DDT によってアプリが再起動 (またはリサイクル) されたのでしょうか? それとも、何らかの形式のガベージ コレクションが呼び出されて、アプリが大量のメモリを解放したのでしょうか?