PDB全称Program Database，不知道中文翻译叫什么。相信使用过VS的人对于这个拓展名的文件不会陌生，这个文件主要会存储对应模块(dll或者exe)内部的所有符号，以及符号对应的地址、文件名和行号。
这个文件会在我们调试的时候被使用到，这个东西可以理解为调试的时候应用程序和源文件之间的一个桥梁。正是归功于这个文件，我们才能在debug的时候看到程序当前执行相对应的代码和监视到一些变量。
PDB文件什么时候产生？
PDB文件是在我们编译工程的时候产生的，它是和对应的模块(exe或dll)一起生成出来的。我们一般可能不会意识到PDB文件的重要性，因为如果只是我们本地进行开发，我们总是能够进行调适。这里我要引入两个概念：Private Build和Public Build。Private Build指的是在开发机器上的编译，Public Build指的是在负责编译的机器上的编译。
正如上面我所说Private Build一般不会有问题，因为在编译出来的机器上进行调试所有必要的文件都在该在的地方。所有大部分不能调试的问题都发生在Public Build的情况下。
如果你的应用程序需要发布或者当作产品卖得，你就需要特别注意要保存你发布出去的那个版本的PDB文件和源文件。注意：你只有一次机会保存着发布出去的PDB文件，如果你弄丢了将无法找回。<当然使用Reflector 类似的工具去调试也是可以的>
为什么PDB这么重要?
也许你会认为如果拿一份一模一样的源代码重新编译一个PDB文件，然后用来调试就行了。我也曾经这么认为过，直到有一天…......
直接的原因是因为VS生成出来的二进制文件的Header部分里面包含了它对应的PDB的GUID，PDB也包含一个GUIID，这两个GUID实在编译的时候添加进去的。VS调试器在载入PDB的时候会去比对这个两个GUID，如果不一致，那么就不能使用。
当然上面那个原因只是一个表面现象，根本原因是既是两份一模一样的代码编译器编译出来的文件可能是不一样的。因为编译器在编译的时候会对代码进行优化，而同一份代码可能会有很多种优化的方法，它会根据当时的具体机器的环境等情况选择一个最快的生成方法。所以它生成出来的文件有可能是不一样的！所以如果连生成出来的文件都不一样，那么原来的那个PDB里面的符号对应的地址也就没有意义了。
如何查看二进制文件和PDB的GUID？
使用VS自带的DUMPBIN工具可以查看二进制文件所期望的PDB的GUID。基本用法就是DUMPBIN /HEADER 文件，具体用可可参考MSDN。
查看PDB的GUID可以用下面这个工具，直接将PDB拉进去即可。http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P
PDB文件的查找策略
先上试验结果，可以再调试的时候从Visual Studio 的Module串口中查找到一个module的symbol的查找策略。从截图中我们可以看到结果如下：
1. 文件被执行或者被载入的地址
2. 就是硬编码在PE文件头中的那个地址。大家可以看到obj\<config>才是最原始生成的地址，只是之后被拷贝到了***个地址中去了。
2.5 如果配置了符号服务器，第二步以后应该先去符号服务器的缓存目录下找，如果找不到再去符号服务器上去找。找到的话就会下载到缓存目录。
3. 第三部分是我VS中设置的一些符号查询的目录，因为我装过Reflector所以默认加了这几个目录在我的设置中。
4. Windows文件夹。
这里有一个比较有意思的现象就是，VS的查找策略都是会先找一个目录下的symbol\exe\project.pdb，然后exe\project.pdb，***才找project.pdb。这个顺序有点出人意料。
PDB文件会影响性能么？
可能有些人会觉得PDB文件的生成会对最终的应用程序的性能产生一定的影响，所以觉得在发布版中不应该生成PDB文件。
错！对于.NET应用程序来说，生成PDB文件不会影响编译器的优化，所以也完全不会影响应用的性能。只会对于生成的程序集中的一个DebuggableAttribute的属性产生影响。有兴趣的人可以阅读Do PDB Files Affect Performance?
小结
因为微软并未公布PDB内部细节，只公开了一些API，所以对于这个文件一直是一个迷。本文只是写了一些我学习到的以及我觉得.net程序员有必要知道的一些知识。如果其中有不对之处望指出，以后如果有更深入了解会另外补充。
原文链接：http://www.cnblogs.com/imjustice/archive/2013/06/07/note_about_dot_net_pdb_file.html
