大家知道 500.19 是常見故障，導(dǎo)致該問題的出現(xiàn)原因有很多，如果僅是單純看錯誤摘要“無法訪問請求的頁面，因為該頁的相關(guān)配置數(shù)據(jù)無效”，是很難確定故障原因的。

　　所以我們需要將重點放在詳細(xì)錯誤信息中，以本案為例，參考下圖可看到在詳細(xì)錯誤信息中提示“模塊 DynamicCompressionModule”出現(xiàn)錯誤，錯誤代碼為“0x8007007e”。

　　檢查了 Windows Server 2012 Essentials 環(huán)境，發(fā)現(xiàn)該 ASP 程序所在網(wǎng)站也啟用了壓縮模塊，但訪問是正常的。此外在 iis.net 上找到一篇相關(guān)的帖子 http://forums.iis.net/t/1149768.aspx/1/10，貌似與 SBS2011 上集成的服務(wù)應(yīng)用有關(guān)，尤其是 WSUS，涉及文件“suscomp.dll”，suscomp.dll 是 WSUS 的專用壓縮模塊。

　　起初，gOxiA 參考帖子直接將加載的 suscomp.dll 語句注釋掉以禁用加載，之后測試 ASP 程序確實就正常了，但這樣以來就要犧牲掉 WSUS 的壓縮模塊。suscomp.dll 屬于全局類型的模塊，它根據(jù)壓縮的類型（動態(tài)或靜態(tài)）由 IIS 的 compdyn.dll 和 compstat.dll 進(jìn)行調(diào)用，所以在 IIS 管理器的站點模塊管理中也找不到對應(yīng)的配置信息，所以單獨對站點禁用該模塊是不可能的。

　　此外想單純通過禁用站點的壓縮功能也是不行的，因為相關(guān)的模塊還是被加載了，只要加載就會導(dǎo)致故障的出現(xiàn)。

　　所以要徹底解決這一故障的唯一辦法就是將對應(yīng)站點中的動態(tài)和靜態(tài)壓縮模塊全部給刪除掉，不予以加載。要直接為單獨某個站點刪除模塊，是不行的！會提示錯誤“鎖定沖突”……

　　為此，要修改 IIS 服務(wù)設(shè)置，即在 IIS 管理器里選中當(dāng)前服務(wù)器，通過內(nèi)容窗體中的“模塊”進(jìn)入其設(shè)置，找到對應(yīng)的模塊（如：DynamicCompressionModule），在任務(wù)窗體中點擊“解除鎖定”，之后才能在對應(yīng)站點中對模塊進(jìn)行刪除。

　　因為涉及到的是全局的 suscomp.dll 模塊，所以為了保證 ASP 程序正常訪問，除了要刪除 動態(tài)壓縮模塊以外，同時還要刪除靜態(tài)壓縮模塊（StaticCompressionModule）?，F(xiàn)在 ASP 程序便可正常訪問了，而且也不會影響到 WSUS 服務(wù)。