WinDbg ne montre pas des informations utiles

Question

D'abord permettez-moi de dire que je suis un noob totale WinDbg, donc cela pourrait être une question facile ...

J'ai une application (« MyApp » - nom changé pour protéger les innocents!) que j'essaye de déboguer parce qu'il lance une exception. Cela n'arrive que sur les machines des utilisateurs - je n'ai pas pu le reproduire sur ma machine de développement. J'ai donc installé DebugDiag sur la machine des utilisateurs et capturé un vidage complet. Ensuite, j'ai chargé le vidage dans WinDbg et j'ai fait un analyze -v et un kp pour essayer de comprendre ce qui se passait ... mais aucun de ceux-ci ne semble me donner l'information que je cherche - la fonction (et j'espère la ligne nombre) de la ligne qui est à l'origine du problème ... Je pense que je le fichier symbole chargé en spécifiant le chemin vers « MyApp.pdb » dans le chemin du fichier Symbole:

 
srv*c:\symcache*http://msdl.microsoft.com/download/symbols;srv*c:\symcache*C:\dev\Customer\MyAppSln\MyApp\Debug 

Tout d'abord, voici la sortie kp:

 
0:004> kp 
ChildEBP RetAddr 
WARNING: Stack unwind information not available. Following frames may be wrong. 
0502f474 7c347966 MyApp!DllMain+0x3e8a6 
0502f4bc 7c3a2448 msvcr71!_nh_malloc(unsigned int size = <Memory access error>, int nhFlag = <Memory access error>)+0x24 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c @ 117] 
0502f57c 7c3416b3 msvcp71!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy(bool _Built = <Memory access error>, unsigned int _Newsize = <Memory access error>)+0x45 [f:\vs70builds\3077\vc\crtbld\crt\src\xstring @ 1520] 
0502f610 7c3a32de msvcr71!_heap_alloc(unsigned int size = <Memory access error>)+0xe0 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c @ 212] 
0502f620 7c3b3f63 msvcp71!wmemcpy(wchar_t * _S1 = 0x04e463b9 "Ҹ???", wchar_t * _S2 = 0xffffffff "--- memory read error at address 0xffffffff ---", unsigned int _N = 0x4e25212)+0x14 [f:\vs70builds\3077\vc\crtbld\crt\src\wchar.h @ 843] 
0502f640 04e463b9 msvcp71!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::assign(class std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * _Right = 0xffffffff, unsigned int _Roff = 0x4e25212, unsigned int _Count = 2)+0x7c [f:\vs70builds\3077\vc\crtbld\crt\src\xstring @ 601] 
0502f770 04df1077 MyApp!DllMain+0x65329 
0502f824 04e01b35 MyApp!DllMain+0xffe7 
0502ff08 04dfe034 MyApp!DllMain+0x20aa5 
0502ff48 04dfde4f MyApp!DllMain+0x1cfa4 
0502ff88 7648d0e9 MyApp!DllMain+0x1cdbf 
0502ffc4 773499f9 kernel32!BaseThreadInitThunk+0xe 
0502ffd4 7738198e ntdll!RtlQueryInformationAcl+0x8b 
0502ffec 00000000 ntdll!_RtlUserThreadStart+0x1b 

la ligne que je suis spécifiquement essayer de décoder est le « MyApp DllMain + 0x65329! » comme cela est le dernier l ine qui semble être en cours d'exécution, et l'erreur se produit dans l'appel malloc, qui est apparemment d'où l'exception est levée. Qu'est-ce que je fais de mal qui fait qu'il affiche seulement le module et le décalage au lieu du fichier source et du numéro de ligne?

Je suis aussi ne sais pas pourquoi la ligne ci-dessus l'appel malloc est de retour à nouveau MyApp - peut-être quelqu'un peut expliquer aussi.

Juste au cas où, voici la sortie de « analyser -v »:

 
0:004> !analyze -v 
******************************************************************************* 
*                    * 
*      Exception Analysis         * 
*                    * 
******************************************************************************* 

*** WARNING: Unable to verify checksum for MyApp.exe 
*** ERROR: Module load completed but symbols could not be loaded for MyApp.exe 
*** WARNING: Unable to verify checksum for ThirdPartyDll.dll 
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ThirdPartyDll.dll - 
*** WARNING: Unable to verify checksum for mdnsNSP.dll 
*** ERROR: Symbol file could not be found. Defaulted to export symbols for mdnsNSP.dll - 
*** ERROR: Symbol file could not be found. Defaulted to export symbols for SLC.dll - 

FAULTING_IP: 
MyApp!DllMain+3e8a6 
04e1f936 8b16   mov  edx,dword ptr [esi] 

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) 
ExceptionAddress: 04e1f936 (MyApp!DllMain+0x0003e8a6) 
    ExceptionCode: c0000005 (Access violation) 
    ExceptionFlags: 00000000 
NumberParameters: 2 
    Parameter[0]: 00000000 
    Parameter[1]: 00000000 
Attempt to read from address 00000000 

PROCESS_NAME: MyApp.exe 

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s". 

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s". 

EXCEPTION_PARAMETER1: 00000000 

EXCEPTION_PARAMETER2: 00000000 

READ_ADDRESS: 00000000 

FOLLOWUP_IP: 
msvcr71!_heap_alloc+e0 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c @ 212] 
7c3416b3 e88e0c0000  call msvcr71!__SEH_epilog (7c342346) 

NTGLOBALFLAG: 0 

APPLICATION_VERIFIER_FLAGS: 0 

LAST_CONTROL_TRANSFER: from 00000000 to 773bbb33 

FAULTING_THREAD: ffffffff 

BUGCHECK_STR: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_NULL_POINTER_READ_SHUTDOWN 

PRIMARY_PROBLEM_CLASS: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN 

DEFAULT_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN 

STACK_TEXT: 
773bbb33 ntdll!RtlpAllocateHeap+0x7ad 
773a6e0c ntdll!RtlAllocateHeap+0x1e3 
7c3416b3 msvcr71!_heap_alloc+0xe0 


FAULTING_SOURCE_CODE: 
No source found for 'f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c' 


SYMBOL_STACK_INDEX: 2 

SYMBOL_NAME: msvcr71!_heap_alloc+e0 

FOLLOWUP_NAME: MachineOwner 

MODULE_NAME: msvcr71 

IMAGE_NAME: msvcr71.dll 

DEBUG_FLR_IMAGE_TIMESTAMP: 3e561eac 

STACK_COMMAND: dds 7740c078 ; kb 

FAILURE_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN_c0000005_msvcr71.dll!_heap_alloc 

BUCKET_ID: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_NULL_POINTER_READ_SHUTDOWN_msvcr71!_heap_alloc+e0 

Answer 1

Lorsque vous définissez le chemin des symboles, avez-vous les recharger?

.reload

Je ne suis pas sûr que votre ajout d'

srv*c:\symcache*C:\dev\Customer\MyAppSln\MyApp\Debug

sur le chemin de symbole a l'effet désiré. je liste généralement tous les chemins locaux du .sympath d'abord, et comme la dernière étape, je .symfix + pour configurer les symboles publics en utilisant le serveur de symbole Microsoft:

 
.sympath C:\dev\Customer\MyAppSln\MyApp\Debug 
.symfix+ c:\symcache 

la raison d'être répertoriant les chemins locaux première étant que le débogueur n'aurait pas à vérifier le serveur distant pour pdbs (qui ne sont pas là de toute façon) au lieu de simplement les récupérer localement.

De toute façon, votre problème est que les symboles pour MyApp ne sont pas chargés, donc la marche en pile ne fonctionne pas tout à fait. Le débogueur fait reculer la pile en commençant par le haut, c'est pourquoi vous voyez MyApp - c'est là que la violation d'accès s'est produite. Maintenant, puisque le débogueur n'a pas les symboles à ce stade, il ne peut que deviner quelle chaîne d'invocation a conduit à la fonction en haut. Et il devine mal en suivant un chemin trompeur.

Answer 2

Si vous croyez que l'APB devrait être dans votre chemin de symbole, vous devez exécuter quelque chose comme ceci:

!sym noisy 
.reload MyApp.dll 
kp 

sym bruyant provoque le débogueur de donner des informations plus détaillées sur la raison pour laquelle il n'a pas pu charger des symboles - Aucun MyApp.pdb trouvé, trouvé mais ne correspond pas, etc. Cela vous aidera à trouver pourquoi il ne charge pas de symboles. !sym noisy désactive à nouveau la sortie du symbole verbeux.