论文部分内容阅读
故障现象
现在许多单位为了宣传自我、展示形象,都通过Web网站将单位信息、最新动态等公布与众;而常见的Web网站几乎都是架设在Windows Server 2003系统上,利用该系统自带的IIS功能组件,并通过ASP程序+ACCESS数据库模式,来发布信息、管理网页的。最近,当笔者尝试将架设在Windows Server 2000系统上的单位网站内容,迁移到Windows Server 2003系统上时,发现网页浏览时会出现Web服务无效之类的错误提示,同时网站内容无法显示出来。重新启动Windows Server 2003系统后,发现网站内容可以正常显示,但是登录进入服务器系统后,系统竟然提示说“为了帮助保护您的计算机,Windows已经关闭了数据执行保护程序”,同时提示“Com Surrogate遇到了一个问题,需要关闭”。
故障排查
由于Windows Server 2000系统使用的是IIS5.0组件,而单位网站内容被迁移到Windows Server 2003系统上后,使用的是IIS6.0组件,难道是IIS5.0上的配置不适合IIS6.0?为了验证自己的猜测是否正确,笔者登录进入Windows Server 2003服务器系统,依次单击“开始”/“设置”/“控制面板”选项,打开系统控制面板窗口,再逐一双击“管理工具”、“Internet信息服务管理器”图标,进入IIS6.0控制台界面(如图1所示);由于单位网站是ASP程序编写的,会不会是Windows Server 2003系统禁止了ASP程序页面正常显示呢?为此,笔者展开本地主机节点,选中目标节点下面的“Web服务扩展”选项,在对应该选项的右侧列表中,选中ASP程序选项,发现该程序已经处于允许状态,这就意味着服务器系统是允许ASP程序页面正常显示的。
有没有可能是目标网站的应用程序池参数设置不当,造成了Web服务无效故障现象呢?想到这一点,笔者从本地主机节点下面选中IIS6.0中的应用程序池——DefaultappPool选项,同时用鼠标右键单击该选项,并点选快捷菜单中的“属性”命令,打开DefaultappPool选项的属性设置对话框(如图2所示),在这里笔者对其中的回收工作进程参数、内存回收参数以及运行性能参数进行了反复调整,并且每调整一次参数都立即进行访问测试,可是无论更改什么参数,哪怕是使用默认的参数,单位Web网站的访问仍然还会出现Web服务无效的故障现象,这说明这种故障现象与应用程序池的参数设置没有任何关系。
考虑到单位网站先前在IIS5.0控制台中能够正常浏览访问,于是笔者准备尝试着在IIS6.0系统中,将目标网站先配置成IIS5.0隔离模式状态,同时在该状态下测试一下目标网站自身是否存在问题。
想到做到,笔者立即在IIS6.0控制台界面中,用鼠标右键单击目标网站选项,从弹出的快捷菜单中执行“属性”命令,打开目标网站的属性设置对话框,单击其中的“服务”选项卡,在对应的选项设置页面中选中“隔离模式”选项,再单击“确定”按钮执行设置保存操作。这时候,继续进行网站页面测试时,笔者看到目标网站的静态页面内容可以正常浏览,但是访问动态网站页面时,就会出现“服务器内部错误出错”的提示。
重新启动服务器系统,并再次进行Web访问测试时,笔者发现动态网页内容又能正常显示了,不过服务器系统屏幕上同时也出现了“为了帮助保护您的计算机,Windows已经关闭了数据执行保护程序”这样的错误提示。
由于重启系统,目标网站内容能够正常显示一段时间,为此笔者认为目标网站程序自身应该不存在问题,毕竟该程序在IIS5.0系统中一直能够正常显示,问题可能还是出在IIS6.0系统中。
从IIS6.0配置中无法找到问题后,笔者开始将检查重点瞄准Windows Server 2003系统自身。由于在访问IIS6.0系统下的Web网站时,系统出现了一些错误提示,笔者认为这些错误提示应该在Windows Server 2003系统的日志文件中有所记录,那么为什么不查看一下系统日志,从中寻找一些故障原因呢?
于是,笔者依次单击“开始”/“设置”/“控制面板”命令,从中启用运行Windows Server 2003系统的事件查看器程序,在对应程序界面中依次查看安全性日志以及系统日志时,发现没有什么异常记录;在查看应用程序日志时,笔者看到有许多报警记录,并且这些记录都来源于“W3SVC-WP”,从这些记录的描述信息来看,笔者认为IIS6.0系统在运行过程中存在错误。由于服务器系统屏幕上反复出现Com Surrogate遇到问题的提示,那么这个提示能说明IIS6.0系统究竟出现了什么错误呢?
为了寻找到答案,笔者特地上网进行了搜索,结果发现问题可能出在Windows Server 2003系统的Vbscript.dll文件上;根据网友提示,笔者特地到另外一台工作状态正常的Windows Server 2003系统中,将Vbscript.dll文件拷贝过来,同时使用该文件替换可能存在问题的相同文件,之后执行regsvr32命令对VBScript控件进行了重新注册,最后再次启动了一下Windows Server 2003系统,然而让人感觉到遗憾的是,上述故障现象仍然还存在。
既然Vbscript.dll文件已经被替换了,那为什么系统屏幕上还会出现Com Surrogate遇到问题的提示,同时Web服务仍然无效呢?难道有非法用户在偷偷地对网站进行恶意攻击?为了排除这方面的故障因素,笔者再次对单位的目标站点内容进行了测试访问,并且将这次测试访问的时间节点也记录下来;之后,打开对应系统的事件查看器程序,从中展开应用程序日志,找到对应Com Surrogate遇到问题的记录选项,发现该记录生成的时间与先前进行测试访问的时间几乎相同,这说明这种错误提示并不是恶意攻击引起的。
故障解决
就这么一个网站,为什么迁移到新的服务器系统环境中后,它就不能正常浏览访问呢?在静静思考一段时间后,笔者认为在Windows Server 2003系统环境下,我们能够正常访问该网站的静态页面,只是不能访问asp页面;而asp页面的代码内容一直没有变化,变化的是一直处于更新的ACCESS数据库,由于先前对IIS配置以及系统自身因素都进行了排除,难道问题出在ACCESS数据库身上?
于是,找到目标网站的数据库文件,查看该文件的属性信息时,笔者发现该文件竟然达到了惊人的300多M,为什么这个数据库文件“身材”这么庞大呢?按理来说,单位网站的信息发布量并不是很大,笔者认为数据库文件最多不应该超过10M,显然数据库文件不正常;于是将目标数据库文件下载保存到本地,同时将该数据库文件打开,依次检查各个表中的记录内容,笔者发现其中某个表中的记录竟然达到了几十万条;原来,单位网站正在搞一个在线投票活动,那个表中的几十万条信息都是投票内容,看来有用户正在利用非法工具进行恶意投票。
为了防止数据库文件的“身材”变得更加臃肿,笔者立即关闭了单位网站的在线投票功能,同时尝试删除恶意投票内容,无奈数据库文件太大,Windows Server 2003系统根本无法正常响应;不得已,笔者只好将先前备份的10M数据库文件拿过来使用,在完成数据库文件的替换操作之后,笔者再次进行了目标网站的访问测试,结果发现这次可以很顺利地访问到网站页面内容了,之后连续几天又对该网站进行反复测试,发现网站的工作状态终于恢复了正常,再也没有出现Web服务无效的故障现象了,至此,笔者断定数据库文件太大就是引起Web服务无效的“罪槐祸首”。
故障总结
规模不大的网站几乎都会选用简单、经济的ACCESS数据库,来保存网站内容,同时普通的ASP程序页面也会选用ACCESS数据库作为后台数据库;尽管这种类型的数据库理论上能够保存2GB大小的数据信息,可是ASP程序在实际调用该数据库时,会受到系统内存以及系统响应时间的限制,因此一旦ACCESS数据库的实际大小超过200M时,网站访问就可能出现速度缓慢甚至不能正常访问的现象。上面的故障现象,其实就是由于有非法用户通过专业工具,不停地向ACCESS数据库中写入投票内容,最终导致ACCESS数据库的大小变成了300多M,所以ASP程序日后在调用这么庞大的数据库文件时,自然就会出现Web服务无效的故障现象了。
从上面的故障排除过程来看,我们不难发现,日后当遭遇Web网站不能正常访问现象时,可以尝试从Web网站自身状态、恶意攻击以及服务器系统自身状态这三个方面进行逐一排查;同时作为网络管理员,我们在平时不但需要加强对服务器系统的管理与维护,而且还要加强对网站自身内容的管理与维护。
现在许多单位为了宣传自我、展示形象,都通过Web网站将单位信息、最新动态等公布与众;而常见的Web网站几乎都是架设在Windows Server 2003系统上,利用该系统自带的IIS功能组件,并通过ASP程序+ACCESS数据库模式,来发布信息、管理网页的。最近,当笔者尝试将架设在Windows Server 2000系统上的单位网站内容,迁移到Windows Server 2003系统上时,发现网页浏览时会出现Web服务无效之类的错误提示,同时网站内容无法显示出来。重新启动Windows Server 2003系统后,发现网站内容可以正常显示,但是登录进入服务器系统后,系统竟然提示说“为了帮助保护您的计算机,Windows已经关闭了数据执行保护程序”,同时提示“Com Surrogate遇到了一个问题,需要关闭”。
故障排查
由于Windows Server 2000系统使用的是IIS5.0组件,而单位网站内容被迁移到Windows Server 2003系统上后,使用的是IIS6.0组件,难道是IIS5.0上的配置不适合IIS6.0?为了验证自己的猜测是否正确,笔者登录进入Windows Server 2003服务器系统,依次单击“开始”/“设置”/“控制面板”选项,打开系统控制面板窗口,再逐一双击“管理工具”、“Internet信息服务管理器”图标,进入IIS6.0控制台界面(如图1所示);由于单位网站是ASP程序编写的,会不会是Windows Server 2003系统禁止了ASP程序页面正常显示呢?为此,笔者展开本地主机节点,选中目标节点下面的“Web服务扩展”选项,在对应该选项的右侧列表中,选中ASP程序选项,发现该程序已经处于允许状态,这就意味着服务器系统是允许ASP程序页面正常显示的。
有没有可能是目标网站的应用程序池参数设置不当,造成了Web服务无效故障现象呢?想到这一点,笔者从本地主机节点下面选中IIS6.0中的应用程序池——DefaultappPool选项,同时用鼠标右键单击该选项,并点选快捷菜单中的“属性”命令,打开DefaultappPool选项的属性设置对话框(如图2所示),在这里笔者对其中的回收工作进程参数、内存回收参数以及运行性能参数进行了反复调整,并且每调整一次参数都立即进行访问测试,可是无论更改什么参数,哪怕是使用默认的参数,单位Web网站的访问仍然还会出现Web服务无效的故障现象,这说明这种故障现象与应用程序池的参数设置没有任何关系。
考虑到单位网站先前在IIS5.0控制台中能够正常浏览访问,于是笔者准备尝试着在IIS6.0系统中,将目标网站先配置成IIS5.0隔离模式状态,同时在该状态下测试一下目标网站自身是否存在问题。
想到做到,笔者立即在IIS6.0控制台界面中,用鼠标右键单击目标网站选项,从弹出的快捷菜单中执行“属性”命令,打开目标网站的属性设置对话框,单击其中的“服务”选项卡,在对应的选项设置页面中选中“隔离模式”选项,再单击“确定”按钮执行设置保存操作。这时候,继续进行网站页面测试时,笔者看到目标网站的静态页面内容可以正常浏览,但是访问动态网站页面时,就会出现“服务器内部错误出错”的提示。
重新启动服务器系统,并再次进行Web访问测试时,笔者发现动态网页内容又能正常显示了,不过服务器系统屏幕上同时也出现了“为了帮助保护您的计算机,Windows已经关闭了数据执行保护程序”这样的错误提示。
由于重启系统,目标网站内容能够正常显示一段时间,为此笔者认为目标网站程序自身应该不存在问题,毕竟该程序在IIS5.0系统中一直能够正常显示,问题可能还是出在IIS6.0系统中。
从IIS6.0配置中无法找到问题后,笔者开始将检查重点瞄准Windows Server 2003系统自身。由于在访问IIS6.0系统下的Web网站时,系统出现了一些错误提示,笔者认为这些错误提示应该在Windows Server 2003系统的日志文件中有所记录,那么为什么不查看一下系统日志,从中寻找一些故障原因呢?
于是,笔者依次单击“开始”/“设置”/“控制面板”命令,从中启用运行Windows Server 2003系统的事件查看器程序,在对应程序界面中依次查看安全性日志以及系统日志时,发现没有什么异常记录;在查看应用程序日志时,笔者看到有许多报警记录,并且这些记录都来源于“W3SVC-WP”,从这些记录的描述信息来看,笔者认为IIS6.0系统在运行过程中存在错误。由于服务器系统屏幕上反复出现Com Surrogate遇到问题的提示,那么这个提示能说明IIS6.0系统究竟出现了什么错误呢?
为了寻找到答案,笔者特地上网进行了搜索,结果发现问题可能出在Windows Server 2003系统的Vbscript.dll文件上;根据网友提示,笔者特地到另外一台工作状态正常的Windows Server 2003系统中,将Vbscript.dll文件拷贝过来,同时使用该文件替换可能存在问题的相同文件,之后执行regsvr32命令对VBScript控件进行了重新注册,最后再次启动了一下Windows Server 2003系统,然而让人感觉到遗憾的是,上述故障现象仍然还存在。
既然Vbscript.dll文件已经被替换了,那为什么系统屏幕上还会出现Com Surrogate遇到问题的提示,同时Web服务仍然无效呢?难道有非法用户在偷偷地对网站进行恶意攻击?为了排除这方面的故障因素,笔者再次对单位的目标站点内容进行了测试访问,并且将这次测试访问的时间节点也记录下来;之后,打开对应系统的事件查看器程序,从中展开应用程序日志,找到对应Com Surrogate遇到问题的记录选项,发现该记录生成的时间与先前进行测试访问的时间几乎相同,这说明这种错误提示并不是恶意攻击引起的。
故障解决
就这么一个网站,为什么迁移到新的服务器系统环境中后,它就不能正常浏览访问呢?在静静思考一段时间后,笔者认为在Windows Server 2003系统环境下,我们能够正常访问该网站的静态页面,只是不能访问asp页面;而asp页面的代码内容一直没有变化,变化的是一直处于更新的ACCESS数据库,由于先前对IIS配置以及系统自身因素都进行了排除,难道问题出在ACCESS数据库身上?
于是,找到目标网站的数据库文件,查看该文件的属性信息时,笔者发现该文件竟然达到了惊人的300多M,为什么这个数据库文件“身材”这么庞大呢?按理来说,单位网站的信息发布量并不是很大,笔者认为数据库文件最多不应该超过10M,显然数据库文件不正常;于是将目标数据库文件下载保存到本地,同时将该数据库文件打开,依次检查各个表中的记录内容,笔者发现其中某个表中的记录竟然达到了几十万条;原来,单位网站正在搞一个在线投票活动,那个表中的几十万条信息都是投票内容,看来有用户正在利用非法工具进行恶意投票。
为了防止数据库文件的“身材”变得更加臃肿,笔者立即关闭了单位网站的在线投票功能,同时尝试删除恶意投票内容,无奈数据库文件太大,Windows Server 2003系统根本无法正常响应;不得已,笔者只好将先前备份的10M数据库文件拿过来使用,在完成数据库文件的替换操作之后,笔者再次进行了目标网站的访问测试,结果发现这次可以很顺利地访问到网站页面内容了,之后连续几天又对该网站进行反复测试,发现网站的工作状态终于恢复了正常,再也没有出现Web服务无效的故障现象了,至此,笔者断定数据库文件太大就是引起Web服务无效的“罪槐祸首”。
故障总结
规模不大的网站几乎都会选用简单、经济的ACCESS数据库,来保存网站内容,同时普通的ASP程序页面也会选用ACCESS数据库作为后台数据库;尽管这种类型的数据库理论上能够保存2GB大小的数据信息,可是ASP程序在实际调用该数据库时,会受到系统内存以及系统响应时间的限制,因此一旦ACCESS数据库的实际大小超过200M时,网站访问就可能出现速度缓慢甚至不能正常访问的现象。上面的故障现象,其实就是由于有非法用户通过专业工具,不停地向ACCESS数据库中写入投票内容,最终导致ACCESS数据库的大小变成了300多M,所以ASP程序日后在调用这么庞大的数据库文件时,自然就会出现Web服务无效的故障现象了。
从上面的故障排除过程来看,我们不难发现,日后当遭遇Web网站不能正常访问现象时,可以尝试从Web网站自身状态、恶意攻击以及服务器系统自身状态这三个方面进行逐一排查;同时作为网络管理员,我们在平时不但需要加强对服务器系统的管理与维护,而且还要加强对网站自身内容的管理与维护。