前幾天同事突然跟我求救，原本可以執行的 ASP 程式（你沒看錯，是ASP）在移到新的伺服器後突然不能用了，這樣一來在線上的應用程式全都無法使用，要我去一趟客戶那裡看是有什麼問題，隔天到了客戶那裡後，同事操作了一下重現問題，發現原本 ASP 程式可以收到 request 的內容，但移到新機後，request 全變空白了...
Bug 逃走中，我們將扮演獵人，追捕躲在程式角落或是各種不同問題內的 bug (不論是程式中的 bug 或是無法讓程式正常運作的，都是 bug)~
前幾天同事突然跟我求救，原本可以執行的 ASP 程式（你沒看錯，是ASP）在移到新的伺服器後突然不能用了，這樣一來在線上的應用程式全都無法使用，要我去一趟客戶那裡看是有什麼問題，隔天到了客戶那裡後，同事操作了一下重現問題，發現原本 ASP 程式可以收到 request 的內容，但移到新機後，request 全變空白了。
當下我想到的問題，可能是 Proxy Server 把內容清掉了，不過同事回報說內部並沒有使用 Proxy，後來我看了一下 IIS 本身的設定 (IIS6)，但一切都正常，沒有任何過濾器或是授權的問題。後來我就詢問同事是否有直接由 request 來接值，同事說直接用 request 接值都正常，但系統本身的 request 都是空值 (這隻 bug 還真會躲)。
這點頗令人玩味，為什麼直接用 request 接值是正常的？接著我就調查了一下有問題的程式的 ASP 程式碼，發現所有的 request 都被一支 3-party component (第三方元件) 攔下來處理了，但同事回報說新機上也有這個元件，可是既然有元件為什麼還會錯？因此我接著調查了元件的版本，發現原本使用的版本是 v3.0，但新機上的元件是 v2.6。
註：COM 元件的版本基本上是可以浮動的，只要元件本身的 COM 介面沒有異動，那麼用戶端程式也不需異動。
我當下判斷可能元件版本會影響程式，所以我要求同事跟客戶要原本使用的 v3.0 版本的元件，手動登錄後再次執行，結果程式就恢復正常了 (我還發現有漏掉的元件，在補上後使用該元件的程式就正常了)。
這次的經驗告訴我們，部署 Web 應用程式 (尤其是像 asp 這種) 除了自己本身的程式碼外，也要注意程式本身是否有用到其他的 3rd party 元件以及其版本，以避免部署後發生莫名奇妙且很難查的異常狀況 ...
Bug 捕獲，Case Closed!