적절한 디버그 기호 찾기

Question

다른 PC에서 메모리 덤프를 받았습니다. 또한 x64 시스템이지만 다른 Windows 버전입니다. 일반적인 앱 작업의 덤프입니다. 나는 다음 덤프 (다음 덤프는 문제가 내부에있을 것임)를 분석해야한다고 확신했다.

처음에는 DebugDiag Analysis 도구를 사용하여이 덤프를 실행했다. 다음은 요약입니다.

수면 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에서 메서드의 사람의 이름 대신 주소를 참조하십시오.

  주요 문제는 내가 놓친하는 기호를 이해하는 방법은 다음과 같습니다

여기 debugdiag에서 스레드 0의 호출 스택입니다 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 
.... 

에 대한 출력의 일부입니다?

Answer 1

는 크래시 덤프 파일을 제공

감사합니다 WinDbg는

의 최신 버전을 사용하십시오. WinDbg 6.3.9600.17298 및 6.2.9200.16384로 문제를 재현 할 수 있습니다.

WinDbg 10.0.15003.1001에서는 처음으로 !analyze -v이 성공하여 이메일을 보냈습니다. 지금은 다시 시도하는 것이, 그것은

X64_BREAKPOINT_NOSOS_sechost!ScSendResponseReceiveControls+13b 

실패 내가 SOS and MSCorDACWks를 다운로드하고이 .cordll -lp 점을하자해도 그 유지됩니다. !dumpstack은 수동으로 입력 할 때 작동하지만 어떤 이유로 든 !analyze에서 작동하지 않는 것으로 보입니다.

메시지의 해석

메시지에 대한 해석이 잘못되었습니다.

메시지는 다음과 같습니다

WRONG_SYMBOLS_80000003_sechost.dll!ScSendResponseReceiveControls 

이 말한다 :

1. 충돌이 sechost.dll
2. 예외 코드에서 일어난 인 INT3 중단 점 (80000003)
3. 일부 기호가 잘못되었으므로 그 정보가 맹목적으로 신뢰하지 마십시오.

"sechost.dll의 기호가 잘못되었습니다"라고 말하지 않습니다.

어떻게 가능합니까? 기호를 사용할 수없는 호출 스택 (호출자 위의 프레임)이있을 수 있습니다. 이 경우 WinDbg가 스택을 올바르게 해석하지 못할 수 있습니다. 그런 다음 잘못된 범인을 발견했을 수 있습니다.