適切なデバッグシンボルを見つける

Question

私は別のPCからメモリダンプを取得しました。 x64マシンですが、Windowsのバージョンは異なります。 通常のアプリのダンプです。 次のダンプを解析する必要があることを確認しました（次のダンプは問題が内部にあります）

最初に、DebugDiag Analysisツールを使用してこのダンプ用に実行しました。 以下は要約です：

スリープAPIは問題ありません。 "以前の.netの例外"に関して、私はそれが何であるか分かりません。

その後、WinDbgを実行します。 Microsoftと自分のシンボルをロードした後、!analyze -vを実行して、関連するすべてのシンボルがダンプで動作することを確認します。

!analyze -vをruningて後、私が得た：

私はこの出力から理解したよう

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 
.... 

のために出力の一部であるdebugdiagからスレッド0のコールスタックです：

主な質問は、私が見逃している記号を理解する方法ですか？

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はスタックを正しく解釈できないことがあります。その後、間違った原因を見つけた可能性があります。