事后崩溃转储调试没有在Symbol Server中具有Windows DLL的确切版本

前端之家收集整理的这篇文章主要介绍了事后崩溃转储调试没有在Symbol Server中具有Windows DLL的确切版本前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在我的应用程序中,我使用MiniDumpWriteDump函数(请参阅dbghelp.dll)在应用程序崩溃时编写崩溃转储文件.

我还使用符号服务器来存储我的所有可执行文件和pdb文件,这样每当客户向我发送崩溃转储文件时,调试器会自动获取正确版本的可执行文件和调试信息.

我还将Windows DLL(ntdll.dll,kernel32.dll,…)及其调试信息存储在符号服务器中(使用SymChk).调试信息从Microsoft的公共符号服务器获取.

大部分时间这种方法都很完美,除非:

>客户在其中一个Windows DLL中崩溃
>并且客户使用我没有放入符号服务器的DLL

这是因为在Symbol Server中存储每个Windows DLL的每种风格都是完全无法解决的(特别是每周补丁).

因此,如果客户崩溃,比如NTDLL.DLL的5.2.123.456版本,我没有将这个DLL的确切版本放在我的符号服务器中,那么我就卡住了.甚至微软的公共符号服务器也无济于事,因为它只提供调试信息,而不是DLL本身.

我目前的解决方案是向客户询问他的DLL,但这并不总是那么容易.因此,我正在寻找更好的解决方案.

有没有办法让调试器显示正确的调用堆栈,或加载特定DLL的调试信息,即使您没有DLL的确切版本?

或者,有没有办法获得所有(或重要的)Windows DLL(来自Microsoft)的所有版本?

编辑:

与此同时,我发现了解决这个问题的一种非常简单的方法.
使用实用程序ModuleRescue(请参阅http://www.debuginfo.com/tools/modulerescue.html),您可以从minidump文件生成虚拟DLL.使用这些虚拟DLL,调试器得到满足,并正确地开始从Microsoft服务器加载调试符号.

解决方法

可以放松WinDbg的符号分辨率;看到我的 answer到类似的问题.另一方面,我在这里提出的解决方案依赖于这样的事实:除了具有标识其调试符号的不同GUID之外,DLL是相同的.不同版本的DLL可能会有不同的二进制文件,因此即使您可以加载它们,符号也可能无法正确匹配.

猜你在找的Windows相关文章