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

Ich habe ein problem mit meinen apps. Es ist ein wcf-basierte app läuft unter IIS6 in Windows Server 2003 (x86):
Im Ereignisprotokoll bekomme ich solch eine Fehlermeldung aus "W3SVC-WP" Quelle (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 Los ist. Ich habe dump erstellen für Orphan Arbeitsprozess, wie beschrieben, in diesem KB.
Wenn ein deadlock aufgetreten ein minidump erstellt wurde.
Dann nehme ich diese minidump, zu versuchen zu verstehen, was passiert ist. Hier bin ich stecken.

Lauf ich WinDbg x86, öffne meine 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 zu tun ist mit diesem Fehler - "Die version von SOS ist nicht mit der version der CLR, die Sie Debuggen" ?

Den gleichen Fehler ("Die version von SOS ist nicht mit der version der CLR, die Sie Debuggen") ich bin immer, wenn ich öffne die minidump in VS2010.

Ich diesen Beitrag gelesen haben - http://tech-thinker.com/Forums/tabid/62/forumid/12/postid/471/scope/posts/Default.aspxund habe versucht die Installation KB2518870. Es hilft nicht.

InformationsquelleAutor der Frage Shrike | 2011-09-15

23

WinDbg nicht in der Lage, verwenden Sie die debugging-adapter mscordacwks.dll es sei denn, es ist die gleiche version wie die von der original-Maschine. Sie können dies umgehen, Fehler durch kopieren dieser DLL aus der Ziel-Maschine, die generiert die Müllkippe zu der Debugging Tools für Windows-Verzeichnis.

Wir Debuggen .NET-2.0-Anwendungen mit WinDbg. Wir würden ständig die gleiche Fehler bzgl. mscordacwks_x86_x86_2.0.50727.3615.dll. Ich musste kopieren Sie diese Datei vom server auf meinen client und steckte es in die C:\Program Files\Debugging Tools for Windows (x86)\ Ordner. WinDbg beendet beschweren, dass nach.

Wenn alle Stricke reißen, können Sie versuchen, Debuggen mit WinDbg auf dem gleichen server, von dem Sie abgerufen die crash-dump.

InformationsquelleAutor der Antwort Paul Williams
42

Dies ist was für mich gearbeitet:

Laden Sie die folgenden DLLs:
- clr.dll
- mscordacwks.dll
- SOS.dll
aus diesem Ordner auf der Maschine generiert, dass der dump:

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

Den folgenden Befehl ausführen. Der Pfad zu SOS.DLL werden sollte, ohne Anführungszeichen, ohne Umschreibung Pfad-Trennzeichen:

.laden Pfad heruntergeladen werden SOS.DLL

Ich glaube, dass eine neue WinDbg Sitzung ist erforderlich für diese zu arbeiten.

InformationsquelleAutor der Antwort Thomas Bratt
16

Den Kern des Problems liegt in der Regel bei einer nicht übereinstimmenden mscordacwks.dll version (mscorwks.dll selbst sollte nicht erforderlich sein, wenn eine vollständige dump genommen wurde). In der Theorie, es sollte erreichbar sein aus dem symbol-server - starten Sie einfach .cordll -ve -u -l. Für weitere Informationen über mscordacwks.dll siehe Failed to load data access DLL, 0 x 80004005" – ODER – Was mscordacwks.dll.

Leider einige Versionen von mscordacwks.dll wurden nicht indiziert, was bedeutet das oben funktioniert nicht immer. In solchen Fällen könnten Sie versuchen, und Holen Sie sich die richtige version aus der Maschine, auf dem der dump gemacht wurde, als Yocahi und Thomas erwähnt (z.B. von C:\Windows\Microsoft.NET\Framework64\v4.0.30319). Sobald Sie es erhalten, geben Sie den folgenden Befehl, um es zu laden: .cordll -u -ve -lp PathToFolderContainingMscorDAC. Natürlich, die Maschine kann nicht zugegriffen werden, oder es kann gepatcht haben seit der Zeit der dump gemacht wurde.

Glücklicherweise gibt es eine Verfahren zum extrahieren mscorwdacwks.dll von den eigentlichen update-Paket KB (es befindet sich in einem der cab Dateien in dem selbstextrahierenden, ausführbaren Datei mit einem tool wie 7-Zipum es zu entpacken). Es gibt auch repositories .NET-updates (mit freundlicher Genehmigung von MS-Mitarbeiter Doug Stewart), so dass Sie durchsuchen können Sie für die genaue build-Nummer, die Sie benötigen:
- Version Geschichte von der CLR 2.0
- Version Geschichte von der CLR 4.0
Sobald Sie die richtige mscordacwks.dlldie SOS.dll Warnung kann ignoriert werden, in den meisten Fällen, wie die jüngsten SOS.dll version funktionieren würde, die meisten der Zeit, trotz der Warnung. Jedoch in einigen Fällen die richtige SOS.dll version benötigt wird (und als bonus, Sie loszuwerden, die lästigen Warnungen). Dunken links zu blog-postdas sollte hilfreich sein, in dieser Hinsicht (im Grunde müssen Sie um das symbol zu platzieren-server in der _NT_SYMBOL_PATH Umgebungsvariablen und ausführen !analyze –v ohne Belastung SOS.dll ersten - es wird laden Sie die richtige version selbst). Wenn das nicht funktioniert, könnten Sie versuchen, zu extrahieren SOS.dll aus einer der der update-Pakete, wie oben beschrieben. Diese Website beweisen können, einfacher zu benutzen für diesen Zweck, da Sie speziell Indizes SOS.dll Versionen.

Schließlich halte PsscorR2 (für .NET 2.0-3.5) und Psscor4 (für .NET 4.0). Psscor ist eine Obermenge von SOS.dll die nicht beschweren sich über nicht übereinstimmende Versionen, also solange du mit dem entsprechenden major-version. Es sollte angemerkt werden, dass im Laufe der Zeit, es war nicht immer gepflegt wie auch SOS.dllso kann letzterer zählen Verbesserungen und bug-fixes, die nicht aus der ehemaligen. Zum Zeitpunkt des Schreibens gab es keine Psscor version für .NET 4.5.

InformationsquelleAutor der Antwort Ohad Schneider
7
```
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 die Ziel-Maschine, die aus der dump ausgeführt wird, auf CLR-version 4.0.30319.1.

Dein system läuft mit version 4.0.30319.235.

Dies ist, weil es ein Sicherheitsupdate war .Net 4.0, die sich auf die CLR und SOS - Dateien. Und einige Computer möglicherweise nicht über dieses update noch.

Finden Sie unter: http://support.microsoft.com/kb/2572078

Dies kann dazu führen, dass einige der Linien in den stack ein wenig falsch...
Sie können den Fehler vermeiden, indem er die SOS.dll und CLR.dll und mscordacwks.dll und mscorwks.dll der ursprünglichen version, und laden diese beim laden der SOS.

Die original-Dateien sind normalerweise unter : C:\Windows\Microsoft.NET\Framework\v4.0.30319

Hängt von der framework-version... und dann kopieren Sie Sie auf einen bestimmten Ordner.

Laden Sie die richtigen Dateien wie dieses:
```
.load C:\CurrectFiles\sos
```
Beachten Sie, dass es nur "sos" und nicht sos.dll.

InformationsquelleAutor der Antwort Yochai Timmer
2

Können Sie automatisch laden Sie die richtige SOS.dll. Check-out John Robbins große blog-post http://wintellect.com/blogs/jrobbins/automatically-load-the-right-sos-for-the-minidump

Könnten Sie auch prüfen, mit .chain was bereits geladen ist. In einigen Fällen müssen Sie zu entladen (z.B. .unload sos) die falsch geladenen dlls erste.

InformationsquelleAutor der Antwort Dunken
1

Kurz gesagt, tun Sie den folgenden:
1. Die CLR-version bilden die dump
2. Finden und downloaden Sie entsprechende Microsoft-patch
3. Extrahieren Sie die sos.dll und mscordacwks.dll aus dem patch
4. Verwenden
Unten ist ein Beispiel:

1. Nach dem laden einen crash-dump bekomme ich die version die ich brauche:
```
>lm vm clr
```
es gibt mir
```
File version:     4.0.30319.18051
```
2. Ich google nach MS-update enthält diese version:

sos.dll 4.0.30319.18051

In diesem Fall gibt google eine MS-KB-Seite mit einem download-link.
Ich in der Regel laden Sie die x64-version, weil es enthält sowohl x86-und x64-dlls, also ich habe Windows8-RT-KB2833958-x64.msu jetzt.

Hinweis: manchmal ist es schwierig, um die patch benötigt, aber nicht in diesem Beispiel.

3. Mit FAR Datei-manager ich extrahieren von Cab-Archiv von dieser MSU:

Windows8-RT-KB2833958-x64.cab

Hinweis: Manchmal gibt es mehrere Schränke im inneren, so dass Sie brauchen, um zu überprüfen, die eine enthält sos.dll.

Hinweis: Manchmal patches verteilt sind .EXE, so müssen Sie zuerst zu extrahieren, MSU-oder MSP-Dateien (ich mache es mit FAR), und extrahieren Sie dann Schränke aus.

4. Manchmal werden Dateien aus Cab kann extrahiert werden, indem man WEIT, aber manchmal haben Sie sehr unterschiedliche Struktur und ich benutze Expand.exe von WinAIK. WinAIK ist 1,7 Gb ISO -, aber Sie brauchen nur einen kleinen Teil.
Ich benutze die folgende BAT-Datei
```
mkdir Extracted
..\winaik_amd64\servicing\Expand.exe "%1" -F:sos.dll "Extracted"
..\winaik_amd64\servicing\Expand.exe "%1" -F:mscordacwks.dll "Extracted"
```
Dieser Befehl extrahiert alle Versionen von bestimmten dlls, die jeweils innerhalb Ihrer eigenen dir.
Manchmal gibt es 2 Versionen von mscordacwks.dll und sos.dll. Ich glaube, das ist, weil der GRD/LDR(QFE) Mitarbeiter.
In unserem Beispiel gibt es 4.0.30319.18051 und 4.0.30319.19079.
Überprüfen Sie die Eigenschaften der Datei mit dem Windows Explorer.

5. Benennen Sie die Dateien entsprechend: mscordacwks.dll muss genannt werden, da mscordacwks_%arch%_%arch%_%version%.dll und platziert in der Nähe der sos.dll

So
mscordacwks.dll (4.0.30319.18051) geht mscordacwks_AMD64_AMD64_4.0.30319.18051.dll

(x86-version umbenennen mscordacwks_x86_x86_4.0.30319.18051.dll)

sos.dll vielleicht bleiben so intakt ist, aber ich es umbenennen sos.4.0.30319.18051.dll

Tun das gleiche für 4.0.30319.19079 version (für möglichen zukünftigen Bedarf)

6. Kopieren Sie diese Dateien auf 'C:\SOS\' - Ordner, die enthält eine Menge von sos.4.x.x.x.dll und mscordacwks_AMD64_AMD64_4.x.x.x.dll

7. Verwenden Sie es mit
```
.load C:\SOS\sos.4.0.30319.18051.dll
```
Hinweis: Manchmal für .Net 4.5, die Sie benötigen, um zusätzliche '0', um mscordacwks-version
mscordacwks_AMD64_AMD64_4.6.1055.00.dll statt mscordacwks_AMD64_AMD64_4.6.1055.0.dll. Ich nicht tiefer Graben, aber da konnte Griff dies in einem kleinen Zeitrahmen.

BTW, WinDbg wird sagen, wenn mscordacwks nicht gefunden werden kann und wird, geben Sie die version (die haben Doppel - '0' am Ende).

InformationsquelleAutor der Antwort mistika

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.