話說月初筆者在華山之巔搞定了asp.net一起莫名奇妙的異常，自此之后和公主過著…嘟～～，不好意思，書都看雜了，串了臺了。好，咱們閑言少敘，書歸正傳。

    自從上次解決了由調試文件庫引起的ASP.NET執行異常之后，服務器一直運行的很穩定，可就在為躲過一個微軟亂擺亂放的隔離墩而回首慶幸時，心神未定，又被另一個絆了一個大馬趴，掙扎爬起，也顧不上臉上的灰土和身上的疼痛，趕緊掏出鉛筆，在密密麻麻的隔離墩示意圖上再添一筆。

    昨天下班之前項目有更新，便編譯打包后上傳到了服務器上，一切正常。早上上班，還未坐穩，辦公室便像到了中國網通總部，電話一個挨一個，急忙登錄系統，發現老主顧又來了…難道是又忘了刪除PDB文件了？登錄服務器，卻一個PDB文件也沒有找到，看來并非舊病復發，而是又添新疾啊。

    系統的服務使用了web service的remote模式和本地dll的local模式，雙模式運行，通過配置文件可以自由切換。為了便于除錯，于是將底層服務切換到local模式，登錄，果然被告知“xxx組件拒絕訪問”，之后是一些無用的調試信息。那既然是拒絕訪問，可能是用戶權限的問題，遂改之，權限放到最大，連只讀屬性都被注意到了。再次登錄，問題依舊。

    無奈，只能求助外網，到搜索引擎一打聽，好家伙！被這個墩子絆倒的還不少呢。其中一點提到了微軟的索引服務，一開始我并不認為跟這個八竿子打不著的東西有關系，可是也算是死馬當活馬醫吧，姑且一試。

    打開“計算機管理”?“系統服務”?“索引服務”，果然發現了c:/intepub被放在了編制目錄里，停止、刪除，再次編譯程序…木哈哈哈！問題解決了！

    事后絞盡腦汁，也只是得出了這么個結論：由于某種原因，索引服務數據出錯，ASP.NET在編譯的時候無法加載正確的庫信息，從而導致了代碼庫的混亂。不可靠的數據簡直就是亂擺亂放的隔離墩，防不勝防啊…