我是否应该了解任何VC ++设置，以生成包含更多信息的更好的PDB文件？

我有一个基于项目crashrpt的故障转储分析系统。

另外，我的生产构建服务器的D：\上安装了源代码，但是我的开发机器的C：\上具有了源代码。我在VC ++设置中输入了源路径，但是当浏览崩溃的调用堆栈时，它不会自动跳转到我的源代码。我相信，如果我在D：\上有我的开发机的源代码，它将可以工作。

解决方案

回答

我们可以尝试使用MS-DOS subst命令将源代码目录分配给D：驱动器。

回答

如果有人感兴趣，一位同事通过电子邮件向我答复了这个问题：

阿尔特姆写道：

There is a flag to MiniDumpWriteDump()
  that can do better crash dumps that
  will allow seeing full program state,
  with all global variables, etc. As for
  call stacks, I doubt they can be
  better because of optimizations...
  unless you turn (maybe some)
  optimizations off.
  
  Also, I think disabling inline
  functions and whole program
  optimization will help quite a lot.
  
  In fact, there are many dump types,
  maybe you could choose one small
  enough but still having more info
  http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
  
  Those types won't help with call stack
  though, they only affect the amount of
  variables you'll be able to see.
  
  I noticed some of those dump types
  aren't supported in dbghelp.dll
  version 5.1 that we use. We could
  update it to the newest, 6.9 version
  though, I've just checked the EULA for
  MS Debugging Tools -- the newest
  dbghelp.dll is still ok to
  redistribute.

回答

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.

符号已成功加载。它显示了调用栈，但是双击一个条目并不会把我带到源代码。我当然可以在文件中搜索有问题的行，但这是艰苦的工作:)

回答

"Are there any VC++ settings I should know about"

确保关闭框架指针Ommision。拉里·奥斯特曼(Larry osterman)的博客提供了有关fpo及其调试问题的历史详细信息。

Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code.

我们正在使用哪个版本的VS？ (或者我们使用的是Windbg？)...在VS中，如果找不到位置，则应在第一次时明确提示输入源。但是，它还会保留"未找到"来源的列表，因此不会每次都询问我们。有时候，"不要看"列表很麻烦...要获取提示，我们需要转到解决方案资源管理器/解决方案节点/属性/调试属性，然后在下部窗格中编辑文件列表。

最后，我们可能会使用"条形符号"。这些是生成的pdb文件，以提供调试信息以使调用堆栈经过FPO，但去除了源位置(以及其他数据)。 Windows OS组件的公共符号已剥离pdbs。对于我们自己的代码，这些代码只会造成痛苦，并且不值得这样做，除非我们将pdbs提供给外部。我们将如何拥有这些可怕的剥离式PDB中的一个？如果在-a命令中使用" binplace"，则可能会有它们。

祝你好运！适当的小型转储故事是生产调试的天赐之物。

回答

如果我们是直接从源代码管理系统构建的，则应使用文件来源注释pdb文件。这使我们可以在调试时自动获取确切的源文件。 (这与检索.Net Framework源代码所使用的过程相同)。

有关更多信息，请参见http://msdn.microsoft.com/zh-cn/magazine/cc163563.aspx。如果将subversion用作SCM，则可以签出SourceServerSharp项目。

回答

这是我在遇到类似麻烦之后使用的过程：

a)将所有已构建的EXE和DLL文件复制到生产服务器，每个文件都具有对应的PDB到同一目录，启动系统，并等待崩溃发生。

b)将所有EXE，DLL和PDB文件连同minidump(在同一文件夹中)一起复制回开发计算机(到临时文件夹)。使用Visual Studio从该文件夹加载minidump。

由于VS在原始文件中找到了源文件，因此它始终能够识别并正确加载它们。与我们一样，在生产机器中使用的驱动器不是C :，而在开发机器中使用的驱动器是。

另外两个提示：

• 我经常做的一件事是复制重建的EXE / DLL，而忘记复制新的PDB。这破坏了调试周期，VS无法向我展示调用堆栈。
• 有时，我得到了在VS中没有意义的调用堆栈。经过一番头痛之后，我发现windbg总是会向我显示正确的堆栈，而VS通常不会。不知道为什么。