下面讓我們來細致看一下這三種服務器系統崩潰的詳細，并辨別簡介一下防止它們的最好方法。
殺毒軟件
到當前為止，最罕見的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年揭曉的。如今我們就知曉，舊版的殺毒驅動順序并沒有對新版的操作系統實行測試。
在這個例子中，此種系統崩潰曾經被廠商標識為已知疑問并文檔化，新版殺毒軟件曾經能夠用來防止系統崩潰。真實上，絕大非少數你遇到的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。
過多的過濾驅動
第三種最罕見的Windows Server崩潰類型與安裝了太多的過慮驅動時的堆棧溢出條件相關。任何能夠阻攔I / O懇求并執行額定功用的驅動順序都被以為是一個過濾驅動。我們曾經知曉，殺毒驅動順序就是一個過濾驅動。其它過慮驅動包括硬盤配額維護、硬盤鏡像和備份代理等，在這里我只列舉了多個。
雖然安裝多個過濾驅動本身不會有疑問，但是在當這些驅動順序以遞歸的方式相互調用并因此耗盡了有限的內核堆棧空間時，狀況就會發作改動。依據計算機體系結構（(x86=12 KB，x64=24 KB），一切裝備驅動順序運用的內核堆棧空間是有限的。當內核堆棧空間耗盡時，就會呈現一個Stop 0x7F bugcheck導致系統崩潰，就像微軟數百篇文檔的描述一樣。
基本沒有方法提供額定的內核堆棧空間來容納更多的過慮驅動。獨一的挑選是辨認這些過濾驅動，禁用或卸載其中不須要的那些。有一個內置在Windows Server操作系統中的工具叫FLTMC（過濾器維護器控制順序），它能夠讓你辨認出安裝的過濾驅動。
正如你看到的，有許多原由會導致Windows Server崩潰。但是絕大非少數服務器停機都是由上述的原由構成的。你完全能夠議決兩種方式處理這些疑問，它們是在升級Windows操作系統或更新相關的熱修補順序的同時更新第三方驅動順序和限定未運用的過濾驅動的數目。
