問題タブ [postmortem-debugging]

アプリケーションのデバッグ バージョンを 1 つのフォルダーにコンパイルしました。現在、すべてのdll、pdb、およびpdbを含むexeがあります。Taskmanager を使用して、このパスから開始した実行中のアプリケーションの MiniDump を作成しました。これで、この dmp ファイルを Visual Studio 2010 で開くことができます。しかし、デバッグしようとすると、シンボルが見つからないというメッセージが表示されます。Visual Studio のシンボル パスに自分のシンボル (pdb) へのパスを追加しましたが、成功しませんでした。また、モジュールの ContextMenu を介してシンボルをロードしようとしました。そこを検索してMyApp.pdbおり、正しいpdbを選択しました。しかし、私はメッセージを受け取りますA matching symbol file was not found in this folder。

Visual Studio 2010 を使用して MiniDump の事後分析デバッグを行うにはどうすればよいですか (シンボルが検出されるようにします)。

現在実行中の Java プログラム (ダウン中の可能性があります) に関するできるだけ多くの情報を含む zip ファイルを作成して、事後法医学分析を可能にしたい状況があります。現在 Java 5 にデプロイしていますが、Java 6 の機能も興味深いものです。

これまでのところ、私は考えました：

• プログラムで生成されたスレッド ダンプ。これは、Java 6 でうまく機能するようです。
• 過去 X 分間に記録されたログ イベント。現在、logback または java.util.logging を使用しています。
• 一部のシリアル化されたオブジェクト。
• 外部環境 - すべてのシステム プロパティ。

JVM 情報で他に役立つものはありますか?

一般的な方法でコール スタックを調べて引数を確認することは可能でしょうか? (または、これには JVMTI または同等のものが必要ですか)。これは IBM JVM であるため、jvisualvm と Attach API は使用できません。

x64 マシンで実行されたプロセスからの 32 ビット プロセス ダンプをデバッグしようとしています。x64 ラップトップで x86 バージョンの windbg を実行しています。ここの推奨事項に従いましたが、まだこれが表示されます:

私が判断できる限り、mscordacwks_x86_x86_4.0.30319.237.dll正常にロードされましたが、それでもエラーが発生します。私は何が欠けていますか？

sosex をロードした後、次のエラーが表示されます。何か案は？ハング ダンプは 32 ビット マシンのもので、私のマシンは 64 ビットです。何かをインストールする必要がありますか?

recore ファイルを分析すると、私の gdb 7.0 はいくつかの警告を出力します。

関連しているかどうかはわかりませんが、バックトレースを取得できません:

OS アーキテクチャは SUN Solaris 10 SPARC です。

質問:

1. これらの警告の理由/原因は何ですか?
2. バックトレースを取得できないのはなぜですか?
3. これらの問題を解決するには？

WinDBG 6.12.0002.633 x86を使用しており、これを使用して、Windows Mobile6ARMV4Iアプリケーションから事後kdmpを表示しています。

コールスタックを分析しようとすると、不明な点がたくさんあります。分析では、* FAULTING_IP *セクションで、tcpstkモジュールに障害があることがわかります。（これについても記号があります。ただし、* STACK_TEXT *セクションでは、tcpstkアドレスは記号ではなく単なるアドレスとして表示されます。

また、* MODULE_NAME *セクションでは、障害のあるモジュールがtcpstkにあるとだけ言っていても、別の不明なものが表示されます。

!analyze -vコマンドの結果は次のとおりです。

コマンドに切り替えると、kp突然、コールスタックのその部分が表示されます。

!analyze -vコマンドが完全にデコードされたコールスタックを表示できないのはなぜですか？なぜこれほど多くの未知数が表示されるのですか？

WinDBG 6.12.0002.633 X86 を使用しています。

kコマンド ライン デバッガー CDB でおよびコマンドの WinDBG と同じ結果が表示されないという問題がありkLます。

WinDBG では、kコマンドはコールスタックのコード行を正しく表示し、kLコマンドはその情報を正しく取り除き、オフセットのみを表示します。

CDB では、 と の結果kはkL同じです。

kWinDBGのように CDB にコマンドのコード行を表示させるにはどうすればよいですか?

WinDBG X86 6.12.0002.633 で分析したい Windows Mobile 6.5 ARMV4I で実行されている C# .NET CF 3.5 アプリケーションによって生成された事後分析 kdmp があります。

アンマネージ コールスタックを取得することはできますが、.net アプリケーションを使用していること以上のことはわかりません。

大きなウィンドウでは、SOS を使用して を実行できますが!clrstack、mscorwks.dll は CF によって読み込まれません。

コンパクト フレームワークによって生成されたダンプ ファイルを分析するには、どうすればよいですか?

ありがとう、ポールH

マップ ファイルは次のようになります。

クラッシュ情報は次のようになります。

次のクラッシュでスタック ダンプを取得しようとしていますが、これは、スタックを切り捨ててリターンを行ったためにデータを実行することになったケースのように思えます。

次のような記事を読んだので、完全にはわかりません: Under the Hood 記事は、これがインポートされたメソッド名の領域であることを示しているようです

インポート ライブラリがインポートされた API に提供するデータは、名前がすべて .idata で始まるいくつかのセクション (たとえば、.idata$4、.idata$5、および .idata$6) に保持されます。.idata$5 セクションには、実行可能ファイルが読み込まれるときに、インポートされた関数のアドレスを含む単一の DWORD が含まれます。.idata$6 セクション (存在する場合) には、インポートされた関数の名前が含まれています。実行可能ファイルをメモリにロードするとき、Win32 ローダーはこの文字列を使用して、インポートされた関数で GetProcAddress を効果的に呼び出します。

スタックバックトレースがないと、ちょっと行き詰まります。このクラッシュを間違った方法で見ていますか?

私たちのパートナーの 1 人が、本当に恐ろしい「CodeMeter」を使用して DLL を暗号化するのに適していると判断したため、デバッグできないアプリでクラッシュが発生しました。CodeMeter のライセンスは、CodeMeter で暗号化された DLL を含むアプリをデバッグするすべての試みを防ぎ、未処理の例外フィルターから呼び出された MiniDumpWriteDump が失敗するようにさえ見えます (この手法は、この DLL が読み込まれなくても機能します)。クラッシュは、暗号化された DLL がプロセスに読み込まれたときにのみ発生します。

これをデバッグして、クラッシュしているのが暗号化された DLL かどうかを確認しようとして気が狂いそうになりました。クラッシュしている場合、パートナーに適切な診断情報を提供してこれを解決するにはどうすればよいでしょうか。

任意の提案 - おそらく、未処理の例外フィルターから呼び出すことができる手動のスタックおよびモジュール ウォーキング コードはありますか?

CodeMeter には、パートナーが暗号化されてライセンスが付与されたビルドを作成できるようにするビルド設定がありますが、デバッグをそれほど積極的に妨害することはありませんか?

疑問がある場合に備えて明確にするために、ライセンスをハッキングしようとしているのではなく、このクラッシュを診断するだけです。