在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.
...
我们看到这个二进制文件甚至没有被加载，因为用于分析转储的机器与生成转储的机器不同。
我目前无法访问这台其他机器 - 我可以以某种方式修复此堆栈，还是在这个确切的路径位置始终需要精确的二进制文件？
答案 0 :(得分：1)
如果您绝对想在Visual Studio中调试此转储，则可以将系统DLL从生成转储的计算机复制到.dmp文件的同一文件夹中。这样，它将加载这些二进制文件，而不是试图在调试系统上的相同路径中找到它们，就像它们在原始系统上一样（可能包含相同模块的不同版本）。
正如Naveen指出的那样，在WinDBG中加载转储时你不会遇到这个问题（原因我还没有理解）。这就是为什么当我从客户端获得转储时，我总是在WinDBG中分析它们。
如果您需要有关使用WinDBG进行故障转储分析的帮助，以下网站上有关于该主题的信息：http://www.dumpanalysis.org/。
答案 1 :(得分：1)
另一个选择是使用DebugInfo.com上的人员的ModuleRescue工具。这将扫描转储文件，允许您选择未加载符号的模块，然后生成一个伪模块，其中包含足够的信息，以便调试器从符号服务器加载符号。
当Visual Studio无法加载此模块的符号并打开一个要求您查找符号的对话框时，只需将调试器指向该假模块即可正确加载。
这个工具基本上和WinDbg做的一样，虽然工作流程不同。