近萬次崩潰分析歸納：三大類佔比90%+
分析全球近十年近千次系統崩潰，**絕大多數屬於三類**：舊版殺毒軟體驅動、不相容存儲驅動、過多濾鏡驅動導致核心堆疊溢位。逐一拆解根因與防護鐵律。
元兇一：舊版殺毒軟體濾鏡驅動
機制
- 殺毒軟體用核心模式濾鏡驅動攔截I/O請求，對比病毒特徵庫。
- 濾鏡驅動直接與核心函數/數據結構互動，參數/類型不符 → 核心模式崩潰 (Bugcheck)。
觸發點
- OS升級（Service Pack/新版本）修改核心函數/結構，微軟測試自家驅動相容性，**不測試第三方驅動**。
- 舊版殺毒驅動遇新核心 → 崩潰。
實戰案例
Stop 0x8E KERNEL_MODE_EXCEPTION_NOT_HANDLED
!analyze -v 堆疊顯示：
buggydrv+0x13059 <-- 導致崩潰的濾鏡驅動
...
nt!NtCreateFile+0x30 <-- OS調用CreateFile
驅動日期 2006年，OS為 Windows Server 2003 SP2 (2007年發布)
→ 驅動未針對新OS測試
防護鐵律
- OS任何更新（含SP/熱修補）前，必先確認第三方殺毒/備份/加密驅動有對應更新。
- 廠商通常已將已知崩潰文檔化並發布新版，**升級驅動即可修復**。
- 善用
!lmi 驅動名 查驅動時間戳，對比OS建構日期，秒級定位版本錯配。
元兇二：不相容存儲驅動（HBA/Storport）
架構
- QLogic/Emulex/HP等廠商提供HBA驅動，**依賴微軟 Storport 驅動** 執行I/O操作。
衝突邏輯
- 廠商更新專用驅動 → 必須重測當前 Storport 版本相容性。
- 微軟更新 Storport（Win2003有50+修補） → 所有 HBA 驅動必須重測新 Storport 相容性。
- 雙向依賴，雙向風險。
診斷神器：Dependency Walker (depends.exe)
- 免費工具，載入驅動檔（如
Hpcisss2.sys）→ 顯示依賴 STORPORT.SYS + Ntoskrnl.exe，秒級確認依賴鏈。
防護鐵律
- 更新 Storport 前確認 HBA 驅動有配套更新，反之亦然。
- 建立廠商驅動發布訂閱機制，同步獲取相容性矩陣。
元兇三：濾鏡驅動過多導致核心堆疊溢位
原理
- 攔截I/O執行額外功能的驅動皆為濾鏡驅動：殺毒、磁碟配額、鏡像、備份代理等。
- 遞歸調用耗盡有限核心堆疊空間（x86=12KB, x64=24KB）→
Stop 0x7F Bugcheck 崩潰。
- **無法擴展核心堆疊**，物理架構硬限制。
診斷工具：FLTMC (濾鏡器管理器控制程式)
- 內建命令列工具，列出所有已載入濾鏡驅動實例與高度。
防護鐵律
- 審計並禁用/卸載非必要濾鏡驅動，保留核心安全/備份最小集合。
- 定期執行
fltmc filters / fltmc instances 監控濾鏡驅動數量與堆疊深度。
總結：兩大核心動作覆蓋90%風險
- 同步更新：OS/補丁更新時，強制同步第三方驅動（殺毒、HBA、備份、加密等）。
- 極簡濾鏡：僅保留業務必需的濾鏡驅動，其餘全卸載，核心堆疊留白給穩定性。
驅動相容性非一次性工程，而是持續治理。建立驅動清單、訂閱廠商通知、納入變更管理流程，將崩潰風險壓縮至最低。
