Mam zrzut, który ma załadowane obie wersje .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) 

Teraz nie jestem pewien, której wersji SOS użyć. Oba ładują się bez problemów.

0:000> .loadby sos mscorwks
0:000> .loadby sos clr

Jak dowiem się, która wersja najlepiej sprawdza się w mojej analizie? Czy też zawsze będę potrzebował obu?

Czy .cordll -ve -u -l jest w tym przypadku niezawodny?

.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

Wątek 0 pokazuje mscorwks. Użyte polecenia:

~0s
k

=== UPDATE ===

.cordll w zasadzie jest w porządku. Domyślnie użyje struktury .NET 4. To zachowanie można zmienić.cordll -I.

Otrzymałem obie wersje SOS, które pasują do komputera docelowego i są ładowane ścieżką

.load C:\SOS\4.0.30319.296\SOS.dll

Zaktualizowałem WinDbg 6.2 do najnowszego 6.3. Wciąż nie lepiej.

Zapytałem również Steve'a Johnsona, autora SOSEX, który zasugerował.cordll -I, ale to również nie działa w moim zrzucie, ani z nazwą modułu, ani z adresem bazowym.

.cordll -I clr
.cordll -I 65490000

Wszelkie próby uruchomienia!threads zawsze skutkuje

Nie można zażądać magazynu wątków.

Wszelkie próby uruchomienia!clrstack zawsze skutkuje

Nie można przejść zarządzanego stosu. Bieżący wątek prawdopodobnie nie jest wątkiem zarządzanym. Możesz uruchamiać! Wątki, aby uzyskać listę zarządzanych wątków w procesie.

=== UPDATE ===

Jak sugeruje Mario Hewardt, złożonego scenariusza z określeniem pełnej ścieżki SOS można uniknąć, ładując tylko jedno rozszerzenie SOS do procesu (lub rozładowując je w przypadku, gdy są już załadowane) lub możemy użyć.setdll zdefiniować domyślną wersję SOS, którą lubimy.

Nie poprawia to jednak analizy.

=== UPDATE ===

Próbowałem także rozładować jeden z modułów .NET.reload /u w nadziei, że WinDbg / SOS nie będzie już w konflikcie, ale nadal nie będzie szczęścia.