web-dev-qa-db-ja.com

SOSは現在のターゲットアーキテクチャをサポートしていません

私はwindbgを使用して、x86プロセス用にx64マシンで作成されたハングダンプファイルを調査しようとしています。これは4.0x86アプリケーションであるため、アンマネージスタックを取得するには、次のことを行う必要がありました。

.loadby sos clr
.load wow64exts
!sw
kL

ただし、!clrstackを介してマネージスタックを取得しようとすると、タイトルにエラーが表示されます。何が足りないのですか?

25
Justin Pihony

32ビットダンプを取得するには、C:\ Windows\SysWOW64\taskmgr.exeにある32ビットタスクマネージャーを使用する必要があると思います。

詳細はこちら: http://blogs.msdn.com/b/tess/archive/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64- machine.aspx

27
trydis

他の人がすでに言っているように、これは64ビットアプリケーション(たとえば、デフォルトのタスクマネージャーなど)が32ビットプロセスのダンプファイルを作成することによって引き起こされる可能性があります。

GitHubのpoizan42 からsoswow64WinDbg拡張機能を使用して問題を解決できました。 このブログエントリ で見つけました。これは、この問題に関するより詳細な情報も提供します。

18
Tamas Kozma

私は常にビットネスマッチングの推奨事項に従いましたが、この記事に出くわすまで、その理由を正確に知ることはできませんでした: 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ビットプロセスにも当てはまります。プログラムのプラットフォームがデバッグしているものと一致していることを確認してください。」

6
Marc Sherman

私のために働いたもう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.aspxhttp://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ビットのクラッシュダンプにも同じことが当てはまると思います。

3
nkanani