0

当我在 Visual Studio 2005 中打开 Windows 故障转储时，得到了这个调用堆栈：

>   myprog.exe!app_crash::CommonUnhandledExceptionFilter(_EXCEPTION_POINTERS * pExceptionInfo=0x0ef4f318)  Line 41  C++
    pdm.dll!513fb8e2()  
    [Frames below may be incorrect and/or missing, no symbols loaded for pdm.dll]   
    kernel32.dll!_UnhandledExceptionFilter@4()  + 0x1c7 bytes   
    ...

查看模块加载信息：

...
'DumpFM-V235_76_1_0-20110412-153403-3612-484.dmp': Loaded '*C:\Program Files\Common Files\Microsoft Shared\VS7Debug\pdm.dll', No matching binary found.
...

我们看到这个二进制文件甚至没有加载，因为用于分析转储的机器与生成转储的机器不同。

我目前无法访问这台机器——我能以某种方式修复这个堆栈，还是我总是需要这个确切路径位置的确切二进制文件？

4

2 回答 2

1

如果您绝对想在 Visual Studio 中调试此转储，则可以将系统 DLL 从产生转储的机器复制到.dmp 文件所在的同一文件夹中。这样，它将加载这些二进制文件，而不是尝试在调试系统上与原始系统（可能包含相同模块的不同版本）相同的路径中找到它们。

不过，正如 Naveen 指出的那样，在 WinDBG 中加载转储时不会遇到这个问题（原因我还不明白）。这就是为什么当我从客户那里得到转储时，我总是在 WinDBG 中分析它们。

如果您需要有关使用 WinDBG 进行故障转储分析的帮助，以下网站包含有关该主题的信息：http ://www.dumpanalysis.org/ 。

于 2011-05-29T21:49:50.417 回答
1

另一种选择是使用来自 DebugInfo.com的ModuleRescue工具。这将扫描转储文件，允许您选择未加载符号的模块，然后生成一个假模块，其中包含足够的信息供调试器从符号服务器加载符号。

当 Visual Studio 无法加载此模块的符号并打开一个对话框要求您查找符号时，只需将您的调试器指向该假模块，它就会正确加载。

这个工具基本上和 WinDbg 做同样的事情，尽管工作流程不同。

于 2015-05-22T13:18:22.730 回答