Поиск подходящих символов отладки

Я получил дамп памяти с другого компьютера. Это также машина x64, но с другой версией Windows. Это свалка обычной работы приложения. Я взял его, чтобы убедиться, что у меня есть все необходимое для анализа следующего дампа (следующий дамп будет с проблемой внутри)

Сначала я взял инструмент анализа DebugDiag и запустил его для этого дампа. Вот сводка: введите здесь описание изображения

API сна в порядке. Что касается «предыдущих исключений .net», я понятия не имею, что это такое. введите здесь описание изображения

После этого запускаю WinDbg. После загрузки Microsoft и моих собственных символов я запускаю !analyze -v, чтобы убедиться, что у меня есть все соответствующие символы для работы с дампом.

После запуска !analyze -v я получил:

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

Как я понимаю из этого вывода:

  • У меня есть некоторые проблемы с символами отладки. (Возможно, это связано с sechost.dll)
  • Анализ застрял в самом начале (поток 0). Так что, возможно, у меня вообще проблемы с анализом (не проблема в этой теме)
  • Я вижу адрес вместо человеческого имени метода в DebugDiag.

Вот часть вывода для 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
....

Вот стек вызовов потока 0 из debugdiag: введите здесь описание изображения

Главный вопрос, как понять, какие символы я пропустил?


c# debug-symbols windbg pdb-files memory-dump
person Stepan Loginov    schedule 29.03.2017    source источник
comment
Возможный дубликат символ отладки Microsoft не работает   -  person magicandre1981    schedule 29.03.2017
comment
Вы задавали тот же вопрос несколько дней назад. не спрашивайте одно и то же снова и снова. Добавьте вознаграждение, если вам нужно больше внимания   -  person magicandre1981    schedule 29.03.2017
comment
@magicandre1981: трудно заметить разницу, но в прошлый раз символы действительно не были найдены, в этот раз символы найдены, но сообщение интерпретировано неправильно. Дайте мне знать, если вы согласны с моим ответом.   -  person Thomas Weller    schedule 29.03.2017
comment
Ты прав. Теперь у меня есть символы для этой библиотеки. Но я все еще не могу продолжать. На самом деле я не уверен, что проблема с этой библиотекой.   -  person Stepan Loginov    schedule 30.03.2017
comment
у вас есть файлы ngened в стеке (собственные изображения), здесь вам нужно создать свои собственные PDB для файлов NI: blogs.msdn.microsoft.com/visualstudioalm/2012/12/10/   -  person magicandre1981    schedule 30.03.2017

Ответы (1)


arrow_upward
2
arrow_downward

Используйте более новую версию WinDbg

Спасибо за предоставленный файл аварийного дампа. Я могу воспроизвести вашу проблему с WinDbg 6.3.9600.17298 и 6.2.9200.16384.

В WinDbg 10.0.15003.1001 !analyze -v удалось, когда я впервые написал вам электронное письмо. Теперь, когда я пытаюсь сделать это снова, это не удается с

X64_BREAKPOINT_NOSOS_sechost!ScSendResponseReceiveControls+13b

и это останется, даже если я загружу SOS и MSCorDACWks и позволю .cordll -lp указать туда . !dumpstack работает, когда я ввожу его вручную, но, похоже, не работает для !analyze по какой-то причине.

Интерпретация сообщения

Ваша интерпретация сообщения неверна.

Сообщение:

WRONG_SYMBOLS_80000003_sechost.dll!ScSendResponseReceiveControls

Это говорит:

  1. сбой произошел в sechost.dll
  2. код исключения - точка останова INT3 (80000003)
  3. некоторые символы неверны, поэтому не доверяйте слепо информации, где это произошло.

Он не говорит: «Символы sechost.dll неверны».

Как это возможно? Может случиться так, что в стеке вызовов есть фрейм (выше виновника), для которого символы недоступны. В этом случае WinDbg не сможет правильно интерпретировать стек. Затем он мог бы найти неправильного виновника.

person Thomas Weller    schedule 29.03.2017
comment
Попросил без проблем снять дамп внутри (дамп дамп при обычной работе). Поэтому любой сбой выглядит странно. Я проверил этот дамп с помощью инструментов debugdiag, и он выглядит хорошо для меня. Но главный вопрос в том, как понять, какие символы пропущены? Завтра я обновлю свой вопрос с полным выводом analyze -v и результатом отладки для потока, в котором windbg получил исключение. - person Stepan Loginov; 30.03.2017