Que faire avec "La version de SOS ne correspond pas à la version de CLR que vous déboguez" dans WinDbg?

Question

Je vais avoir un problème avec certains de mes applications. Elle est basée sur wcf une application qui s'exécute sous IIS6 dans Windows Server 2003 (x86):
Dans le Journal des Événements, je reçois une erreur "W3SVC-WP" source (EventID=2262):

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

Je suis en train de découvrir ce qui se passe. J'ai mis en place la création de vidage pour Orphelin Processus de travail, comme décrit dans cette KB. Lorsqu'un blocage est survenue d'un minidump est créé.
Puis-je prendre ce minidump pour essayer de comprendre ce qui s'est passé. Voici, je suis coincé.

- Je exécuter WinDbg x86, ouvrir mon dump et puis:

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

De quoi faire avec cette erreur - "La version de SOS ne correspond pas à la version du CLR de débogage" ?

La même erreur ("La version de SOS ne correspond pas à la version du CLR de débogage") j'obtiens quand j'ai ouvert le minidump dans VS2010.

J'ai lu ce post http://tech-thinker.com/Forums/tabid/62/forumid/12/postid/471/scope/posts/Default.aspxet essayé d'installer KB2518870. Il ne l'aide pas.

Answer 1

C'est ce qui a fonctionné pour moi:

Télécharger la Dll suivantes:

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

à partir de ce dossier sur la machine qui a généré le dump:

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

Exécutez la commande suivante. Le chemin d'accès à SOS.DLL devrait être sans guillemets, sans échappement chemin de séparateurs:

.charger chemin à téléchargé SOS.DLL

Je pense qu'un nouveau WinDbg session est nécessaire pour faire ce travail.

Answer 2

WinDbg ne sera pas en mesure d'utiliser le débogage de l'adaptateur mscordacwks.dll sauf si c'est la même version que celle de la machine originale. Vous pouvez contourner cette erreur en copiant cette DLL à partir de la machine cible qui a généré le dump de vos Outils de Débogage pour le répertoire Windows.

Nous debug .NET 2.0 applications avec WinDbg. Nous continuellement obtenir cette même erreur en ce qui concerne mscordacwks_x86_x86_2.0.50727.3615.dll. J'ai dû copier ce fichier à partir du serveur sur mon client et de le mettre dans le C:\Program Files\Outils de Débogage pour Windows (x86)\ dossier. WinDbg cessé de se plaindre après.

Si tout le reste échoue, vous pouvez essayer de débogage avec WinDbg sur le même serveur à partir duquel vous avez récupéré le fichier de vidage sur incident.

Answer 3

Le cœur du problème se trouve généralement avec une désadaptation mscordacwks.dll version (mscorwks.dll lui-même ne devrait pas être nécessaire si un vidage complet a été prise). En théorie, il devrait être accessible depuis le serveur de symbole - simplement exécuter .cordll -ve -u -l. Pour plus d'informations sur l' mscordacwks.dll voir l' Échec du chargement de données DLL d'accès, 0 x 80004005" – OU – Ce qui est mscordacwks.dll.

Malheureusement, certaines versions de l' mscordacwks.dll n'ont pas été indexés, ce qui signifie le ci-dessus ne fonctionne pas toujours. Dans de tels cas, vous pourriez essayer et obtenir la version correcte de la machine sur laquelle le cliché a été pris, comme Yocahi et Thomas mentionnés (par exemple, à partir d' C:\Windows\Microsoft.NET\Framework64\v4.0.30319). Une fois que vous l'obtenez, exécutez la commande suivante pour le charger: .cordll -u -ve -lp PathToFolderContainingMscorDAC. Bien sûr, cette machine est peut-être inaccessible, ou il peut avoir été corrigé depuis le temps que le cliché a été pris.

Heureusement, il existe un moyen d'extraire mscorwdacwks.dll à partir de la mise à jour réelle KO paquet (il se trouve dans l'une des cab fichiers à l'intérieur de l'auto exécutable à extraction - utiliser un outil tel que 7-Zip pour extraire l'). Il existe aussi des dépôts de la .NET des mises à jour (avec l'aimable autorisation de MME employé Doug Stewart), de sorte que vous pouvez les parcourir pour le numéro de build vous avez besoin:

• Version de l'histoire de la CLR 2.0
• Version de l'histoire de la CLR 4.0

Une fois que vous avez la bonne mscordacwks.dll, l' SOS.dll avertissement peut être ignoré dans la plupart des cas, le plus récent, SOS.dll version de travail la plupart du temps malgré l'avertissement. Toutefois, dans certains cas, la bonne SOS.dll version est nécessaire aussi bien (et en bonus, vous vous débarrasser de la satanés mises en garde). Dunken des liens vers un blog qui devraient être utiles à cet égard (essentiellement, vous avez besoin de placer le serveur de symbole dans l' _NT_SYMBOL_PATH variable d'environnement et d'exécuter !analyze –v sans chargement SOS.dll de la première il va charger la version correcte de lui-même). Si cela ne fonctionne pas, vous pouvez essayer de l'extraire SOS.dll de l'un des packages de mise à jour comme décrit ci-dessus. Ce site peut s'avérer plus facile à utiliser à cette fin, comme il est expressément index SOS.dll versions.

Enfin, pensez PsscorR2 (par .NET 2.0 et 3.5) et Psscor4 (par .NET 4.0). Psscor est un sur-ensemble de l' SOS.dll qui ne se plaignent pas incompatibles versions, aussi longtemps que vous êtes à l'aide de la version majeure. Il convient de noter qu'au fil du temps, il n'a pas été maintenu ainsi que SOS.dll, de sorte que celles-ci peuvent inclure des améliorations et des corrections de bugs absent de l'ancien. Au moment de l'écriture, il n'y avait pas Psscor version pour .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

Cela signifie que l'objectif de la machine qui fait le dump est en cours d'exécution sur la version CLR 4.0.30319.1.
Votre système est en cours d'exécution avec la version 4.0.30319.235.

C'est parce qu'il y avait une mise à jour de sécurité pour .Net 4.0, qui a changé le CLR et SOS fichiers. Et certains ordinateurs peuvent ne pas avoir cette mise à jour encore.

Voir: http://support.microsoft.com/kb/2572078

Cela peut entraîner certaines des lignes dans la pile à être un peu mal... Vous pouvez éviter l'erreur par l'obtention de la SOS.dll et CLR.dll et mscordacwks.dll et mscorwks.dll de la version originale et la charge de ceux qui, lorsque vous chargez le SOS.
Les fichiers originaux sont généralement sous : C:\Windows\Microsoft.NET\Framework\v4.0.30319
Dépend de la version de framework... et puis les copier dans un dossier spécifique.
Charger le bon de fichiers comme ceci:

.load C:\CurrectFiles\sos

Notez que c'est juste "sos" et pas sos.dll.

Answer 5

Vous pouvez charger automatiquement le bon fichier SOS.dll. Découvrez l'excellent article de blog de John Robbins http://wintellect.com/blogs/jrobbins/automatically-load-the-right-sos-for-the-minidump

Vous pouvez également vérifier avec .chain ce qui est déjà chargé. Dans certains cas, vous devez d'abord décharger (par exemple .unload sos ) les dll chargées incorrectement.