查找适当的调试符号

Posted 2023-04-19

【中文标题】查找适当的调试符号

【英文标题】：Finding appropriate debug symbols

【发布时间】：2017-08-22 19:26:01

【问题描述】：

我从另一台 PC 获得了内存转储。 它也是 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
....

这是来自 debugdiag 的线程 0 的调用堆栈：

主要问题是如何理解我错过了哪些符号？

【问题讨论】：

Microsoft debug symbol don't work的可能重复

你几天前问过同样的问题。不要一遍又一遍地问同样的问题。 Add a bounty如果您需要更多关注

@magicandre1981：很难发现差异，但上次确实找不到符号，这一次，找到了符号但信息被错误地解释了。如果您同意我的回答，请告诉我。

你是对的。现在我有这个库的一些符号。但我还是不能继续。其实我不确定这个库有这个问题。

您已经在堆栈中生成了文件（本机图像），这里您需要为 NI 文件创建自己的 PDB：blogs.msdn.microsoft.com/visualstudioalm/2012/12/10/…

【参考方案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

这说：

sechost.dll 发生崩溃 异常代码是一个 INT3 断点 (80000003) 一些符号是错误的，所以不要盲目相信它发生的信息。

它没有说“sechost.dll 的符号错误”。

这怎么可能？调用堆栈（在罪魁祸首之上）可能存在符号不可用的帧。在这种情况下，WinDbg 可能无法正确解释堆栈。那么它可能找到了错误的罪魁祸首。

【讨论】：

我要求在没有任何问题的情况下进行转储（在正常工作期间进行转储转储）。所以任何崩溃看起来都很奇怪。我用调试诊断工具检查了这个转储，它看起来对我很好。但主要问题是如何理解遗漏了哪些符号？明天我将使用analyze -v 的完整输出和windbg 出现异常的线程的调试诊断结果更新我的问题。