none
一个奇怪的C0000005错误 RRS feed

  • 问题

  • Web服务器为IIS6.0,运行ASP角本,角本语言VBScript。最近大半年来服务器频频被C0000005错误困扰。

    相关的角本代码编写执行都没有问题,但是运行一段时间后就会出现这种C0000005的报错。

    在事件查看器中也会记录这种错误信息:

    程序块
    事件类型: 错误
    事件来源: Active Server Pages
    事件种类: 无
    事件 ID: 5
    日期:  2007-10-23
    事件:  6:31:16
    用户:  N/A
    计算机: MYSERVER-06020806
    描述:
    错误: 文件 /book/index.asp  意外错误. 外部对象中发生了可捕获的错误(C0000005)。脚本无法继续执行。

     

     

    一旦有第一个文件开始这种报错,马上会迅速蔓延所有以前测试运行相当稳定的代码文件,而且该类型报错信息几乎完全占满应用程序日志部分。

     

    根据事件日志,第一次发生上述报错信息后几秒内会发生如下的报错信息:

    程序块

    事件类型: 错误
    事件来源: Active Server Pages
    事件种类: 无
    事件 ID: 5
    日期:  2007-10-23
    事件:  6:31:42
    用户:  N/A
    计算机: MYSERVER-06020806
    描述:
    错误:   脚本引擎异常. ScriptEngine 产生了异常 'C0000005'(错误位于

    'IActiveScript::SetScriptState()' 中,来自

    'CActiveScriptEngine::ResetToUninitialized()')。

     

     

    同时在该错误持续一段时间后通常会产生另一种错误日志信息:

    程序块

    事件类型: 错误
    事件来源: Application Error
    事件种类: (100)
    事件 ID: 1000
    日期:  2007-10-23
    事件:  7:47:49
    用户:  N/A
    计算机: MYSERVER-06020806
    描述:
    错误应用程序 w3wp.exe,版本 6.0.3790.3959,错误模块 ntdll.dll,版本 5.2.3790.3959,错误地址 0x0002caa2。

    有关更多信息,请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。
    数据:
    0000: 41 70 70 6c 69 63 61 74   Applicat
    0008: 69 6f 6e 20 46 61 69 6c   ion Fail
    0010: 75 72 65 20 20 77 33 77   ure  w3w
    0018: 70 2e 65 78 65 20 36 2e   p.exe 6.
    0020: 30 2e 33 37 39 30 2e 33   0.3790.3
    0028: 39 35 39 20 69 6e 20 6e   959 in n
    0030: 74 64 6c 6c 2e 64 6c 6c   tdll.dll
    0038: 20 35 2e 32 2e 33 37 39    5.2.379
    0040: 30 2e 33 39 35 39 20 61   0.3959 a
    0048: 74 20 6f 66 66 73 65 74   t offset
    0050: 20 30 30 30 32 63 61 61    0002caa
    0058: 32                        2      

     

     

    另外在不断发生C0000005错误信息的同时,w3wp.exe占据的内存会不断增长。我设置了内存回收的限制。一旦系统完成内存强制回收则系统立刻恢复正常运行,报错的页面都能正常访问。

     

    在官方网站找相关的解决方案,但是都不理想。角本代码本身应该是没有问题的。曾有一种解决方案认为是相关的角本dll库文件损坏了,更新即可。但是在已经更新成官方最新的版本仍然没有解决这个问题。因此想知道发生这种问题的真正原因是什么,如何避免和解决。

    2007年11月26日 3:19

答案

  • 这个的可能性很多,其他可行性也不能断然排除.

    还有的情况就是:

    资源产生死锁并导致IIS进程出错.这个在日志中可以看出.

    请排查客户程序的编码合理性.

     

    其他情况该回答并不排除其可能性.

    2007年11月26日 22:54
  •  

    除杨云版主所列编码问题外,数据库太大,这是一方面原因;特别是mdb数据库。
    2007年12月10日 4:48

全部回复

  • 这个的可能性很多,其他可行性也不能断然排除.

    还有的情况就是:

    资源产生死锁并导致IIS进程出错.这个在日志中可以看出.

    请排查客户程序的编码合理性.

     

    其他情况该回答并不排除其可能性.

    2007年11月26日 22:54
  •  

    除杨云版主所列编码问题外,数据库太大,这是一方面原因;特别是mdb数据库。
    2007年12月10日 4:48
  • 我的服务器5月2日开始到5月3日,也出现上述问题,且服务器的CPU load为100%,所有的asp代码的网站全打不开,重启服务器后一切正常。不知什么原因造成,有没有好的解决问题办法

    2008年5月4日 2:15
  •  

    楼上几位已经指明了方向,基本上是mdb数据库引起的。这确定了排查了方向。

    就我的问题而言,基本上是一个基于mdb数据库开发的代码中在conn.open了数据库资源的情况下却没有进行conn.close这样释放资源的操作。累积起来造成消耗资源占用严重,致使其它正常页面的代码在申请系统资源时也受到影响出现报错,日志中这些报错基本上是在系统资源已经消耗殆尽的情况下才出现的,而实际引发该问题的页面在第一次执行时通常是资源够用的,并不会在日志中报错。因此通过时间顺序排查事件日志中最早的报错记录并不能确定问题源。

    因为这样的问题是最近一段时间发生的,因此解决办法是:

    一、范围定位在所有基于Access MDB数据库开发的程序代码上。

    二、重点检查近一段时间内被修改或新境的功能代码

    仔细检查这些代码是否在申请了数据库资源后,在用完资源后是否显式的释放了这些资源。

    2008年5月4日 2:54