両方の .NET バージョンがロードされたダンプがあります。
0:000> lm m clr
start end module name
65490000 65aff000 clr (deferred)
0:000> lm m mscorwks
start end module name
6a980000 6af2c000 mscorwks (deferred)
現在、どのバージョンの SOS を使用すればよいかわかりません。どちらも問題なくロードされます。
0:000> .loadby sos mscorwks
0:000> .loadby sos clr
分析に最適なバージョンを見つけるにはどうすればよいですか? それとも常に両方が必要ですか？
この場合、.cordll -ve -u -l は信頼できますか?
.symfix c:\symbols
.cordll -ve -u -l
CLRDLL: C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.18047 f:8
doesn't match desired version 4.0.30319.296 f:8
CLRDLL: Loaded DLL c:\symbols\mscordacwks_x86_x86_4.0.30319.296.dll\50484AA966f000\mscordacwks_x86_x86_4.0.30319.296.dll
CLR DLL status: Loaded DLL c:\symbols\mscordacwks_x86_x86_4.0.30319.296.dll\50484AA966f000\mscordacwks_x86_x86_4.0.30319.296.dll
スレッド 0 は mscorwks を示しています。使用するコマンド:
~0s
k
===更新===
.cordll原則OKです。デフォルトでは、.NET 4 フレームワークが使用されます。この動作は、によって変更できます.cordll -I。
ターゲット コンピューターのバージョンと一致し、パスで読み込まれた SOS の両方のバージョンを取得しました。
.load C:\SOS\4.0.30319.296\SOS.dll
WinDbg 6.2 から最新の 6.3 にアップグレードしました。まだ良くない。
を提案した SOSEX の作成者である Steve Johnson にも尋ねました.cordll -Iが、これもモジュール名でもベースアドレスでも、私のダンプでは機能しません。
.cordll -I clr
.cordll -I 65490000
実行しようとすると、!threads常に次の結果になります
ThreadStore の要求に失敗しました。
実行しようとすると、!clrstack常に次の結果になります
マネージド スタックをウォークできません。現在のスレッドはマネージド スレッドではない可能性があります。!threads を実行して、プロセス内のマネージド スレッドの一覧を取得できます。
===更新===
Mario Hewardt によって提案されているように、完全な SOS パスを指定する複雑なシナリオは、1 つの SOS 拡張機能をプロセスにロードする (または既にロードされている場合はアンロードする) だけで回避できます。または、.setdll好きなデフォルトの SOS バージョンを定義するために使用できます。 .
ただし、これによって分析が改善されるわけではありません。
===更新===
また、WinDbg/SOS が競合しないことを期待して、.NET モジュールの 1 つをアンロードしようとし.reload /uましたが、それでもうまくいきません。