問題タブ [minidump]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c - Visual Studio で一致しないシンボルを読み込むことはできますか?
Windows ミニダンプ (C コード) と対応する exe ファイルがあります。残念ながら、正確に一致する .pdb ファイルはありませんが、別の時点でビルドされたまったく同じコードを含む .pdb があります。Windbg では、次を使用できます。
不一致のシンボルファイルであっても、何でもロードするように指示します。これは、この特定のインスタンスではうまく機能し、適切なコール スタックを取得できます。Visual Studio にそのような機能があるかどうかに興味があります。ここでは、ほぼすべての異なるバージョンの VS を使用しているため、どのバージョンであっても問題ありません。ありがとうございます。
windbg - windbg での死後ミニダンプのデバッグ -- 原因ヒープメモリ用?
クラッシュダンプを見ています。一部の変数はwindbgで完全に表示できるように見えますが、他の変数は単に「メモリアクセスエラー」と表示されます。これは何が原因ですか?一部の変数には意味のある値があり、他の変数には単にリストされているのはなぜですか?
すべての問題は、次のポインターに関連付けられているようです。これらのポインターの多くは初期化されていませんが、それらの大部分は有効な場所を指しているはずです。このクラッシュの性質 (単純な null ptr デリファレンス) に基づいて、プロセス全体が昼食に出ていないことはかなり確信しています。
windows - メモリダンプに関する質問
現在、別のプロセスからクラッシュしたプロセスのメモリ ダンプを取得できるメモリ ダンプ ツールを設計しようとしています。しかし、私はこれにまったく慣れていないので、これを機会として、メモリ ダンプの手法をしっかりと理解したいと思います。
クラッシュしたプロセスのメモリ ダンプを作成する作業パラダイムを知りたいです。私の現在の野生の想像力は以下のようなものです:
プロセスがクラッシュすると、オペレーティング システムは常にそれを認識します (方法はわかりませんが、できるはずです)。その後、OS は何らかのメカニズムを起動して、クラッシュしたプロセスの仮想アドレス空間の内容をいわゆるダンプ ファイルにコピーしました。次に、WinDbg を使用してダンプ ファイルをデバッグできます。
クラッシュしたプロセスの仮想アドレス空間全体をダンプ ファイルにコピーできるとしたら、ファイルが大きすぎないのでしょうか。または、ダンプする仮想アドレス空間 (カーネル/ユーザー) を指定できますか?
特に次の側面について、私が最初に始めるための参考文献を誰かに提供してもらえますか。
メモリダンプとは?
いわゆるカーネル ダンプとユーザー モード ダンプがある場合、それらは何ですか?
Windows プラットフォームでは、どの API が必要ですか? MiniDumpWriteDump()などの関数は関係がありますか?
OS が特定のプロセスのクラッシュを検出した場合、ダンプ ツールにダンプの開始を通知するために監視できる信号はありますか?
私の言葉を見てくれてありがとう。
追加1:
(5) ミニダンプとは? カーネル/ユーザー モードのダンプとの関係は?
(6)メモリダンプについて話すとき、どのメモリについて話しているのですか? 仮想メモリまたは物理メモリ? この写真から、物理メモリだと思います。
ADD2:
DbgHelp.dll に含まれる API を使用した MiniDump の記述に関する参考文献を見つけました。シェアしたいと思います。これに関連する他の優れた資料を提供できる場合は、共有していただけませんか? ありがとう。
(ところで:私はこのスレッドを自分の進捗状況で更新し続けます。コメントをいただければ幸いです。)
debugging - MiniDumpWriteDump()関数のパラメーター:なぜハンドルとIDが必要なのですか?
以下のように、MSDNでMiniDumpWriteDump()メソッドの定義を確認しました。
パラメーター:
hProcess [in]
情報が生成されるプロセスへのハンドル。
ProcessId [in]
情報が生成されるプロセスの識別子。
プロセスハンドルまたはプロセスIDのいずれかでプロセスを識別できるのに、なぜ両方を渡す必要があるのでしょうか。それらの1つを他から推測することはできませんか?それで、それらの間にはいくつかの違いがあるはずです、それらは何ですか?
ありがとう。
debugging - 例外をスローする別のプロセスのスレッドIDを知る方法はありますか?
MiniDumpWriteDump()APIを使用して、クラッシュしたプロセスBを別のプロセスAからダンプしようとしています。MSDNが次のように言っているため、これを実行しています。
MiniDumpWriteDumpは、ダンプされるターゲットプロセス内からではなく、可能であれば別のプロセスから呼び出す必要があります。
MiniDumpWriteDump()は次のように定義されます。
特に、ExceptionParamのタイプはPMINIDUMP_EXCEPTION_INFORMATIONであり、次のように定義されています。
今、私は次の2つのパラメータをどのように準備するのか疑問に思っています。
ThreadId 例外をスローするスレッドの識別子。
ExceptionPointers コンピューターに依存しない例外の説明と例外時のプロセッサーコンテキストを指定するEXCEPTION_POINTERS構造体へのポインター。
プロセスAで実行しているときに、プロセスBで障害のあるスレッドIDと例外ポインターを取得するにはどうすればよいですか?
ありがとう。
c# - 致命的なエラーのミニダンプ
致命的なエラーが発生した場合にミニダンプ dmp ファイルを作成するユーティリティを作成したいと考えています。私は clrdump api を使用していますが、これはかなり簡単に思えます。
私が知りたかったのは、このミニダンプの作成を可能にする致命的なエラーが発生したときにイベントをトリガーする方法を決定するために、何を調べればよいかということです。
C#で書いていきます。
ありがとう。
visual-studio-2005 - .dll 関数を使用して、アプリケーションが Visual Studio によって作成されていないミニダンプを生成する
Visual Studio 2005 (アンマネージ C++) で生成された .dll ファイルがあります。DLL 内のさまざまな関数でエラーを検出し、DLL 内の別の関数を呼び出してミニダンプを生成できます (dbghelp.dll を使用)。
これは、DLL を使用するアプリケーションが VS2005 で作成されたプログラムでもある場合に完全に機能します。ただし、National Instrument Measurement Studio/CVI を使用してアプリケーションを作成すると (単純な C で、問題ではありません)、.pdb ファイルが取得されません (驚き!)。その結果、生成された .dmp ファイルを VS2005 で開くと、アプリケーションがデバッグを使用してビルドされていないことがわかり (ただし、ビルドされていました!)、表示されたスタックは役に立たないことがわかります。
この DLL の他の多く (40 以上) の関数は、CVI アプリケーションによって正常に使用されます。これは、非 VS アプリケーションから DLL 関数へのアクセスが成功したことを示しているようです。
National Instruments は明らかに DrWatson からの完全なダンプを使用できるので、それは可能であるに違いありません。
.dmp ファイルを使用するために必要なものを入手する方法を知っている人はいますか?
要約すると、.NET なし、関数アクセスは問題ありません。生成されたミニダンプ ファイルは Visual Studio では使用できないようです。
ご協力いただきありがとうございます。
.net - (WPF) ネイティブ イメージが関係している場合、混合モードのミニダンプの完全なスタック トレースを取得するにはどうすればよいですか?
WPF を使用する混合モードの C++/CLI アプリケーションがあります。お客様からのクラッシュは、ミニダンプとして独自のサーバーに報告されます。
windbg sos-extension から !pe または !clrstack コマンドを使用してミニダンプを調査しようとすると、WPF アセンブリからスタック フレームに関する不完全な情報が得られることがよくあります。
この場合、スタック トレースのデコードも非常に遅くなります。
!sym ノイジーを使用すると、次のメッセージが大量に表示されます。
使った
c:\Windows\System32;SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
windbg シンボルおよびイメージ パスとして。
私が理解している限り、クラッシュが発生したマシンとデバッガーを搭載したマシンが Windows バージョン、SP の .NET バージョンに関して異なる場合、これは .NET ネイティブ イメージでのみ発生します。主に WPF ネイティブ イメージで見てきました。
この問題を回避するにはどうすればよいですか?
私の最初の質問への更新:
異なる mscordacwks dll バージョンで同様の問題に苦労したことを忘れていました。SOS を使用するには、クラッシュしているコンピューターで使用されていたバージョンの mscordacwks.dll がデバッグ コンピューターに必要です。そこで、さまざまな Windows と SP の組み合わせからこの dll のさまざまなバージョンを収集し、独自のシンボル サーバーに配置することにしました。もちろん、これは非常に厄介です。特別な規則 (mscordacwks_x86_x86_2.0.50727.4952.dll など) に従って名前を付ける必要があるため、なおさらです。
以下の Rick の回答を正しく理解している場合は、参照する .NET アセンブリのネイティブ イメージに対して同様のことを行う必要があります。1 つの例 (WindowsBase.ni.dll) でこれを手動で試しましたが、この dll をシンボル サーバーに簡単に保存できませんでした。symstore がネイティブ イメージを認識していないようです。symstore からのエラー メッセージは次のとおりです。
そのため、それを追加のディレクトリに配置して、シンボルまたはイメージ パスに追加しようとしたところ、SOS は WindowsBase_ni フレームを正しくデコードしました。
しかし、これはすべて面倒な手動セットアップ作業のように思えます: さまざまな .NET バージョンのすべてのネイティブ イメージを取得し (SP とセキュリティ アップデートはどうなるか)、symstore を使用できないため手動でデバッガーをセットアップする...
これが本当に唯一の方法ですか?
顧客の環境を制御できれば、おそらくそれほど問題にはなりません。しかし、大規模なユーザーベース向けに混合モードのアプリケーションを構築している組織にとって、事後分析のデバッグは悪夢のようです。
c++ - ミニダンプ ファイルまたは例外構造がある場合、winqual が使用する「バケット ID」を取得するにはどうすればよいですか? (Windows C++)
SOには関連する質問がいくつかありますが、答えは見つかりませんでした-
「署名」/バケット ID を生成して、ミニダンプ/クラッシュを問題追跡システムに報告したいと考えています。MSはすでに「バケットID」でこれを行っているため、バケット/署名の生成を再利用できると考えました。
トップ レベル フィルター、フィルター内にある _EXCEPTION_POINTERS オブジェクト、_MINIDUMP_EXCEPTION_INFORMATION 構造体、またはミニダンプ自体からその ID を取得できますか?
これは C++ アプリケーションです。
.net - windbgで!clrstackを使用できるように.netコンポーネントをホストするネイティブC++プロセスをダンプするために設定された最小のMINIDUMP_TYPEは何ですか
いくつかの.netコンポーネントをホストするネイティブC++アプリケーションがあります。エラーが発生すると、このアプリケーションはMiniDumpWriteDump関数を使用してミニダンプを作成します。ここで質問の最小セットは何ですか
小さなダンプファイルを生成するためにMiniDumpWriteDumpに渡す必要がありますが、clrスタックを表示する機能があります)?確かに、フルメモリダンプは機能しますが、耐えられる最小値のみを取得するにはどうすればよいですか?