：.NET 4（CLR）私は両方の.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
=== === UPDATE
.cordllはokです。デフォルトでは、.NET 4フレームワークを使用します。この動作は.cordll -Iによって変更できます。
私は、ターゲットコンピュータのものと一致SOSの両方のバージョンを取得し、パス
.load C:\SOS\4.0.30319.296\SOS.dll
によってロードされてきた私は、最新の6.3にWinDbgを6.2からアップグレードしました。まだ良くはありません。
私はまた、.cordll -Iを提案したSOSEXの著者Steve Johnsonに尋ねましたが、これはダンプでもモジュール名でもベースアドレスでも機能しません。
.cordll -I clr
.cordll -I 65490000
!threadsを実行しようとすると、常に
の結果はThreadStoreを要求するために失敗しました。
!clrstackを実行するための
しようとすると、常に
管理スタックを歩くことができないことになります。現在のスレッドは、管理スレッドではない可能性があります。 ！threadsを実行すると、プロセス内の管理対象スレッドのリストを取得できます。
=== UPDATE ===
マリオ・ヘワートによって示唆されるように、完全なSOSのパスを指定すると、複雑なシナリオは、プロセスに1つのSOS拡張をロード（またはケースの一方をアンロードすることによって回避することができますそれらが既にロードされている場合）、または.setdllを使用して、好きなデフォルトのSOSバージョンを定義することができます。
しかし、これは分析を改善しません。
=== === UPDATE
私もWinDbgの/ SOSが、それ以上競合しないだろうことを期待して.reload /uで.NETモジュールのいずれかをアンロードしようとしている
、まだ運。
、このブログの記事で覆われている、明示的にフォーMscordacwks.dllをロードするために、複雑な
.cordllコマンドを使用する必要があります。この問題は、プラグインのアーキテクチャによって発生します。アプリケーション自体は.NET2なので、当初は.NETが使用されていました。プラグインは.NET4を使用するので、これもロードされます。 –