Ich habe einen Speicherauszug, auf dem beide .NET-Versionen geladen sind:

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) 

Jetzt bin ich mir nicht sicher, welche Version von SOS ich verwenden soll. Beide werden ohne Probleme geladen.

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

Wie finde ich heraus, welche Version für meine Analyse am besten geeignet ist? Oder brauche ich immer beides?

Ist .cordll -ve -u -l in diesem Fall zuverlässig?

.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

Thread 0 zeigt mscorwks. Verwendete Befehle:

~0s
k

=== UPDATE ===

.cordll im prinzip ist das ok Standardmäßig wird .NET 4 Framework verwendet. Dieses Verhalten kann durch geändert werden.cordll -I.

Ich habe beide Versionen von SOS erhalten, die mit denen des Zielcomputers übereinstimmen und über den Pfad geladen werden

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

Ich habe von WinDbg 6.2 auf die neueste Version 6.3 aktualisiert. Immer noch nicht besser.

Ich habe auch Steve Johnson, den Autor von SOSEX, gefragt.cordll -I, aber das funktioniert auch nicht in meinem dump, weder mit modulname noch mit basisadresse.

.cordll -I clr
.cordll -I 65490000

Jeder Versuch zu rennen!threads ergibt immer

Fehler beim Anfordern von ThreadStore.

Jeder Versuch zu rennen!clrstack ergibt immer

Der verwaltete Stapel kann nicht ausgeführt werden. Der aktuelle Thread ist wahrscheinlich kein verwalteter Thread. Sie können! Threads ausführen, um eine Liste der verwalteten Threads zu erhalten.

=== UPDATE ===

Wie von Mario Hewardt vorgeschlagen, kann das komplexe Szenario mit der Angabe des vollständigen SOS-Pfads vermieden werden, indem nur eine SOS-Erweiterung in den Prozess geladen wird (oder eine, falls sie bereits geladen ist, entladen wird), oder wir können es verwenden.setdll um die Standard-SOS-Version zu definieren, die wir mögen.

Dies verbessert jedoch die Analyse nicht.

=== UPDATE ===

Ich habe auch versucht, eines der .NET-Module von zu entladen.reload /u in der Hoffnung, dass WinDbg / SOS nicht mehr in einem Konflikt stecken würde, aber immer noch kein Glück.