话说月初笔者在华山之巅搞定了asp.net一起莫名奇妙的异常，自此之后和公主过着…嘟～～，不好意思，书都看杂了，串了台了。好，咱们闲言少叙，书归正传。

    自从上次解决了由调试文件库引起的ASP.NET执行异常之后，服务器一直运行的很稳定，可就在为躲过一个微软乱摆乱放的隔离墩而回首庆幸时，心神未定，又被另一个绊了一个大马趴，挣扎爬起，也顾不上脸上的灰土和身上的疼痛，赶紧掏出铅笔，在密密麻麻的隔离墩示意图上再添一笔。

    昨天下班之前项目有更新，便编译打包后上传到了服务器上，一切正常。早上上班，还未坐稳，办公室便像到了中国网通总部，电话一个挨一个，急忙登录系统，发现老主顾又来了…难道是又忘了删除PDB文件了？登录服务器，却一个PDB文件也没有找到，看来并非旧病复发，而是又添新疾啊。

    系统的服务使用了web service的remote模式和本地dll的local模式，双模式运行，通过配置文件可以自由切换。为了便于除错，于是将底层服务切换到local模式，登录，果然被告知“xxx组件拒绝访问”，之后是一些无用的调试信息。那既然是拒绝访问，可能是用户权限的问题，遂改之，权限放到最大，连只读属性都被注意到了。再次登录，问题依旧。

    无奈，只能求助外网，到搜索引擎一打听，好家伙！被这个墩子绊倒的还不少呢。其中一点提到了微软的索引服务，一开始我并不认为跟这个八竿子打不着的东西有关系，可是也算是死马当活马医吧，姑且一试。

    打开“计算机管理”“系统服务”“索引服务”，果然发现了c:\intepub被放在了编制目录里，停止、删除，再次编译程序…木哈哈哈！问题解决了！

    事后绞尽脑汁，也只是得出了这么个结论：由于某种原因，索引服务数据出错，ASP.NET在编译的时候无法加载正确的库信息，从而导致了代码库的混乱。不可靠的数据简直就是乱摆乱放的隔离墩，防不胜防啊…