Was tun mit "Die Version von SOS stimmt nicht mit der Version von CLR überein, die Sie debuggen" in WinDbg?

Question

Ich habe ein Problem mit einigen meiner Anwendungen. Es ist eine wcf-basierte Anwendung, die unter IIS6 in Windows 2003 Server (x86) läuft:
Im Ereignisprotokoll erhalte ich einen solchen Fehler von der Quelle "W3SVC-WP" (EventID=2262):

ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

Ich versuche herauszufinden, was hier los ist. Ich habe einen Dump für den Orphan Worker Process erstellt, wie in dieser Anleitung beschrieben KB . Wenn eine Blockierung auftritt, wird ein Minidump erstellt.
Dann nehme ich diesen Minidump, um zu versuchen zu verstehen, was passiert ist. Hier stecke ich fest.

Ich starte WinDbg x86, öffne meinen Dump und dann:

0:037> .loadby sos clr
0:037> .sympath SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
0:037> !clrstack
The version of SOS does not match the version of CLR you are debugging.  Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.1
SOS Version: 4.0.30319.235
CLRDLL: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.235 f:8 doesn't match desired version 4.0.30319.01 f:8
CLRDLL: Loaded DLL c:\temp\symbols\mscordacwks_x86_x86_4.0.30319.01.dll\4BA1D9EF66f000\mscordacwks_x86_x86_4.0.30319.01.dll
OS Thread Id: 0x690 (37)
Unable to walk the managed stack. The current thread is likely not a managed thread.
You can run !threads to get a list of managed threads in the process

Was ist bei diesem Fehler zu tun? - "Die Version von SOS stimmt nicht mit der Version von CLR überein, die Sie debuggen" ?

Derselbe Fehler ("Die Version von SOS stimmt nicht mit der Version von CLR überein, die Sie debuggen"), den ich erhalte, wenn ich den Minidump in VS2010 öffne.

Ich habe diesen Beitrag gelesen - http://tech-thinker.com/Forums/tabid/62/forumid/12/postid/471/scope/posts/Default.aspx und versuchte die Installation von KB2518870 . Das hilft nicht.

Answer 1

Das hat bei mir funktioniert:

Laden Sie die folgenden DLLs herunter:

• clr.dll
• mscordacwks.dll
• SOS.dll

aus diesem Ordner auf dem Rechner, der den Dump erzeugt hat:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319

Führen Sie den folgenden Befehl aus. Der Pfad zu SOS.DLL sollte ohne Anführungszeichen und ohne Pfadbegrenzer angegeben werden:

.laden Pfad zur heruntergeladenen SOS.DLL

Ich denke, dass eine neue WinDbg-Sitzung erforderlich ist, damit dies funktioniert.

Answer 2

WinDbg ist nicht in der Lage, den Debugging-Adapter mscordacwks.dll zu verwenden, es sei denn, es handelt sich um dieselbe Version wie auf dem ursprünglichen Rechner. Sie können diesen Fehler umgehen, indem Sie diese DLL von dem Zielrechner, der den Dump erzeugt hat, in Ihr Verzeichnis Debugging Tools for Windows kopieren.

Wir debuggen .NET 2.0-Anwendungen mit WinDbg. Wir erhielten immer wieder die gleiche Fehlermeldung bezüglich mscordacwks_x86_x86_2.0.50727.3615.dll. Ich musste diese Datei vom Server auf meinen Client kopieren und sie in das Verzeichnis C:\Program Dateien \Debugging Tools für Windows (x86)\ Ordner. Danach hat WinDbg aufgehört, sich zu beschweren.

Wenn alles andere fehlschlägt, können Sie versuchen, die Fehlersuche mit WinDbg auf demselben Server durchzuführen, von dem Sie den Absturzdump abgerufen haben.

Answer 3

Das Kernproblem liegt in der Regel in einer fehlenden Abstimmung zwischen mscordacwks.dll Version ( mscorwks.dll selbst sollte nicht erforderlich sein, wenn ein vollständiger Dump durchgeführt wurde). Theoretisch sollte es vom Symbolserver aus erreichbar sein - führen Sie einfach .cordll -ve -u -l . Für weitere Informationen über mscordacwks.dll siehe Datenzugriffs-DLL konnte nicht geladen werden, 0x80004005" - OR - Was ist mscordacwks.dll .

Leider sind einige Versionen von mscordacwks.dll sind nicht indiziert, was bedeutet, dass die oben genannten Maßnahmen nicht immer funktionieren. In solchen Fällen können Sie versuchen, die korrekte Version von dem Rechner zu bekommen, auf dem der Speicherauszug gemacht wurde, wie Yocahi y Thomas erwähnt (z.B. von C:\Windows\Microsoft.NET\Framework64\v4.0.30319 ). Sobald Sie sie erhalten haben, geben Sie den folgenden Befehl ein, um sie zu laden: .cordll -u -ve -lp PathToFolderContainingMscorDAC . Natürlich kann es sein, dass der Rechner nicht mehr zugänglich ist oder dass er seit der Erstellung des Dumps gepatcht wurde.

Zum Glück gibt es eine Extrahieren der Datei mscorwdacwks.dll aus dem eigentlichen Update-KB-Paket (sie befindet sich in einem der cab Dateien innerhalb der selbst extrahierenden ausführbaren Datei - verwenden Sie ein Tool wie 7-Zip um sie zu extrahieren). Es gibt auch Repositories für .NET-Updates (mit freundlicher Genehmigung des MS-Mitarbeiters Doug Stewart), die Sie nach der genauen Build-Nummer durchsuchen können, die Sie benötigen:

• Versionsgeschichte der CLR 2.0
• Versionsgeschichte der CLR 4.0

Sobald Sie die richtige mscordacwks.dll die SOS.dll Warnung konnte in den meisten Fällen ignoriert werden, da die letzte SOS.dll Version funktionierte trotz der Warnung meistens. In einigen Fällen wurde jedoch die korrekte SOS.dll Version ist ebenfalls erforderlich (und als Bonus werden Sie die lästigen Warnungen los). Dunken Links zu einer Blogbeitrag die in dieser Hinsicht hilfreich sein sollten (im Grunde müssen Sie den Symbolserver in der _NT_SYMBOL_PATH Umgebungsvariable und führen Sie !analyze –v ohne Belastung SOS.dll zuerst - er lädt die richtige Version selbst). Wenn das nicht funktioniert, können Sie versuchen, die folgende Datei zu extrahieren SOS.dll aus einem der Update-Pakete wie oben beschrieben. Diese Seite kann sich für diesen Zweck als einfacher erweisen, da es speziell Indizes SOS.dll Versionen.

Schließlich sollten Sie PsscorR2 (für .NET 2.0-3.5) und Psscor4 (für .NET 4.0). Psscor ist eine Obermenge von SOS.dll die sich nicht über nicht übereinstimmende Versionen beschwert, solange Sie die entsprechende Hauptversion verwenden. Es sollte beachtet werden, dass es im Laufe der Zeit nicht so gut gepflegt wurde wie SOS.dll Daher kann die letztere Verbesserungen und Fehlerbehebungen enthalten, die in der ersteren nicht enthalten sind. Zum Zeitpunkt der Erstellung dieses Berichts gab es noch keine Psscor Version für .NET 4.5.

Answer 4

The version of SOS does not match the version of CLR you are debugging.  Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.1
SOS Version: 4.0.30319.235

Dies bedeutet, dass der Zielcomputer, auf dem der Dump erstellt wurde, mit der CLR-Version 4.0.30319.1 .
Ihr System läuft mit der Version 4.0.30319.235 .

Das liegt daran, dass es ein Sicherheitsupdate für .Net 4.0 gab, das die CLR y SOS Dateien. Und einige Computer verfügen möglicherweise noch nicht über dieses Update.

ご覧ください： http://support.microsoft.com/kb/2572078

Dies kann dazu führen, dass einige der Zeilen im Stapel etwas falsch sind... Sie können den Fehler vermeiden, indem Sie die SOS.dll y CLR.dll y mscordacwks.dll y mscorwks.dll der Originalversion und laden diese, wenn Sie SOS laden.
Die Originaldateien sind in der Regel unter : C:\Windows\Microsoft.NET\Framework\v4.0.30319
Hängt von der Framework-Version ab... und kopieren Sie sie dann in einen bestimmten Ordner.
Laden Sie die richtigen Dateien wie folgt:

.load C:\CurrectFiles\sos

Beachten Sie, dass es nur "sos" und nicht sos.dll heißt.

Answer 5

Sie können automatisch die richtige SOS.dll laden. Lesen Sie John Robbins' großartigen Blogbeitrag http://wintellect.com/blogs/jrobbins/automatically-load-the-right-sos-for-the-minidump

Sie können sich auch an folgende Stellen wenden .chain was bereits geladen ist. In manchen Fällen müssen Sie entladen (z. B. .unload sos ) die falsch geladenen DLLs zuerst.