x86 プロセス用に x64 マシンで作成されたハング ダンプ ファイルを調査するために、windbg を使用しようとしています。これは 4.0 x86 アプリケーションであるため、アンマネージ スタックを取得するには、次の手順を実行する必要がありました。
.loadby sos clr
.load wow64exts
!sw
kL
ただし、管理されたスタックを取得しようとするたびに!clrstack
、タイトルにエラーが表示されます。私は何が欠けていますか?
32 ビット ダンプを取得するには、C:\Windows\SysWOW64\taskmgr.exe にある 32 ビット タスク マネージャーを使用する必要があると思います。
他の人がすでに言っているように、これは 64 ビット アプリケーション (たとえば、デフォルトのタスク マネージャーなど) が 32 ビット プロセスのダンプ ファイルを作成することが原因である可能性があります。
GitHubの poizan42 の soswow64 WinDbg 拡張機能を使用して問題を解決できました。このブログ エントリで見つけました。このブログ エントリには、この問題に関する詳細情報も記載されています。
私は常にビット数マッチングの推奨事項に従ってきましたが、この記事に出会うまでその理由を正確に知りませんでした: http://blogs.msdn.com/b/dotnet/archive/2013/05/01/net-crash-dump -and-live-process-inspection.aspxには次のように記載されています。
「DAC には標準化されたインターフェイスがあり、マネージド ヒープなどの抽象化の状態に関する情報をデバッガーが取得するために使用されます。CLR バージョンとプロセスまたはクラッシュのアーキテクチャに一致する DAC を使用することが不可欠です。検査したいダンプ。」
と
「DAC はネイティブ DLL であり、ClrMD を使用するプログラムにロードする必要があることに注意してください。ダンプまたはライブ プロセスが 32 ビットの場合は、32 ビット バージョンの DAC を使用する必要があります。つまり、検査プログラムも 32 ビットである必要があります。64 ビット プロセスの場合も同様です。プログラムのプラットフォームがデバッグ対象のものと一致していることを確認してください。」
私にとってうまくいったオプションがもう1つあります。 - 64ビットプロセスのクラッシュダンプがありました。- それで、まず、ダンプが取られたマシン (C:\Windows\Microsoft.NET\Framework64\v4.0.30319) から SOS.dll と mscordacwks.dll が必要でした。- 2 つの msdn 記事に基づく ( http://msdn.microsoft.com/en-gb/library/windows/hardware/ff562263%28v=vs.85%29.aspx、http://msdn.microsoft.com/en -gb/library/windows/hardware/ff540665%28v=vs.85%29.aspx )、次の方法で CLR をロードしました。
.cordll -u -ve -I clr -lp <path to SOS.dll & mscordacwks.dll>
この後、 !threads が機能しました。32 ビットのクラッシュ ダンプにも同じことが当てはまると思います。