問題タブ [minidump]

私は最近、作業中の実稼働環境でのw3wpプロセスのクラッシュを分析するのに役立つダンプファイルを調べ始めました...

ミニダンプとフルダンプファイルの違いは何ですか？

VS2010で.NET4.0アプリを開発しています。

初めてダンプファイルを使用しようとしていますが、ミニダンプをVSにロードするときに、VSがソースファイルを見つけられないため、デバッグできません。

これが私がしたことです：

• にOptions -> Debugging -> Symbols、pdbを含むアプリのビルドディレクトリを追加しました。
• VSデバッガーでアプリを実行しました。選択されDebug -> Break Allました。
• 選択済みDebug -> Save dump as
• Windowsエクスプローラーのダンプファイルに移動して開きました。これにより、VSの新しいインスタンスが開かれました。
• 「混合でデバッグ」をクリックしました。これにより、という新しいタブが開きました"There is no source code available for the current location。

VSが私のpdbsをロードしなかった理由を理解しようとしました：

• オープンDebug -> Windows -> Modules
• MyApp.exeのSymbol Status列に「シンボルがロードされました」と表示されていました。
• MyApp.vshost.exeの場合、「PDBファイルが見つかりません」と表示されていました。
• MyApp.exeを右クリックし、[シンボルの読み込み情報]を選択します。「MyApp.pdb：シンボルがロードされました」と表示されました。
• MyApp.vshost.exeについても同じことをしました。vshost32.pdb ：PDBファイルが見つからないか開くことができません。。（何らかの理由で、MyApp.vshost.pdbではなくvshost32.pdbという名前のファイルを検索する方法に注意してください）

それで、何かアイデアはありますか？

この C# アプリケーションは、未処理の例外が発生したときに MinidumpWriteDump を呼び出します。

ユーザーからいくつかのクラッシュ ダンプを受け取りましたが、SOS でクラッシュ ダンプを開くことができず、クラッシュの原因となった例外を確認できません。

取得しているダンプの種類はMiniDumpWithPrivateReadWriteMemory です

MS パブリック シンボル サーバーを使用するように _NT_SYMBOL_PATH を構成しました。このクラッシュ ダンプを WinDBG でデバッグすると、必要な DLL が自動的にダウンロードされます (このダンプは、別のバージョンの .NET 2 を搭載したマシンで取得されたものです。 .3053)

!Threads を実行すると、次の出力が得られます。

ThreadStore のリクエストに失敗しました

ダンプマシンで取得したものとは異なるバージョンの CLR を処理するためのテクニックを説明しているすべての可能なサイトを調べましたが、どれもうまくいきませんでした。

これらのクラッシュをデバッグするにはどうすればよいですか?

何か問題がありますか (.NET プロセスから間違った種類のダンプを取得するなど)。

編集：

~* の結果は次のとおりです。

0:000> ~* . 0 Id: 1338.258 Suspend: 0 Teb: 7ffdf000 Unfrozen Priority: 0 1 Id: 1338.2a0 Suspend: 0 Teb: 7ffde000 Unfrozen Priority: 0 2 Id: 1338.1fd4 Suspend: 0 Teb: 7ffdd000 Unfrozen Priority: 0 3 Id: 7e838. : 0 Teb: 7ffda000 Unfrozen Priority: 0 4 Id: 1338.1148 Suspend: 0 Teb: 7ffd9000 Unfrozen Priority: 0 5 Id: 1338.b1c Suspend: 0 Teb: 7ffd7000 Unfrozen Priority: 0 6 Id: 1338.f94 Suspend: 0 Teb: 7ffd4000 Unfrozen Priority: 0 7 Id: 1338.11b4 Suspend: 0 Teb: 7ff4f000 Unfrozen Priority: 0 8 Id: 1338.1814 Suspend: 0 Teb: 7ff4e000 Unfrozen Priority: 0 9 Id: 1338.1cc4 Suspend: 0 Teb: 0 冷凍優先度 1 Id: 1338.1e48 サスペンド: 0 Teb: 7ffd5000 凍結解除優先度: 0 11 Id: 1338.

!analyze -v の結果は次のとおりです。

分析する

Google Breakpad を使用して、Windows アプリケーションがクラッシュしたときにクラッシュ ダンプを生成しています。

私のアプリケーションでは、C++ ネイティブ コードと C# CLR コードが混在しています。ブレークパッドが生成するダンプには、CLR 情報は含まれません。

Breakpad で CLR ダンプを有効にすることはできますか? CLR ダンプを作成するには、どの API が必要ですか?

.NET から MiniDumpWriteDump を呼び出してミニダンプを生成しましたが、正常に動作します。ただし、結果のダンプを VS 2010 にロードすると、有用な情報が表示されません。具体的には、コール スタックウィンドウは次のようになります。

マネージ コードの例外ハンドラーでダンプを書いていますが、マネージ フレームは含まれていません。また、私のexeにあるフレームは含まれていません。

なぜこれが起こるのか分かりますか？

ところで、VS デバッガーから手動でダンプを作成すると、期待どおりにマネージド フレームがダンプに含まれます。

編集：

これに関するMicrosoft Connect の問題を見つけました。それは言います：

現在、CLR は、独自のダンプを取得するマネージド プロセスをサポートしていません。

それがまだ本当かどうか知っている人はいますか？

私は混合モードのアプリ (C++/CLI、C++、いくつかの C#) に取り組んでおり、フィールドでクラッシュするとメモリ ダンプが作成されます。私は通常、顧客からこれらのダンプを受け取り、何が問題だったのかを突き止めようとします。

問題は、マネージド コードの事後分析デバッグをどのように処理するかということです。私は通常、SOS.dll で WinDbg を使用しますが、SOS には後方互換性がないようです! 最近 Windows Update を実行しましたが、クライアント サイトからミニダンプを読み込めません。SOS のバージョンが間違っていると表示されます。

以前のバージョンを取得してロードするにはどうすればよいですか? 私は何か間違ったことをしていますか？

マネージド アプリのミニダンプの生成に取り組んでいます。これが私がこれまでに持っているものです：

• この記事のように例外フィルターを設定しました。フィルターでは、MiniDumpWriteDump を呼び出します。
• 結果のダンプを VS デバッガーにロードし、コール スタックを参照して、ローカルの値を表示することができました。

ただし、プロジェクトで最適化が有効になっている場合、ローカルの値にアクセスできません (取得します"The value of the local or argument 'x' is unobtainable at this time")。これで、なぜこのようなことが起こるのかがわかりました。最適化により、ローカルの再利用などを行うことができます。これは、コンパイルされたコードがソース コードを反映していないことを意味します。

私の質問: 回避策はありますか? 最適化されたコードを取得し、ローカルにアクセスできるようにする方法はありますか? ミニダンプを生成/表示するためにサードパーティのツールを使用することに反対しているわけではありません。

必要に応じてクラッシュ ダンプを手動で作成する方法に関する投稿を多数見つけましたが、監視対象のアプリケーションがクラッシュしたときにクラッシュ ダンプが確実に生成されるようにしたいと考えています。

TechNet の PROCDUMP ツールは、これを完全に行うことができます。私が知りたいのは、独自の管理プログラムで同じことを行うコードを記述して、例外が発生したときにのみダンプ ファイルを作成する方法です。

私のプログラムは、監視したいプログラムのプロセス ID を知っているサービス アプリです。

明確にするために、PROCDUMP へのこの呼び出しが何をするかを模倣したいと思います。

procdump -e someprocess.exe -w

理論的には、Windows は DrWatson を使用してこの作業を行うことができるはずです。私が抱えている問題は、アプリケーションがランダムにクラッシュすると主張している約 200 の顧客システムを実行していることです。ワトソン博士は、アプリケーションがクラッシュしているという事実を確認していないようです。そのため、クラッシュ ダンプの生成を独自のソフトウェアで制御することにしました。

__try/except および MiniDumpWithFullMemory タイプの MiniDumpWriteDump() を使用して、独自のアプリケーションで独自のダンプを作成することができましたが、WinDbg でローカル変数などを見ることができないため、これはアプリケーション自体からトリガーされた..だから..監視/管理タイプのアプリケーションで仕事をしたいもう1つの理由。

少なくとも..あるアプリケーションが別のアプリケーションのクラッシュにどのように反応できるでしょうか? ある種のデバッグ フックをインストールする必要がありますか、それとも管理プログラムが実際にはカスタム デバッガーであるふりをする必要がありますか?

乾杯

一部のアプリで問題が発生しています。これは、Windows 2003 Server (x86) の IIS6 で実行されている wcf ベースのアプリです
。

私は何が起こっているのかを理解しようとしています。このKBで説明されているように、孤立したワーカー プロセスのダンプを作成するように設定しました。デッドロックが発生すると、ミニダンプが作成されます。
次に、このミニダンプを取得して、何が起こったのかを理解しようとします。ここで私は立ち往生しています。

WinDbg x86 を実行し、ダンプを開いてから:

このエラーの対処方法- 「SOS のバージョンは、デバッグしている CLR のバージョンと一致しません」?

VS2010 でミニダンプを開くと、同じエラー (「SOS のバージョンが、デバッグしている CLR のバージョンと一致しません」) が発生します。

この投稿を読みました - http://tech-thinker.com/Forums/tabid/62/forumid/12/postid/471/scope/posts/Default.aspx、インストールを試みましたKB2518870。役に立ちません。

Windowsのミニダンプファイルから障害のあるスレッドのスタックトレースを読み取る方法を見つけようとしています。簡単な解決策はありますか？見つからない。

申し訳ありませんが、プログラムで行う必要があることを忘れていました。

DbgEng を使用する必要がありますか?

どうも