windbg 命令_4. windbg调试符号表1

我们都知道，程序根据配置不同，可以build成release和debug两个版本。一般发布出去的是release版本，相比debug版本，release版本文件小，执行快，但相对的，其携带的信息也更少。所以开发人员在遇见问题时，都会build一个debug版本去重现场景，然后通过调试器去发现root cause，进而解决问题，而其原因就是debug版本，连接器在生成*.exe和*.dll时，还会生成带有关于程序详细符号信息pdb文件(Program Debug Database)。

符号表包含很多用于debug的内容，包括详细的类型信息，函数信息(函数名称以及入口地址)，源代码行数，堆栈大小，优化信息，堆栈的信息......如果你想阅读pdb文件里面的信息，可以通过一些工具读取，比如微软自带的dbh.exe，通过执行命令""C:\Program Files(x86)\Windows Kits\10\Debuggers\x64\dbh.exe" -v demo.pdb dump",可以将pdb转化成可以阅读的文本。下图中红框的两行分别是源程序中main和fun的两个函数。关于dbh.exe更详细的用法，可以参考文档。

int fun(int x, int y){  x += y;  return x / y;}int main(){  int a = 2, b = 0;  fun(a, b);    return 0;}

为什么调试时我们需要符号表？

• 链接器创建的可执行文件不包含任何变量信息和函数名称等；

• 调试就是查看操作系统或应用程序的运行时内存；

• 同样，内存也不包含任何变量或函数信息；

• 调试器需要符号来将地址转换为名称；

所以，在调试时，调试器(windbg.exe)就像一个中介一样，可以将.exe中的内存地址与.pdb文件中的符号信息对应起来。

那pdb文件只有在构建debug版本时才创建吗？答案是NO。pdb文件在构建release版本时也会生成，只是相对debug版本，信息不太全面而已，但还是很重要的。

想象下，你的release版本遇见crash问题，如果用debug版本重现问题会非常耗时，而你需要快速定位问题，或者至少有相对正确的猜想和怀疑位置。此时，你可以直接将源代码attach到release版本，crash时你可以看到call stack(函数名)，虽然没法查看源代码，但有了关注的位置，再用debug版本去查看具体的内存信息，解决问题就会快速很多。