微软符号服务器_NT_SYMBOL_PATH给VS调试带来的隐藏坑

昨天我碰到一个非常坑的问题，问题是这样的：

我机子上已经装了vs2015和vs2010，vs2010和vs2015都跑得很溜，没有啥异常现象。然后昨天我不知哪里来的突然想法：机子上有些资源需要打包收藏，便于后面自己使用。于是乎我就安装了vs2008，分别是以下几个文件

vs2008安装包示意图

安装顺序如图上所标。安装过程中倒是自己做了一些偷工减料：就是我打开着vs2010正在写代码，同时在安装vs2008，这时候在安装过程中就会提示我vs需要关闭，此时我再去选择关闭，但是一旦提示过后我又偷偷打开了vs2010，咳，因为安装过程实在太久了。好，就这样安装了2008，之后我就继续开始调试我的代码了。神奇的一幕就发生了：

我的vs2010突然之间加载pdb非常慢。表现是我通过ide界面上的debug按钮点击调试，程序启动，就当加载到每个dll的时候，程序就卡住了，而且是卡在了加载本地dll。你说嘛，要是加载windows dll卡住也就算了，因为我确实配置了windows符号svr来拉取。但是一会想也不对啊，windows所有本地的符号我都是拉取过的，之前一直都没有这个问题，怎么会现在突然有这个问题呢，更何况是在加载本地的dll的时候卡住的，更是想不通啊！！我转念一想，是不是vs此时怪异抽筋啊，于是乎我想起了几个绝招，绝招中的绝招：vs重启，电脑重启。但是残酷的现实告诉我仍然是无效。算呢，可能是今天电脑怪异，硬盘说来也跑了很多天了，明天再来吧。

第二天我过来，问题仍然依旧。这回真没有办法了，得硬着头皮搞啊，要不没有办法干活啊，于是乎我重现了现场，拿起我的windbg来进行attach跟踪，得到如下堆栈

windbg跟踪vs加载符号卡死堆栈

基本上确定是在vsdebug.dll里面执行UpdateInfo卡住了，而且是卡在了sta网络com调用，com调用啊，既激动有懊恼，激动的是刚好最近在深入com底层了解，懊恼的是还是不知道为什么。好吧，我已经是穷途末路，找了同事一起来看看，最终我们根据汇编定位到是在等待一堆的event事件回来，但仍然是无果，因为也解决不了问题。就这样上午仍然无果

下午了，实在没有办法了，只能慢慢等吧。不甘心，于是乎死马当活马医，卸载vs2008，反正目前来看定位是昨天装完2008是不是安装过程不标准，或者2008在我这个机子上有问题导致的，毕竟是装完后出现的，但是黄天总是喜欢开欢笑，仍然卸了又泄，把windows更新都卸载了，依然无果。算了，算了，进行第二步定位：

是不是工程有问题，是不是只有vs2010有问题，从这两步去定位

1、我新建一个简单工程，mfc的，试了，跑得很溜啊，尼玛，难道是我的工程自己出的问题。好吧，突然想起之前邪恶的ncb和suo文件，于是乎把他们删除了，问题依旧。是不是我的工程太旧太古老了，生成了一堆垃圾后工程被损坏了问题，于是我重新编译了另一个工程，尼玛，仍然问题依旧。没辙，没有办法怀疑工程吧

2、使用2015来编译试试，此时一个转机出现

vs2015拉取微软将服务器符号示意图

此时的我瞬间恍然大悟，尼玛，

1、原来他任何时候都在从windows服务器加载

2、windows符号本地有了还仍然去svr查找

3、微软服务器符号加载如此之慢，竟然有时快有时慢！！！

好吧，坑了我一天的恶心bug，只要去除掉全局变量中的全局微软符号svr配置，即可

 

从这里我得出了两个教训：

1、以后别再相信_NT_SYMBOL_PATH这个符号的可靠性了，微软符号服务器有时好有时坏这个才是最大的坑(事实证明不是这个问题，我得出了错误的结论)

2、一定要随手准备一个网络监听工具包，随时观测来自网络的坑爹等待

 

补注：后和同事沟通，是symsrv.dll有些版本有bug，目前得知的情况是只有6.2这个版本才是好的，其他版本有bug
 

symsrv.dll6.2版本

导致了这个问题有些情况下会出现有些情况下不会出现，

我出问题的版本是
vs2015随身带的版本

symsrv.dll2015版本

vs2010随身带的版本

作者：fishmai0
链接：https://www.jianshu.com/p/bd82ba4f0a1a
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。