2017-03-29 4 views
0

J'ai récupéré l'image mémoire d'un autre PC. C'est aussi une machine x64, mais la version différente de Windows. Il s'agit d'un vidage du travail de l'application habituelle. Je l'ai pris pour m'assurer d'avoir analysé le prochain vidage (la prochaine vidage sera avec le problème à l'intérieur)Recherche des symboles de débogage appropriés

Dans un premier temps, j'ai pris l'outil DebugDiag Analysis et je l'ai exécuté pour ce vidage. Voici le résumé: enter image description here

Sleep API est ok. En ce qui concerne les "précédentes exceptions .net", je n'ai aucune idée de ce que c'est. enter image description here

Ensuite, je lance le WinDbg. Après avoir chargé Microsoft et mes propres symboles, je cours !analyze -v pour m'assurer que j'ai tous les symboles appropriés pour travailler avec dump.

Après runing !analyze -v je suis arrivé:

FAULTING_IP: 
+0 
00000000`00000000 ??    ??? 
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff) 
ExceptionAddress: 0000000000000000 
    ExceptionCode: 80000003 (Break instruction exception) 
    ExceptionFlags: 00000000 
NumberParameters: 0 

CONTEXT: 0000000000000000 -- (.cxr 0x0;r) 
rax=000007fef8150aa8 rbx=0000000000000000 rcx=000000000210e618 
rdx=000000000210e801 rsi=00000000ffffffff rdi=00000000000001a4 
rip=0000000076e7d9fa rsp=000000000058e558 rbp=0000000000000000 
r8=0000000001a5a404 r9=00000000ffffffff r10=000007fef7f304e0 
r11=0000000000000206 r12=0000000000000000 r13=000000000066be80 
r14=0000000000000000 r15=0000000000000000 
iopl=0   nv up ei pl zr na po nc 
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b    efl=00000246 
ntdll!ZwWaitForSingleObject+0xa: 
00000000`76e7d9fa c3    ret 
FAULTING_THREAD: 00000000000012b8 
DEFAULT_BUCKET_ID: WRONG_SYMBOLS 
PROCESS_NAME: IPCapture.exe 
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached. 
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid 
NTGLOBALFLAG: 0 
APPLICATION_VERIFIER_FLAGS: 0 
APP: ipcapture.exe 
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre 
MANAGED_STACK: !dumpstack -EE 
No export dumpstack found 
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS 
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS 
LAST_CONTROL_TRANSFER: from 000007fefcde10dc to 0000000076e7d9fa 

STACK_TEXT: 
00000000`0058e558 000007fe`fcde10dc : 00000000`0058e928 00000000`0058e5c0 00000000`0195bfc8 00000000`561ad250 : ntdll!ZwWaitForSingleObject+0xa 
00000000`0058e560 000007fe`fdd6affb : 00000000`ffffffff 000007fe`fdd6344c 00000000`00000000 00000000`000001a4 : KERNELBASE!WaitForSingleObjectEx+0x79 
00000000`0058e600 000007fe`fdd69d61 : 00000000`0060b0d0 00000000`000001a4 00000000`00000000 00000000`00000000 : sechost!ScSendResponseReceiveControls+0x13b 
00000000`0058e6f0 000007fe`fdd69c16 : 00000000`0058e858 00000000`00000000 00000000`00000000 000007fe`00000000 : sechost!ScDispatcherLoop+0x121 
00000000`0058e800 000007fe`f904bec7 : 00000000`00611460 00000000`0066be80 00000000`00611460 00000000`00644d60 : sechost!StartServiceCtrlDispatcherW+0x14e 
00000000`0058e850 000007fe`f72cf0a8 : 000007fe`f72dc8a0 000007fe`f72a64c8 00000000`447ecfa0 00000000`00000000 : mscorwks!DoNDirectCall__PatchGetThreadCall+0x7b 
00000000`0058e8f0 000007fe`f72d1478 : 00000000`006548a0 00000000`00000000 00000000`006548b8 00000000`00000000 : System_ServiceProcess_ni+0x2f0a8 
00000000`0058e9b0 000007ff`00180147 : 00000000`01962888 00000000`01962768 00000000`01962768 000007fe`f82e7680 : System_ServiceProcess_ni+0x31478 
00000000`0058ea50 000007fe`f904c6a2 : 000007ff`00043430 000007fe`f8f58ae9 00000000`00000000 000007ff`00043420 : 0x000007ff`00180147 
00000000`0058ea80 000007fe`f8f0ff03 : 00000000`00000000 000007fe`00000026 000007fe`f8e073e0 00000000`00000000 : mscorwks!CallDescrWorker+0x82 
00000000`0058eac0 000007fe`f942a291 : 00000000`0058ebf8 00000000`00000000 00000000`00000001 00000000`00000000 : mscorwks!CallDescrWorkerWithHandler+0xd3 
00000000`0058eb60 000007fe`f8eb3167 : 00000000`00000000 000007ff`00043420 00000000`00000000 00000000`0058f060 : mscorwks!MethodDesc::CallDescr+0x2b1 
00000000`0058eda0 000007fe`f8e8f874 : 00000000`00000000 00000000`00000000 00000003`00380017 00000000`00000000 : mscorwks!ClassLoader::RunMain+0x22b 
00000000`0058f000 000007fe`f9516aed : 00000000`0058f650 00000000`00000000 00000000`00629698 00000000`00000200 : mscorwks!Assembly::ExecuteMainMethod+0xbc 
00000000`0058f2f0 000007fe`f8e825f7 : 00000000`00000000 00000000`00000000 00000000`00000000 000007fe`f8e6796e : mscorwks!SystemDomain::ExecuteMainMethod+0x47d 
00000000`0058f8c0 000007fe`f8e9f610 : ffffffff`fffffffe 00000000`00000000 0000f563`00000000 00000000`00000000 : mscorwks!ExecuteEXE+0x47 
00000000`0058f910 000007fe`f97672fd : ffffffff`ffffffff 00000000`00611460 00000000`00000000 00000000`0058f918 : mscorwks!CorExeMain+0xac 
00000000`0058f970 000007fe`f9845b21 : 00000000`00000000 000007fe`f8e9f564 00000000`00000000 00000000`00000000 : mscoreei!CorExeMain+0xe0 
00000000`0058f9c0 00000000`76c25a4d : 000007fe`f9760000 00000000`00000000 00000000`00000000 00000000`00000000 : mscoree!CorExeMain_Exported+0x57 
00000000`0058f9f0 00000000`76e5b831 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd 
00000000`0058fa20 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d 


STACK_COMMAND: ~0s; .ecxr ; kb 
FOLLOWUP_IP: 
sechost!ScSendResponseReceiveControls+13b 
000007fe`fdd6affb 85c0   test eax,eax 
SYMBOL_STACK_INDEX: 2 
SYMBOL_NAME: sechost!ScSendResponseReceiveControls+13b 
FOLLOWUP_NAME: MachineOwner 
MODULE_NAME: sechost 
IMAGE_NAME: sechost.dll 
DEBUG_FLR_IMAGE_TIMESTAMP: 55636728 
FAILURE_BUCKET_ID: WRONG_SYMBOLS_80000003_sechost.dll!ScSendResponseReceiveControls 
BUCKET_ID: X64_APPLICATION_FAULT_WRONG_SYMBOLS_sechost!ScSendResponseReceiveControls+13b 
ANALYSIS_SOURCE: UM 
FAILURE_ID_HASH_STRING: um:wrong_symbols_80000003_sechost.dll!scsendresponsereceivecontrols 
FAILURE_ID_HASH: {e6dbb060-e976-9c4d-c3ce-fc837a3c58a8} 
Followup: MachineOwner 

Comme je comprends de cette sortie:

  • j'ai quelques problèmes avec des symboles de débogage. (Peut-être est-il lié à sechost.dll)
  • Analyser bloqué au tout début (fil 0). Alors peut-être que j'ai un problème avec l'analyse du tout (pas de problème ce fil)
  • Je vois l'adresse à la place du nom de la méthode dans DebugDiag.

Voici une partie de la production pour lmvm sechost

0:000> lmvm sechost 
start    end     module name 
000007fe`fdd60000 000007fe`fdd7f000 sechost (pdb symbols)   
C:\ProgramData\dbg\sym\sechost.pdb\3824AD19AB6C47AA8870D6E371F1738B1\sechost.pdb 

Loaded symbol image file: sechost.dll 
Image path: C:\Windows\System32\sechost.dll 
.... 

Voici pile d'appel de fil 0 de DebugDiag: enter image description here

La principale question est de savoir comment comprendre quels symboles j'ai manqué?

+1

La duplication possible de [symbole de débogage Microsoft ne fonctionne pas] (http://stackoverflow.com/questions/42770518/microsoft-debug-symbol-dont-work) – magicandre1981

+0

vous avez posé la même question il y a quelques jours. ne demandez pas la même encore et encore. [Ajouter une prime] (http://stackoverflow.com/help/bounty) si vous avez besoin de plus d'attention – magicandre1981

+0

@ magicandre1981: il est difficile de repérer la différence, mais la dernière fois, les symboles étaient vraiment introuvables, cette fois, les symboles sont trouvé mais le message est interprété dans le mauvais sens. Faites-moi savoir si vous êtes d'accord avec ma réponse. –

Répondre

2

utiliser une version plus récente de WinDbg

Merci de fournir le fichier de vidage sur incident. Je pourrais reproduire votre problème avec WinDbg 6.3.9600.17298 et 6.2.9200.16384.

Dans WinDbg 10.0.15003.1001, !analyze -v a réussi la première fois que je vous ai écrit un e-mail. Maintenant que je l'essayer à nouveau, il échoue avec

X64_BREAKPOINT_NOSOS_sechost!ScSendResponseReceiveControls+13b 

et qui reste même si je télécharger SOS and MSCorDACWks et laisser .cordll -lp points là-bas. !dumpstack fonctionne quand je l'entre manuellement, mais il semble ne pas fonctionner pour !analyze pour une raison quelconque.

interprétation du message

Votre interprétation du message est erroné.

Le message est:

WRONG_SYMBOLS_80000003_sechost.dll!ScSendResponseReceiveControls 

Ce dit:

  1. l'accident est arrivé dans sechost.dll
  2. le code d'exception est un point d'arrêt INT3 (80000003)
  3. certains les symboles sont faux, alors ne faites pas aveuglément confiance à l'information là où c'est arrivé.

Il ne dit pas "Les symboles de sechost.dll sont faux".

Comment est-ce possible? Il peut arriver qu'il y ait un cadre sur la pile d'appels (au-dessus du coupable) pour lequel les symboles ne sont pas disponibles. Dans ce cas, WinDbg risque de ne pas pouvoir interpréter correctement la pile. Il aurait alors pu trouver un coupable incorrect.

+0

J'ai demandé à prendre le vidage sans aucun problème à l'intérieur (vidage de vidage pendant le travail habituel). Donc, tout accident semble étrange. J'ai vérifié ce vidage avec les outils debugdiag et ça me semble bien. Mais la question principale est de savoir comment comprendre quels symboles sont manqués? Je mettrai à jour ma question demain avec la sortie complète de 'analyze -v' et le résultat de debugdiag pour le thread où windbg a obtenu l'exception. –