|
日历 |
<< < 2009 - 3 > >>
日 |
一 |
二 |
三 |
四 |
五 |
六 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
|
|
|
|
|
|
|
|
|
用户 222-76-212-216\Administrator 为这台机器上一次意外的关机提供的原因是: 系统故障: 停止错误 原因代码: 0x805000f 错误 ID: 错误检查字符: 0x000000d1 (0x00000008, 0x00000002, 0x00000000, 0xf723e1e4) 注释: 0x000000d1 (0x00000008, 0x00000002, 0x00000000, 0xf723e1e4)
有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持
这是错误代码 用户 222-76-XXX-XXX\Administrator 为这台机器上一次意外的关机提供的原因是: 系统故障: 停止错误 原因代码: 0x805000f 错误 ID: 错误检查字符: 0x000000d1 (0x00000008, 0x00000002, 0x00000000, 0xf723e1e4) 注释: 0x000000d1 (0x00000008, 0x00000002, 0x00000000, 0xf723e1e4)
有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持
|
可能的原因: 一、内存错误 二、某个定时的服务引起死锁 三、病毒残留或者黑客攻击 四、诺顿的文件检查功能 检查及处理过程: 一、由于这是第一次出现类似重启,先不考虑硬件故障。 但内存错误仍有另外一个可能性就是对磁盘上的虚拟内存访问出错。先检查虚拟内存所在磁盘,未发现错误。但磁盘中有比较多的文件碎片,考虑到内存文件过于分散有可能会引起偶尔的读错误。所以在凌晨1时左右进行一次全盘的文件碎片整理。 二、根据原因代码,网络上有关于定时服务引起文件死锁的记录,而查询登录日志,离重启最近的访问来自于另一台服务器B,加上出现故障时间与整点比较接近,有可能与某些系统服务有关,所以,将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中的文件保护功能关闭,这样可以一劳永逸地解决这类事故。 |
|
|
|
|