SOS Verwendung in einer Müllhalde mit .NET 2 (mscorwks) und 4 .NET (CLR)

Question

Ich habe einen Dump, die sowohl .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, welche Version von SOS ich unsicher bin benutzen. Beide laden ohne Probleme.

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

Wie würde ich herausfinden, welche Version für meine Analyse am besten geeignet ist? Oder werde ich immer beides brauchen?

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. Befehle verwendet:

~0s 
k 

=== UPDATE ===

.cordll grundsätzlich ok. Standardmäßig wird .NET 4 Framework verwendet. Dieses Verhalten kann durch .cordll -I geändert werden.

Ich habe beide Versionen von SOS erhalten, die durch Pfad

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

Ich Upgrade von WinDbg 6.2 bis spätestens 6.3, dass der Zielcomputer und geladen entsprechen. Immer noch nicht besser.

Ich habe auch Steve Johnson, der Autor von SOSEX gefragt, der .cordll -I vorgeschlagen hat, aber das funktioniert auch nicht in meinem Dump, weder mit Modulnamen noch mit Basisadresse.

.cordll -I clr 
.cordll -I 65490000 

Jeder Versuch !threads immer zu laufen ergibt

fehlgeschlagen ThreadStor beantragen.

Jeder Versuch !clrstack immer zu laufen ergibt

konnte nicht verwalteten Stapel laufen. Der aktuelle Thread ist wahrscheinlich kein verwalteter Thread. Sie können! -Threads ausführen, um eine Liste verwalteter Threads im Prozess zu erhalten.

=== UPDATE ===

Wie von Mario Hewardt deutet, kann der Komplex Szenario den vollständigen Pfad SOS mit Angabe von nur Laden eines SOS-Erweiterung in den Prozeß (oder im Falle einer Entladung vermieden werden, sie sind bereits geladen) oder wir können .setdll verwenden, um die Standard-SOS-Version zu definieren, die wir mögen.

Dies verbessert jedoch nicht die Analyse.

=== === UPDATE

ich auch versucht haben, durch .reload /u in der Hoffnung, eine der .NET Module Entladen dass WinDbg/SOS nicht mehr in einem Konflikt sein würde, aber noch kein Glück.

Answer 1

Dies ist ein sehr hässliches Problem und afaik gibt es keine einfache Lösung dafür. Das Kernproblem besteht darin, dass Ihr Kunde eine andere Version der CLR verwendet als Sie. Angesichts der vielen verschiedenen Revisionsnummern ist bei einigen Quoten .NET 4.5 installiert und der Kunde verwendet .NET 4.0. Aber nur ein Sicherheitspatch kann genug sein, um eine Diskrepanz zu verursachen, sie sind in letzter Zeit stetig angestiegen.

Afaik Sie sind ziemlich stecken fest, eine VM oder Maschine, die die genau gleiche Revision wie Ihre Kunden verwendet.

Die In-Process-Side-by-Side-CLR-Funktion in .NET 4 kann sonst erklären, wie Sie zwei CLR-Versionen in einem Prozess erhalten könnten. Die v2.0-Version wäre normalerweise da, um einen COM-Server zu implementieren. Etwas, das Sie vermeiden, indem Sie stattdessen einen Verweis auf die [ComVisible] .NET-Assembly hinzufügen. Auch wenn es nicht Ihr Code ist, der dies tut. Viel Glück damit, kein schönes Problem zu haben.

Answer 2

Sie haben komplexe .cordll Befehle verwenden, um die Mscordacwks.dll explizit zu laden, die in diesem Blog-Eintrag abgedeckt ist,

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