WinDbg 不会加载使用相同源创建但在与原始时间不同的时间构建的符号文件
我们发布了一个产品(C#.NET 库),并且没有存储该库的 pdb 文件,假设我们始终可以使用相同的源代码生成符号文件。
现在,我们要分析使用我们的库的应用程序的故障转储(小型转储)文件。 由于我们没有存储 pdb 文件,因此我使用相同的源代码(在 SVN 中使用相同的标签)创建了一个新文件。然后我尝试了WinDbg并提供了pdb文件,但调试器不喜欢它。
由于源代码是相同的,我认为唯一的区别是构建完成的日期(我们使用同一台机器进行发布)。这真的会导致调试器无法加载符号文件吗? WinDbg如何识别符号文件?
如果我确定符号文件与原始文件相同(日期除外),是否有办法强制 WinDbg 加载符号文件?
谢谢。
注意:如果我制作新版本并人为创建转储文件,则符号会正确加载。
We released a product (C#.NET library) and didn't store the pdb file of the library, assuming that we can always generate symbol files using the same source code.
Now, we want to analyze crash dump (mini dump) file of an application that is using our library.
Since we didn't store the pdb file, I created a new one using the same source code (using the same tag in SVN). Then I tried WinDbg and provided the pdb file, but the debugger didn't like it.
Since the source code is the same, I think the only difference is the date the build was done (We are using the same machine for releases). Can this really cause the debugger to not load the symbol file? How does WinDbg identify a symbol file?
If I am sure that the symbol file is identical to the original one (except the date), is there a way to force WinDbg to load the symbol file?
Thanks.
Note: If I make a new release and artificially create a dump file, symbols are loaded properly.
在不更改源的情况下进行重建将更改 pdb 文件。请参阅 John Robbins 的博客文章 PDB 文件:每个开发人员必须了解的细节。
您需要告诉 WinDbg 对准备加载的符号文件不要那么挑剔。来自(稍旧的)WinDbg 帮助文件:
此符号选项可减少符号处理程序在尝试匹配符号时的挑剔性。
该选项默认关闭。调试器运行后,可以分别使用 .symopt+0x40 或 .symopt-0x40 打开或关闭它。
Rebuilding without changing the sources will change the pdb file. See John Robbins' blog entry PDB FILES: WHAT EVERY DEVELOPER MUST KNOW for the gory details.
You need to tell WinDbg to be less picky about the symbol files it's prepared to load. From (a slightly elderly) WinDbg helpfile:
This symbol option reduces the pickiness of the symbol handler when it is attempting to match symbols.
This option is off by default. Once the debugger is running, it can be turned on or off by using .symopt+0x40 or .symopt-0x40, respectively.