【发布时间】:2021-01-20 16:51:16
【问题描述】:
我一直在尝试在一个项目中使用以前的同事的崩溃记者。 它在发生崩溃时输出堆栈跟踪,其中包含例如这样的内容(仅显示堆栈跟踪中最重要的行):
Event: APPLICATION_CRASH
SE EXCEPTION_ACCESS_VIOLATION at address 0x00007FF773D681E6 inside MyApp.exe loaded at base address 0x00007FF773950000 Invalid operation: read at address
作为我们构建过程的一部分,我们将导出调试信息(即使在“发布”模式下构建)并将它们保存在我们的文件服务器上,以便我们为我们交付的每个版本的软件应用程序提供匹配的调试信息.
现在,我正在尝试使用内存地址、exe、pdb 文件和 WinDBG(版本 1.0.2007.06001)查找崩溃发生的位置。
我已将所有 pdb 文件复制到我的 exe 所在的应用程序文件夹的根目录中
我正在通过开始调试-> 启动可执行文件来加载 exe。
然后我尝试在 WinDBG 中使用以下命令获取符号:
u 0x00007FF773D681E6
不幸的是,无论我尝试什么,我都会得到:
0:000> u 0x00007FF773D681E6
00007ff7`73d681e6 ?? ???
^ Memory access error in 'u 0x00007FF773D681E6'
我试图通过这样做来添加这个标志SYMOPT_LOAD_ANYTHING:
0:000> .symopt+ 0x40
Symbol options are 0x30377:
0x00000001 - SYMOPT_CASE_INSENSITIVE
0x00000002 - SYMOPT_UNDNAME
0x00000004 - SYMOPT_DEFERRED_LOADS
0x00000010 - SYMOPT_LOAD_LINES
0x00000020 - SYMOPT_OMAP_FIND_NEAREST
0x00000040 - SYMOPT_LOAD_ANYTHING
0x00000100 - SYMOPT_NO_UNQUALIFIED_LOADS
0x00000200 - SYMOPT_FAIL_CRITICAL_ERRORS
0x00010000 - SYMOPT_AUTO_PUBLICS
0x00020000 - SYMOPT_NO_IMAGE_SEARCH
然后完全重新加载,使用此命令:.reload /f /i(我尝试过不使用 /i 但仍然是相同的输出)但我总是遇到相同的内存访问错误。
我做错了什么,我有什么遗漏吗?
【问题讨论】:
-
看看
!sym noisy有没有给你带来有趣的东西 (docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-sym) -
如果可能的话,也设置一个符号服务器意味着你可以避免几乎所有这些问题。
-
我如何定期执行此操作,尤其是对于转储中的实际崩溃:1. 打开转储时立即使用
.symfix2. 使用.sympath+ full-path-to-your-pdbs。对需要修改的所有 pdb 路径重复 (2)。 3.运行!analyze -v,然后坐等;这可能需要一段时间,具体取决于图像大小和符号。这应该让你非常接近罪魁祸首。机器架构在分析步骤之前设置很重要。如果它是 32 位 x86 转储并且您正在运行 WinDbg x64,则在步骤 (2) 和 (3) 之间需要.effmach x86,但看起来这不是您的情况。 -
@MikeVine 我以前用过那个详细的模式,但它并没有告诉我太多,你要我在这里发布吗?什么是符号服务器?我已将所有符号放在一个地方,并将该路径添加到 WinDBG sympath,但没有成功编辑:似乎主 pdb 已正确加载
-
@WhozCraig 不幸的是,该应用程序没有生成 dmp 文件...一直是 x64 :) 我以前没有听说过分析,我会尝试你的命令并回复你 - 谢谢!
标签: c++ windows debugging windbg