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