有可能與某些系統服務有關，所以，將B中的DNS、DHCP等服務關閉，因為這些服務會與故障服務器通訊同步，或者進行某種查詢。更進一步地，將服務器和B服務器上的文件跨網絡定時復制備份等功能刪除。
三、從微軟的網站找到有關病毒也會引發類似故障的說明（相關網址），按說明查詢後排除可能性，然後，再檢查可疑的設備驅動，也未發現任何可疑之處。另外，通過查詢防火牆日志，在19：03前也未發現有異常的攻擊事件。
四、通過網絡上上報的事故報告（相關網址）中提到Symantec的版本有關，在Symantec的技術支持網站看到相類似的報告。考慮到離最近的故障時間登錄者是B服務器，而我們的B服務器上恰恰安裝了Symantec的10.0版，懷疑與故障服務器上的9.0版在升級病毒庫時產生了沖突，所以將B上的Symantec殺毒軟件刪除，然後安裝了一個客戶端，由故障服務器統一管理。
進一步分析
用WinDbg對系統崩潰時的內存Dump文件分析，發現系統重啟時的直接引發文件為RapDrv.sys。
這個文件為BlackICE的系統文件，它包括了監視應用程序的變化的相關模塊，可參見BlackICE的在線說明
檢查RapDrv.sys，文件沒有被改變的跡象，可排除被黑客和病毒修改文件的可能性。
對Dump文件進行調試，找到RapDrv.sys出錯時的堆棧情況，具體內容如下：
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx" "0x%08lx" "%s"
FAULTING_IP:
RapDrv+9785
f535e785 894104 mov dWord ptr [ecx+4],eax
TRAP_FRAME: f4c0bb54 -- (.trap fffffffff4c0bb54)
ErrCode = 00000002
eax=858b8b4c ebx=00000000 ecx=00000000 edx=00000000 esi=858b5000 edi=84e2660c
eip=f535e785 esp=f4c0bbc8 ebp=f4c0bbdc iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
RapDrv+0x9785:
f535e785 894104 mov dWord ptr [ecx+4],eax ds:0023:00000004=????????
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: blackice.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8085b4b3 to 8087b6be
STACK_TEXT:
f4c0b720 8085b4b3 0000008e c0000005 f535e785 nt!KeBugCheckEx+0x1b
f4c0bae4 808357a4 f4c0bb00 00000000 f4c0bb54 nt!KiDispatchException+0x3a2
f4c0bb4c 80835758 f4c0bbdc f535e785 badb0d00 nt!CommonDispatchException+0x4a
f4c0bb6c f5355b93 850ab630 84e2660c 858b5001 nt!Kei386EoiHelper+0x186
WARNING: Stack unwind information not available. Following frames may be wrong.
f4c0bbdc f535aa20 85897900 84e2660c 00000028 RapDrv+0xb93
f4c0bc08 f535b282 00222034 84e26608 00000058 RapDrv+0x5a20
f4c0bc28 f535b2f3 865b5ba0 00000058 86043a70 RapDrv+0x6282
f4c0bc4c 8092d3b9 84ad79d8 858e9028 84ad7968 RapDrv+0x62f3
f4c0bc60 8092e81b 865b5ba0 84ad7968 858e9028 nt!IopSynchronousServiceTail+0x10b
f4c0bd00 80940844 00000160 00000000 00000000 nt!IopXxxControlFile+0x5db
f4c0bd34 80834d3f 00000160 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f4c0bd34 7c95ed54 00000160 00000000 00000000 nt!KiFastCallEntry+0xfc
0012d688 00000000 00000000 00000000 00000000 0x7c95ed54
STACK_COMMAND: kb
FOLLOWUP_IP:
RapDrv+9785
f535e785
894104 mov dWord ptr [ecx+4],eax
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: RapDrv
IMAGE_NAME: RapDrv.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3f99bc4f
SYMBOL_NAME: RapDrv+9785
FAILURE_BUCKET_ID: 0x8E_RapDrv+9785
BUCKET_ID: 0x8E_RapDrv+9785
Followup: MachineOwner
從上面可以看出，在系統崩潰時，RapDrv正試圖作一個IO操作，在IopSynchronousServiceTail調用時出錯。在網上查尋相關資料，發現DapDrv有一個系統漏洞（相關資料），這個漏洞目前並沒有相關補丁和解決方案，好在它發生的條件比較苛刻，如果是攻擊，必須是已經攻入系統，在試圖修改應用程序時才會觸發。也就是說，如果想用這個漏洞進行攻擊，對方必須是已經攻入系統才能利用這個漏洞。
綜合上述，原來推測的四個可能性，只有最後一個Symantec的版本問題最有可能，因為其它的文件傳輸，只要不修改服務器上的可執行程序，是不會引發錯誤的。而Symantec在B服務器上安裝的也是服務器版，它的升級過程中，可能會試圖替換故障服務器上Symantec的上的9.0版程序。這才會觸發RapDrv對文件進行監控。
目前最終處理方案是：
考慮到這種事故發生時造成的影響較小，在基本排除硬件故障後，決定暫時只處理Symantec的版本問題，然後繼續觀察服務器的狀態，如果不再發生類似事件， 則不予理會。如果再一次發生類似情況，就將BlackICE中的文件保護功能關閉，這樣可以一勞永逸地解決這類事故。
