任何推荐的VC ++设置，以在发行版上进行更好的PDB分析 [英] Any recommended VC++ settings for better PDB analysis on release builds
问题描述
我是否应该知道任何VC ++设置，以生成包含更多信息的更好的PDB文件?
我有一个基于项目 crashrpt 的崩溃转储分析系统./p>
此外，我的生产构建服务器在D:\上安装了源代码，但是我的开发计算机在C:\上具有了源代码.我在VC ++设置中输入了源路径，但是当浏览崩溃的调用堆栈时，它不会自动跳转到我的源代码.我相信，如果我在D:\上有我的开发机的源代码，它将可以工作.
有什么我应该了解的VC ++设置"
确保关闭框架指针Ommision.拉里·奥斯特曼(Larry osterman)的博客有关fpo和调试引起的问题.
符号已成功加载.它显示了调用栈，但是双击一个条目并不会把我带到源代码.
您使用的是哪个版本的VS? (或者您使用的是Windbg?)...在VS中，如果找不到位置，则应在第一次时明确提示输入源.但是，它还会保留未找到"来源的列表，因此它不会每次都要求您提供.有时候，不要看"列表很麻烦...要获取提示，您需要转到解决方案资源管理器/解决方案节点/属性/调试属性，然后在下部窗格中编辑文件列表.
最后，您可能会使用条形符号".这些是生成的pdb文件，用于提供调试信息，以使调用堆栈经过FPO，但去除了源位置(以及其他数据). Windows OS组件的公共符号已剥离pdbs.对于您自己的代码，这些操作只会造成痛苦，并且不值得这样做，除非您将pdbs提供给外部.您将如何拥有这些可怕的剥离式PDB中的一个?如果在-a命令中使用"binplace"，则可能会有它们.
祝你好运！适当的小型转储故事是生产调试的天赐之物.
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.
"Are there any VC++ settings I should know about"
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.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code.
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.
这篇关于任何推荐的VC ++设置，以在发行版上进行更好的PDB分析的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
