web-dev-qa-db-fra.com

WinDbg x64: Impossible de déborder sur un incident - échec du chargement de l'accès aux données DLL

J'ai attaché WinDbg à un processus en cours d'exécution et le processus s'est bloqué (j'ai une question distincte à propos de ce cas). Une fois le programme bloqué, WinDbg s’est arrêté et m’a permis de déboguer le programme. J'ai pris un vidage mémoire sur incident pour une enquête plus poussée avec la commande ".dump/ma".

Le programme a été compilé en tant que "Tout processeur" et j'ai utilisé WinDbg x64 pour effectuer le vidage. Maintenant, j'ouvre à nouveau WinDbg x64 sur le même ordinateur et ouvre le fichier de sauvegarde sur incident. Voici ce qu'il dit:

Loading Dump File [C:\crashdump.dmp]
User Mini Dump File with Full Memory: Only application data is available

Symbol search path is: SRV*c:\symbols*http://msdl.Microsoft.com/download/symbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00)
System Uptime: 17 days 0:54:39.021
Process Uptime: 12 days 14:01:31.000
................................................................
...............................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1be0.b78): Access violation - code c0000005 (first/second chance not available)
*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
clr!WKS::gc_heap::find_first_object+0x92:
000007fe`ea129a1d f70100000080    test    dword ptr [rcx],80000000h ds:00000000`00003d80=????????

Ensuite, j'essaie de charger SOS avec ".load sos clr" et le message d'erreur:

The call to LoadLibrary(sos clr) failed, Win32 error 0n2
    "The system cannot find the file specified."
Please check your debugger configuration and/or network access.

Essayer avec ".loadby sos clr" et ça marche. Maintenant, je veux voir la pile avec "! Clrstack" et coller ici:

Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<Arch>_<Arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.

J'ai essayé ".symfix" et ".reload":

0:027> .symfix
0:027> .reload
..................*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
..............................................
...............................................................

Coincé. En même temps, lorsque le processus est exécuté sous WinDgb, je peux suspendre l'exécution, charger SOS Et exécuter la commande "! Clrstack" avec succès.

Des idées? Merci.

UPDATE - a suivi les étapes fournies dans la deuxième réponse, ne fonctionne toujours pas.

1) Chemin de mon symbole: SRV * c:\symboles * http: //msdl.Microsoft.com/download/symbols; srv *

2) CLR chargé: 4.0.30319. 237 : 

0:027> lm v clr
Unknown option 'r'
start             end                 module name
00000000`77b60000 00000000`77d09000   ntdll      (pdb symbols)          c:\symbols\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\ntdll.pdb
    Loaded symbol image file: ntdll.dll
    Image path: C:\Windows\System32\ntdll.dll
    Image name: ntdll.dll
    Timestamp:        Sat Nov 20 13:11:21 2010 (4CE7C8F9)
    CheckSum:         001B55EA
    ImageSize:        001A9000
    File version:     6.1.7601.17514
    Product version:  6.1.7601.17514
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® Windows® Operating System
    InternalName:     ntdll.dll
    OriginalFilename: ntdll.dll
    ProductVersion:   6.1.7601.17514
    FileVersion:      6.1.7601.17514 (win7sp1_rtm.101119-1850)
    FileDescription:  NT Layer DLL
    LegalCopyright:   © Microsoft Corporation. All rights reserved.
000007fe`e9fb0000 000007fe`ea915000   clr      # (pdb symbols)          c:\symbols\clr.pdb\1A7EA01DA29549DAB2B0BD012A6C5BA12\clr.pdb
    Loaded symbol image file: clr.dll
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
    Image name: clr.dll
    Timestamp:        Tue May 17 09:35:10 2011 (4DD2333E)
    CheckSum:         00967144
    ImageSize:        00965000
    File version:     4.0.30319.237
    Product version:  4.0.30319.237
    File flags:       8 (Mask 3F) Private
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® .NET Framework
    InternalName:     clr.dll
    OriginalFilename: clr.dll
    ProductVersion:   4.0.30319.235
    FileVersion:      4.0.30319.235 (RTMGDR.030319-2300)
    PrivateBuild:     DDBLD240
    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail

3) "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll" a la version 4.0.30319. 239

4) J'ai constaté que lorsque je charge le dump dans WinDbg, il charge le "mscordacwks.dll" correct à partir du Web, donc dans le dossier "C:\symboles\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000". mscordacwks_AMD64_AMD64_4.0.30319.237.dll ".

5) 

0:027> .cordll -ve -u -l
CLR DLL status: No load attempts

6)

0:027> !sym noisy
noisy mode - symbol prompts on
0:027> .restart

Loading Dump File [C:\crashdump.dmp]
User Mini Dump File with Full Memory: Only application data is available

DBGHELP: Symbol Search Path: srv*;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.Microsoft.com/download/symbols;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.Microsoft.com/download/symbols;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
Symbol search path is: srv*;SRV*c:\symbols*http://msdl.Microsoft.com/download/symbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00)
System Uptime: 17 days 0:54:39.021
Process Uptime: 12 days 14:01:31.000
................................................................
...............................................................
DBGHELP: ntdll - public symbols  
         C:\Program Files\Debugging Tools for Windows (x64)\sym\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\ntdll.pdb
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.Microsoft.com/download/symbols;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.Microsoft.com/download/symbols;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1be0.b78): Access violation - code c0000005 (first/second chance not available)
*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
DBGHELP: clr - public symbols  
         C:\Program Files\Debugging Tools for Windows (x64)\sym\clr.pdb\1A7EA01DA29549DAB2B0BD012A6C5BA12\clr.pdb
clr!WKS::gc_heap::find_first_object+0x92:
000007fe`ea129a1d f70100000080    test    dword ptr [rcx],80000000h ds:00000000`00003d80=????????

7)

0:027> !clrstack
SYMSRV:  C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll not found
SYMSRV:  mscordacwks_AMD64_AMD64_4.0.30319.237.dll from http://msdl.Microsoft.com/download/symbols: 502892 bytes - copied         
DBGHELP: C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll cached to C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD233F317b000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll
DBGHELP: C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD233F317b000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll - OK
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<Arch>_<Arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.
debuggingwindbgdump
19
net_prog

Je frappe ceci régulièrement lors du débogage avec minidumps du site. Je ne suis pas sûr de savoir comment cela s'est passé dans votre cas. Cela se produit généralement lorsque la version de CLR chargée lors du dump n’est pas disponible sur votre machine de débogage. Dans votre cas, il s’agit de la même machine, elle devrait donc probablement tout simplement fonctionner. Je suis sûr que d’autres pourront expliquer précisément pourquoi.

En attendant, voici ce que je fais avec les vidages de mon site. Windbg recherche "la bonne version" de mscordacwks.dll. Nous lui donnons donc cette version et lui indiquons où la chercher.

Premièrement, si je trafique tout cela en supprimant mscordacwks.dll, windbg s’éteint et le charge à partir du serveur de symboles Microsoft. Assurez-vous donc que vos symboles sont correctement configurés pour télécharger des symboles à partir du serveur de symboles Microsoft et qu’ils y reviennent .

Maintenant - en supposant que cela ne fonctionne pas, vérifiez exactement quelle version est la "bonne version". Répertoriez les informations sur le module avec "lm v clr" et vérifiez la version de votre CLR chargée ACTUELLEMENT. Le mien est 4.0.30319.239. Ok - trouve maintenant cette version de mscordacwks.dll. Supposons qu'il se trouve dans l'installation normale du framework .NET sur votre machine (C:\Windows\Microsoft.NET\Framework64\v4.0.30319). Vérifiez que la version correspond exactement (clic droit, propriétés, etc.)! Prenez-le et mettez-le dans un endroit sûr (j'utilise D:\Symbols\_Images). Suivez les instructions que windbg vous a données pour renommer le fichier. mscordacwks _.dll serait mscordacwks_AMD64_AMD64_4.0.30319.239.dll.

Configurez maintenant le chemin de votre image exécutable (".exepath D:\Symbols\_Images") afin que windbg sache où vous l'avez placé.

Vous avez maintenant "la bonne version de mscordacwks" et vous l'avez renommée pour que Windbg sache ce qu'elle recherche et lui indique où vous l'avez mise.

Si cela ne fonctionne toujours pas, essayez alors ".cordll -ve -u -l" et "! Sym noisy" pour activer la journalisation détaillée de la charge cordll et du serveur de symboles, puis essayez à nouveau! CLRStack. Peut-être que le résultat de ces deux commandes vous dira exactement ce qu'il essaie de charger et vous pourrez comprendre pourquoi il ne le fera pas ...

17
Pete

Je viens de passer la journée à déboguer de nombreux cas dans lesquels nous avons rencontré ce scénario. Les fichiers SOS + CLR situés sur la même boîte que le crash ne pouvaient pas être chargés dans WinDbg, et "lm v" a signalé deux versions différentes pour le même module:

0: 011> lm vM * clr.dll 
 Début/fin nom du module 
 000007fe`f2f50000 000007fe`f38b0000 clr # (symboles de pdb) c:\symboles\clr.pdb\EDFF900AC9B94D1B3269696A7989891A2\clr.p 
 Fichier d'image de symbole chargé: clr.dll 
 Chemin de l'image: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll 
 Nom de l'image: clr.dll 
 Horodatage: dim 21 avr. 03:36:04 2013 (5173C114) 
 Somme de contrôle: 0095F379 
 Image Taille: 00960000 
 Version du fichier: 4.0.30319.18052
    Version de produit: 4.0.30319.18052
 Drapeaux de fichiers: 8 (masque 3F) Privé 
 Fichier OS: 4 Inconnu Win32 
 Type de fichier: 2.0 Dll 
 Date du fichier: 00000000.00000000 
 Traductions : 0409.04b0 
 CompanyName: Microsoft Corporation 
 Nom du produit: Microsoft® .NET Framework 
 InternalName: clr.dll 
 OriginalFilename: clr.dll 
 ProductVersion : 4.0.30319.18047
 FileVersion: 4.0.30319.18047  construit par: FX45RTMGDR 
 PrivateBuild: DDBLD320 
 FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation 
 Mentions légalesCopyright: © Microsoft Corporation. Tous droits réservés. 
 Commentaires: Flavour = Retail

Détails de la sauvegarde

Le fichier Horodatage (0x5173C114), la somme de contrôle (0x0095F379) et la version (4.0.30319.18052) stockés dans la structure MINIDUMP_MODULE dans le module-list-stream du module minidump était destiné au nouveau CLR. Ouvrir le fichier minidump moi-même et regarder directement les données du flux:

MINIDUMP_MODULE: (pack: 8 taille: 112) 
 + 0x000 .BaseOfImage UInt64: 8791579230208 (0x7FEF2F50000) 
 + 0x008 .SizeOfImage UInt32: 9830400 (0x960000) 
 + 0x008. .CheckSum UInt32: 9827193 (0x95F379)
 + 0x010 .TimeDateStamp UInt32: 1366540564 (0x5173C114)
 + 0x014 .ModuleNameRva UInt32: 107828 (0x1A534) 
 + 0x018 .VersionInfo tagVS_FIXEDFILEINFO: (pack: 8 taille: 52) 
 + 0x000 .dwSignature UInt32: 4277770181 .____.] + 0x004 .dwStrucVersion UInt32: 65536 (0x10000) 
 + 0x008 .dwFileVersionMS UInt32: 262144 (0x40000)
 + 0x00C .dwFileVersionLS UInt32: 1987004036 (0x766F4684)

En séparant les mots haut et bas de dwFileVersionMS, nous obtenons 4 et 0.
En séparant les mots haut et bas de dwFileVersionLS, nous obtenons les 30319 et 18052.


En utilisant dumpchk.exe et en regardant les détails du module dans le PEB, nous pouvons voir un horodatage différent (0x515530CE), qui correspond en réalité à la version la plus ancienne (18047):

7fef2f50000 515530ce  28 mars 23:12:30 2013 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll


En examinant la mémoire brute dans le vidage sur incident où clr.dll est chargé, vous pouvez voir la somme de contrôle (0x00965F80) et l'horodatage (0x515530CE) de la version 4.0.30319.18047:

0: 011> db 000007fe`f2f50000 
 000007fe`f2f50000 4d 5a 90 00 03 00 00-04-04 00 00ff 00 00 MZ .............. 
 000007fe`f2f50010 b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 ... ........ @ ....... 
 000007fe`f2f50020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 
 000007fe`f2f50030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 01 00 00 ................ 
 000007fe`f2f50040 0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68 .... ....! .. L.! Th 
 000007fe`f2f50050 69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f est un programme canno 
 000007fe`f2f50060 74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20 t être exécuté en mode DOS 
 000007fe`f2f50070 6d 6f 64 65 2e 0d 0a-24 00 00 00 00 00 00 00 .... $ ....... 
 0: 011> db 
 000007fe`f2f50080 39 e4 28 ed 7d 85 46 be-7d 85 46 be 7d 85 46 be 9. (.}. F. } .F.}. F. 
 000007fe`f2f50090 81 f2 f8 soit 79 85 46 be-81 f2 fa soit 74 85 46 be .... yF .... tF 
 000007fe` f2f500a0 74 fd c5 be 73 85 46 be-74 fd c2 be c9 85 46 be t ... sFt .... F. 
 000007fe`f2f500b0 ee 41 8d soit 7f 85 46 be-e3 25 81 be 7c 85 46 be .A .... F ..% .. | .F. 
 000007fe`f2f500c0 ee 41 88 be 6b 85 46 be-ee 41 89 be 78 85 46 be .A..kF.A .. xF 
 000007fe`f2f500d0 ee 41 8b soit 64 85 46 be-7d 85 47 be ca 87 46 be .A..dF} .G ... F. 
 000007fe`f2f500e0 81 f2 ff be 76 85 46 be-ee 41 9e be 70 87 46 be .... vF.A..pF 
 000007fe`f2f500f0 ee 41 8c soit 7c 85 46 be-ee 41 8f soit 7c 85 46 be. A .. | .F..A .. | .F. 
 0: 011> 
 000007fe`f2f50100 ee 41 8a soit 7c 85 46 be-52 69 63 68 7d 85 46 be. A .. | .F.Rich} .F. ​​
 000007fe`f2f50110 00 00 00 00 00 00 00 00-50 45 00 00 64 86 06 00 ........ PE..d. .. 
 000007fe`f2f50120 ce 30 55 51  00 00 00 00-00 00 00 00 00 f0 00 22 20 .0UQ .......... "
 000007fe`f2f50130 0b 02 0b 00 00 90 69 00-00 c2 2b 00 00 00 00 00 ...... i ... + ..... 
 000007fe`f2f50140 40 51 13 00 00 00 00 00 f5 f2 fe 07 00 00 @Q ...... ........ 
 000007fe`f2f50150 00 10 00 00 00 02 00 00-06 00 00 00 00a 00 00 00 ................ 
 000007fe`f2f50160 06 00 00 00 00 00 00 00-00 e0 95 00 00 04 00 00 ................ 
 000007fe`f2f50170 80 5f 96 00  02 00 60 01-00 00 10 00 00 00 00 00 ._.... `.........

J'ai également progressé dans la mémoire, j'ai regardé la ressource Version en mémoire et vu la chaîne de version 18047.


Nous avons donc maintenant un minidump contenant des informations contradictoires sur la version de clr.dll réellement utilisée.

Ce qui l'a causé

J'ai également découvert que notre service informatique avait récemment publié une poignée de mises à jour Windows.

  • Lorsqu'une application était en cours d'exécution, une mise à jour du CLR a été installée.
  • Le fichier dans C:\Windows\Microsoft.NET\Framework64\v4.0.30319\a été mis à jour vers la version la plus récente (4.0.30319.18052).
  • L'application s'est écrasée
  • MiniDumpWriteDump a apparemment utilisé les informations de fichier sur disque lors du stockage de la liste de modules dans le fichier de vidage sur incident (4.0.30319.18052)
  • WinDbg n'a pas été en mesure de corréler la version marquée dans le vidage mémoire sur incident avec ce qui était dans la mémoire du processus car il contenait des informations contradictoires.

Pour vérifier cela, j'ai modifié manuellement l'entrée MINIDUMP_MODULE pour clr.dll afin de modifier la somme de contrôle, l'horodatage et la version de 18052 à 18047. Après avoir rechargé le fichier .dmp piraté dans WinDbg et défini le chemin d'exépat sur les dll sos + clr correctes, J'ai réussi à exécuter les commandes sos et à obtenir une trace de pile valide.

Ligne de fond

Nous nous sommes essentiellement retrouvés avec un fichier minidump contenant des informations contradictoires sur la version de clr.dll chargée dans le processus, empêchant ainsi SOS d'identifier le bon moteur clr. Il s'agit probablement d'un bogue. dans MiniDumpWriteDump car il enregistre le fichier de vidage sur incident. Mais cela ne devrait se produire que lorsque la version de sauvegarde du CLR a été mise à jour pendant l'exécution de votre application.

12
josh poley

Le processus que vous essayez de déboguer est-il un 32 bits? Que dit la liste des gestionnaires de tâches-processus? Si son processus 32 bits, vous devez utiliser windbg 32 bits. Sinon, je ne vois pas pourquoi .load sos clr devrait échouer.

ps: (alerte noob windbg), donc je m'excuse si cela semble boiteux. J'essaye juste d'aider.

0
Nikhil S

On dirait que vous avez fait une installation personnalisée de windbg sans sélectionner toutes les extensions dont vous avez besoin. L'erreur Win32 n2 est généralement un signe de ce problème.

0
steve