Windbg - 检测故障转储所需的符号

发布于 2024-08-08 03:49:37 字数 160 浏览 5 评论 0原文

我有一个故障转储文件,需要使用 Windbg 对其进行分析以运行一些测试。

由于一些限制我无法发表评论,我的符号文件夹只能包含分析此故障转储所需的符号。

有没有办法知道转储所需的确切符号?如果有帮助,我可以首先在所有符号可用的另一个环境中分析此转储。

谢谢。

I have a crash dump file that I need to analyze using windbg to run some tests.

Due to some restrictions I can't comment, my symbols folder can only contain the symbols needed to analyze this crash dump.

Is there a way to know the exact symbols needed by a dump? If it helps, I can first analyze this dump in another environment where all the symbols are available.

Thank you.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

一页 2024-08-15 03:49:37

您可以使用 !sym Noise 使 Windbg 转储出它需要和查找的符号。
如果您设置带有本地缓存​​的符号路径,Windbg 将仅将所需的符号下载到本地缓存路径。
如果您在计算机上加载转储,强制它加载所有符号,lml 命令将显示所有加载的符号,您可以看到加载符号的每个模块,仅复制那些 pdb 文件进入您的目标受限环境。

You can use !sym noisy to make Windbg dump out the symbol it needs and looks for.
If you set up a symbol path with a local cache, Windbg will download into the local cache path only the needed symbols.
If you load the dump on your machine, force it to load all the symbols, the lml command will show all loaded symbols and you can see each module where it loaded the symbols from, copy only those pdb files into your target restricted environment.

无人接听 2024-08-15 03:49:37

我不完全确定这是否可能。分析转储是一个动态过程,但您正在寻找静态解决方案。除非您已经知道问题是什么,否则不可能知道需要什么符号。因此不可能知道需要哪组符号。

即使做一些简单的事情,比如“我只会为堆栈上有帧的 DLL 提供符号”也是不够的。内存损坏或 DLL 中不在堆栈上的全局变量可能会影响程序的行为。忽略该 DLL 的符号可能会妨碍问题的诊断。

一种可以产生不错结果的方法如下:

  • 在所有符号都可用的环境中加载转储
  • 将符号路径设置为目录
  • 运行“analyze -v”
  • 此时转储模块的状态并包含任何符号Windbg 为其加载符号的 DLL。

I'm not entirely sure if this is possible. Analyzing a dump is a dynamic process but you're looking for a static solution. It's not possible to know what symbols will be needed unless you already know what the problem is. Therefore it's not possible to know what set of symbols will be needed.

Even doing something as simple as saying that "I will only provide symbols for the DLL's which have frames on the stack" is not enough. It's possible that memory corruption or a global variable from a DLL not on the stack could influence the behavior of the program. Leaving symbols for that DLL out could prevent diagnosis of a problem.

One approach though which will yield decent results would be the following

  • Load up the dump in the environment where all symbols are available
  • Set the symbol path to the directory
  • run "analyze -v"
  • Dump the state of modules at this point and include symbols for any DLL for which windbg loaded symbols.
等风也等你 2024-08-15 03:49:37

您还可以使用以下命令:

lml

运行“analyze -v”后显示WinDbg加载或尝试加载哪些符号。

You can also use the command:

lml

after running "analyze -v" to display which symbols WinDbg loaded or attempted to load.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文