Windows Server崩潰的三大常見誘因與避免方式
Windows Server崩潰的方式有很多種，但絕大多數都屬于三大類：舊版殺毒軟件、不兼容的存儲驅動程序和過多的過濾驅動。在分析了來自世界各地近十年差不多1000次的系統崩潰后，我可以確認這些都是你想要避免的隱患。
下面讓我們來詳細看一下這三種服務器系統崩潰的細節，并分別介紹一下避免它們的最佳方法。
殺毒軟件
到目前為止，最常見的Windows Server崩潰是由舊版殺毒軟件所致。所有的殺毒軟件都是使用設備驅動程序，更具體地說是“過濾驅動”來攔截I / O（讀/寫）請求并執行額外的檢查。殺毒軟件驅動程序將檢查的內容與已知的病毒定義文件進行對比，以確保沒有感染病毒。
過濾驅動包含內核模式的代碼，它們會與操作系統底層的內核函數和數據結構相互作用這些函數和數據結構包括那些預期會在相應設備驅動調用時呈現的預定義參數和數據類型。如果函數傳遞的數據類型錯誤或參數數目不對，就會發生導致內核模式中系統崩潰的錯誤。
當開發人員在不同版本的操作系統之間（如服務包更新或新版本操作系統發布）修改這些內核函數或數據結構時，問題就出現了。雖然微軟在測試設備驅動程序對所有操作系統改變的兼容性方面做得很好，但它顯然沒有測試第三方設備驅動程序來確保它們可兼容。因此，當舊版殺毒驅動程序偶然遭遇了這些更改，最終就會導致系統崩潰。其它過濾驅動也容易受到這種問題影響，但是殺毒軟件驅動程序是最容易受影響的一個。
讓我們來看一個例子：
下面是一個Stop 0x8E bugcheck -KERNEL_MODE_EXCEPTION_NOT_HANDLED的系統崩潰。在Windows debugger中用命令!analyze –v顯示了它的堆棧模式。從下往上讀，我們就看到一個NtCreateFile的函數調用，最終引入了buggydrv，從而導致bugcheck。使用命令!lmi buggydrv可以顯示出驅動程序的日期是2006年，而操作系統Windows Server 2003 SP2是2007年發布的。現在我們就知道，舊版的殺毒驅動程序并沒有對新版的操作系統進行測試。
nt!KeBugCheckEx+0x1b nt!KiDispatchException+0x3a2 nt!CommonDispatchException+0x4a nt!Kei386EoiHelper+0x186 buggydrv+0x13059 <--導致系統崩潰的過濾驅動 buggydrv+0x8390 buggydrv+0x8809 buggydrv+0x2940 nt!IofCallDriver+0x45 nt!IopParseDevice+0xa35 nt!ObpLookupObjectName+0x5b0 nt!ObOpenObjectByName+0xea nt!IopCreateFile+0x447 nt!IoCreateFile+0xa3 nt!NtCreateFile+0x30 <--操作系統調用CreateFile nt!KiFastCallEntry+0xfc
在這個例子中，此種系統崩潰已經被廠商標識為已知問題并文檔化，新版殺毒軟件已經可以用來避免系統崩潰。事實上，絕大多數你遇到的Windows Server崩潰，都曾在別人身上發生過，它們的解決方法通常已經記錄在互聯網上的某個地方。因此，很重要的一點是，一定要記住即使只是一個服務包更新。在更新操作系統時也該第一時間與第三方廠商確認是否有相應的軟件更新。
存儲驅動程序不兼容
另一種最常見的系統崩潰是由不兼容的存儲驅動程序所致。如你所知，第三方存儲廠商提供設備驅動程序來控制它們的主機總線適配器（HBA）并用于訪問存儲設備。像Qlogic、Emulex和惠普（HP）等廠商都有不同的設備驅動程序，但它們都依賴于微軟的Storport驅動程序。Storport驅動程序提供一套通用程序，這些特定的廠商驅動程序在執行I / O操作時使用它們。
這種問題的出現方式與殺毒軟件驅動程序的不兼容性很相似。當廠商修改其專用的驅動程序時，它們必須重新與當前版本的Storport進行測試，以確保仍然兼容。同樣的道理，當更新Storport版本時，所有的HBA驅動程序也必須重新測試，以保證它們仍然與新版的Storport驅動程序兼容。在Windows Server 2003中當你需要考慮Storport的50多個修補程序時，這才是一個真正的挑戰。
經驗法則是，在更新Storport驅動之前與你的第三方廠商確認HBA驅動程序是否有相應的更新，反之亦然。如何才能知道哪個存儲驅動程序依賴于Storport？幸運的是，有一個叫Dependency Walker（depends.exe）的免費工具，可以揭示驅動程序間的依賴關系。
下載并解壓縮后，運行depends.exe，使用文件下拉菜單選擇你所關注的驅動程序。在這個例子中，我選擇了驅動程序Hpcisss2.sys，它應用于HP的磁盤陣列。正如你下面可以看到的，該工具顯示，驅動程序Hpcisss2依賴于STORPORT.SYS和Ntoskrnl.exe。
圖一：Dependency Walker
過多的過濾驅動
第三種最常見的Windows Server崩潰類型與安裝了太多的過慮驅動時的堆棧溢出條件相關。任何可以攔截I / O請求并執行額外功能的驅動程序都被認為是一個過濾驅動。我們已經知道，殺毒驅動程序就是一個過濾驅動。其它過慮驅動包括磁盤配額管理、磁盤鏡像和備份代理等，在這里我只列舉了幾個。
雖然安裝多個過濾驅動本身不會有問題，但是在當這些驅動程序以遞歸的方式相互調用并因此耗盡了有限的內核堆棧空間時，情況就會發生改變。根據計算機體系結構（(x86=12 KB，x64=24 KB），所有設備驅動程序使用的內核堆棧空間是有限的。當內核堆棧空間耗盡時，就會出現一個Stop 0x7F bugcheck導致系統崩潰，就像微軟數百篇文檔的描述一樣。
根本沒有辦法提供額外的內核堆棧空間來容納更多的過慮驅動。唯一的選擇是識別這些過濾驅動，禁用或卸載其中不需要的那些。有一個內置在Windows Server操作系統中的工具叫FLTMC（過濾器管理器控制程序），它可以讓你識別出安裝的過濾驅動。
圖二：FLTMC工具
正如你看到的，有很多原因會導致Windows Server崩潰。但是絕大多數服務器停機都是由上述的原因造成的。你完全可以通過兩種方式解決這些問題，它們是在升級Windows操作系統或更新相關的熱修補程序的同時更新第三方驅動程序和限制未使用的過濾驅動的數量。
原文：http://www.searchsv.com.cn/showcontent_44896.htm
【編輯推薦】
