任何推荐的 VC++ 在发布版本上更好地进行 PDB 分析的设置
我是否应该了解任何 VC++ 设置才能生成包含更多信息的更好的 PDB 文件？
我有一个基于 crashrpt 项目的故障转储分析系统。
另外，我的生产构建服务器将源代码安装在 D:\ 上，但我的开发计算机将源代码安装在 C:\ 上。 我在VC++设置中输入了源路径，但是当查看崩溃的调用堆栈时，它不会自动跳转到我的源代码。 我相信如果我的开发机器的源代码位于 D:\ 上，它就可以工作。
Are there any VC++ settings I should know about to generate better PDB files that contain more information?
I have a crash dump analysis system in place based on the project crashrpt.
Also, my production build server has the source code installed on the D:\, but my development machine has the source code on the C:\. I entered the source path in the VC++ settings, but when looking through the call stack of a crash, it doesn't automatically jump to my source code. I believe if I had my dev machine's source code on the D:\ it would work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
确保关闭帧指针省略。 Larry osterman 的博客包含有关 fpo 和调试时引起的问题。
你用的VS是什么版本？ （或者你正在使用Windbg？）...在VS中，如果找不到位置，它应该第一次提示输入源。 然而，它还保留了“未找到”的源列表，因此它不会每次都要求您提供。 有时，不查看列表很痛苦......要恢复提示，您需要转到解决方案资源管理器/解决方案节点/属性/调试属性并编辑下部窗格中的文件列表。
最后，您可能会使用“剥离符号”。 这些是生成的 pdb 文件，用于提供调试信息以供调用堆栈经过 FPO，但源位置被删除（以及其他数据）。 Windows 操作系统组件的公共符号被剥离 pdb。 对于您自己的代码来说，这些只会造成痛苦并且不值得，除非您将 pdb 提供给外部。 你怎么会拥有这些可怕的剥离的 pdb 之一？ 如果您将“binplace”与 -a 命令一起使用，您可能会拥有它们。
祝你好运！ 适当的迷你转储故事是生产调试的天赐之物。
Make sure you turn off Frame pointer ommision. Larry osterman's blog has the historical details about fpo and the issues it causes with debugging.
What version of VS are you using? (Or are you using Windbg?) ... in VS it should defintely prompt for source the first time if it doesn't find the location. However it also keeps a list of source that was 'not found' so it doesn't ask you for it every time. Sometimes the don't look list is a pain ... to get the prompt back up you need to go to solution explorer/solution node/properties/debug properties and edit the file list in the lower pane.
Finally you might be using 'stripped symbols'. These are pdb files generated to provide debug info for walking the callstack past FPO, but with source locations stripped out (along with other data). The public symbols for windows OS components are stripped pdbs. For your own code these simply cause pain and are not worth it unless you are providing your pdbs to externals. How would you have one of these horrible stripped pdbs? You might have them if you use "binplace" with the -a command.
Good luck! A proper mini dump story is a godsend for production debugging.
如果您直接从源代码管理系统构建，则应该使用文件来源注释 pdb 文件。 这允许您在调试时自动获取准确的源文件。 （这与检索 .Net 框架源代码的过程相同）。
请参阅 http://msdn.microsoft.com/en-us/magazine/cc163563 .aspx 了解更多信息。 如果您使用 Subversion 作为 SCM，您可以查看 SourceServerSharp 项目。
If your build directly from your sourcecode management system, you should annotate your pdb files with the file origins. This allows you to automatically fetch the exact source files while debugging. (This is the same proces as used for retrieving the .Net framework sourcecode).
See http://msdn.microsoft.com/en-us/magazine/cc163563.aspx for more information. If you use subversion as your SCM you can check out the SourceServerSharp project.
您可以尝试使用 MS-DOS subst 命令将源代码目录分配到 D:驾驶。
You could trying using the MS-DOS subst command to assign your source code directory to the D: drive.
这是我在经历了与您类似的麻烦后使用的过程：
a）将所有 EXE 和 EXE 复制到生产服务器 构建的 DLL 文件，每个文件都有相应的 PDB 到同一目录，启动系统，然后等待崩溃发生。
b) 复制回所有 EXE、DLL 和 PDB 文件与小型转储（在同一文件夹中）一起传输到开发计算机（到临时文件夹）。 使用 Visual Studio 从该文件夹加载小型转储。
由于 VS 找到了最初编译它们的源文件，因此它总是能够识别它们并正确加载它们。 与您一样，在生产计算机中使用的驱动器不是 C:，但在开发计算机中是。
还有两个提示：
我经常做的一件事是复制重建的 EXE/DLL，却忘记复制新的 PDB。 这破坏了调试周期，VS 将无法向我显示调用堆栈。
有时，我会得到一个在 VS 中没有意义的调用堆栈。 经过一番头痛之后，我发现 Windbg 总是会向我显示正确的堆栈，但 VS 通常不会。 不知道为什么。
This is the procedure I used after some trouble similar to yours:
a) Copied to the production server all the EXE & DLL files that were built, each with its corresponding PDB to the same directory, started the system, and waited for the crash to happen.
b) Copied back all the EXE, DLL & PDB files to the development machine (to a temporary folder) along with the minidump (in the same folder). Used Visual Studio to load the minidump from that folder.
Since VS found the source files where they were originally compiled, it was always able to identify them and load them correctly. As with you, in the production machine the drive used was not C:, but in the development machine it was.
Two more tips:
One thing I did often was to copy an EXE/DLL rebuilt and forget to copy the new PDB. This ruined the debug cycle, VS would not be able to show me the call stack.
Sometimes, I got a call stack that didn't make sense in VS. After some headache, I discovered that windbg would always show me the correct stack, but VS often wouldn't. Don't know why.
如果有人感兴趣，一位同事通过电子邮件回复了我这个问题：
Artem 写道：
In case anyone is interested, a co-worker replied to this question to me via email:
Artem wrote:
Visual Studio 是否提示您输入源文件的路径？ 如果不是，那么它认为它没有调用堆栈的符号。 设置源路径应该可以工作，而无需映射确切的原始位置。
您可以通过查看 Visual Studio 中的“模块”窗口来判断符号是否已加载。
假设您正在构建 PDB，那么我认为没有任何选项可以直接控制 PDB 中的信息量。 您可以更改编译器执行的优化类型以提高可调试性，但这会降低性能 - 正如您的同事指出的那样，禁用内联将有助于使崩溃文件中的事情变得更加明显，但会在运行时产生成本。
根据您的应用程序的性质，如果可以的话，我建议您使用完整转储文件，它们更大，但会为您提供有关该进程的所有信息......以及它崩溃的频率:)
Is Visual Studio prompting you for the path to the source file? If it isn't then it doesn't think it has symbols for the callstack. Setting the source path should work without having to map the exact original location.
You can tell if symbols are loaded by looking at the 'modules' window in Visual Studio.
Assuming you are building a PDB then I don't think there are any options that control the amount of information in the PDB directly. You can change the type of optimizations performed by the compiler to improve debuggabilty, but this will cost performance -- as your co-worker points out, disabling inline will help make things more obvious in the crash file, but will cost at runtime.
Depending on the nature of your application I would recommend working with full dump files if you can, they are bigger, but give you all the information about the process ... and how often does it crash anyway :)
不。
符号已成功加载。 它显示了调用堆栈，但是双击某个条目不会将我带到源代码。 我当然可以在文件中搜索有问题的行，但这是一项艰苦的工作:)
No.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code. I can of course search in files for the line in question, but this is hard work :)