Korzystanie SOS w wysypisko z .NET 2 (mscorwks) i .NET 4 (CLR)

Question

Mam zrzut który obie wersje NET załadowane:

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 jestem niepewny, która wersja SOS używać. Oba ładują się bez problemów.

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

Jak mogę się dowiedzieć, która wersja najlepiej pasuje do mojej analizy? Czy zawsze będę potrzebował obu?

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

.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żywane polecenia:

~0s 
k 

=== UPDATE ===

.cordll w zasadzie jest w porządku. Domyślnie będzie korzystał z platformy .NET 4. To zachowanie można zmienić przez .cordll -I.

Otrzymałam obie wersje SOS, które pasują do danego komputera docelowego i ładowany przez ścieżki

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

Mam przeniesieni z WinDbg 6.2 do najnowszej 6.3. Wciąż nie lepiej.

Poprosiłem też 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 

Każda próba uruchomienia !threads zawsze skutkuje

Nie można żądać ThreadStore.

Każda próba uruchomienia !clrstack zawsze skutkuje

stanie chodzić zarządzanego stosu. Bieżący wątek prawdopodobnie nie jest zarządzanym wątkiem. Możesz uruchamiać wątki, aby uzyskać listę zarządzanych wątków w procesie.

=== UPDATE ===

Jak sugeruje Mario Hewardt kompleks scenariusz z określeniem pełną ścieżkę SOS można uniknąć tylko ładuje jedno rozszerzenie SOS do procesu (lub rozładunku w przypadku jednego są już załadowane) lub możemy użyć .setdll do zdefiniowania domyślnej wersji SOS, którą lubimy.

Nie poprawia to jednak analizy.

=== UPDATE ===

Próbowałem również rozładunek jednego z modułów .NET przez .reload /u w nadziei, że WinDbg/SOS nie byłby w konflikcie więcej, ale nadal nie ma szczęścia.

Answer 1

To bardzo brzydki problem, a afaj nie ma na to prostego rozwiązania. Głównym problemem jest to, że klient używa innej wersji CLR niż ty. Z pewnymi prawdopodobieństwami, biorąc pod uwagę szalenie różne numery wersji, że masz zainstalowany .NET 4.5, a klient korzysta z .NET 4.0. Ale łata bezpieczeństwa może być wystarczająca, aby spowodować niedopasowanie, które pojawiają się regularnie.

Afaik prawie utknąłeś, tworząc maszynę wirtualną lub maszynę, która używa dokładnie tej samej wersji, którą używa twój klient.

Funkcja CLR w procesie przy użyciu .NET 4 może w inny sposób wyjaśnić, w jaki sposób można uzyskać dwie wersje CLR w jednym procesie. Wersja v2.0 zazwyczaj służy do implementacji serwera COM. Coś, czego można uniknąć, dodając w zamian odniesienie do zespołu [ComVisible] .NET. Chociaż może to nie być twój kod, który to robi. Powodzenia z nim, nie jest to przyjemny problem.

Answer 2

Będziesz musiał użyć złożonych .cordll polecenia, aby załadować mscordacwks.dll jawnie która zostanie ujęta w tym blogu,

http://blogs.msdn.com/b/asiatech/archive/2010/09/10/how-to-load-the-specified-mscordacwks-dll-for-managed-debugging-when-multiple-net-runtime-are-loaded-in-one-process.aspx