最近在互联网上提这个问题的网友较多，典型问题：这几天服务器总是运行缓慢，远程登录后发现一个w3wp.exe的进程占用了100%  cpu


在Windows  Server  2003中对于每一个Web应用，IIS  6.0都用一个独立的w3wp.exe的实例来运行它。w3wp.exe也称为工作进程（每一个主机头都会有一个）

直接在任务管理器中结束进程是不起作用的，结束后不久它会执行启动，要想结束它可以在IIS中找到相应的应用程序池停止相应的应用程序池工作。

这些都不是解决办法，它的根本问题是你的那个网站程序有问题，在找到问题以前可以先打开IIS找到应用程序池先用右键属性中设置“性能”把其中的CPU设成大于60%关闭应用程序池，把关闭时间和开启时间设短一些比如10秒，这样当您的网站程序大量占用系统资源时IIS自动快速回收进程并且快速启动进程，您的网站暂时还可以将就着工作。

要解决根本问题还要从程序查起，您可以在IIS中的应用程序池中右键创建多个应用程序池，然后在每个主机头中的文件家选项的底部将应用程序池对应道刚才建好的应用程序池，然后一个一个关闭在任务管理器中看看是哪个程序占用的资源较大。

下面是一些网友的相关贴子也许对大家有帮助



朋友的WEB服务器一直运行正常，但这几天CPU占用率一直将近100%，遂去看个究竟。
服务器采用Windows  2003,  网站使用ASP+Access数据库,  查看进程列表发现w3wp.exe  占用了70%以上的CPU，
查看WEB日志，站点访问量不大，查看TCP连接也不多。用net  stop  w3svc停掉WEB服务，CPU占用立即正常，net  start  w3svc启动WEB后不久现象又出来了。停止所有虚拟站点，新建一个虚拟站点发现并没有问题，怀疑是站点本身的代码问题。
检查首页代码，大致是如下结构：










粗看一下并没有问题，但就是这段代码造成了w3wp.exe占用大量CPU，难道是死循环？似乎没有理由。在循环体内加入计数，发现确实是死循环，说明RS.EOF一直为false，加入如下代码：




if  RS.EOF  =  true  then  Response.Write  "EOF  is  true"
if  RS.EOF  =  false  then  Response.Write  "EOF  is  false"




发现输出竟然是EOF  is  true  EOF  is  false,  说明无法判断RS.EOF的值，为何如此百思不得其解。检查数据库，发现库中并没有mytable表,  如果该表不存在，RS.Open  "SELECT  *  FROM  mytable",  conn  就会出错，为何没有出错，很有可能捕获的异常被忽略了。
检查包含文件conn.asp,  发现了异常处理代码：




On  Error  Resume  Next




原来问题在此。



On  Error  Resume  Next忽略了查询表时的失败以及后续的错误，造成进入死循环。
那为何网站本来运行正常，现在却找不到mytable表了呢？仔细检查网站才发现“有‘客’自远方来”，上传了后门工具、删除了多张数据表，害我忙活了一天。




更多的内容大家还可以到：http://www.microsoft.com/china/technet/security/guidance/secmod93.mspx


查找更详细的安全设置


windows2003  iis6.0假死问题解决

这几天服务器总是运行缓慢，远程登录后发现一个w3wp.exe的进程占用了100%  cpu。


问题的原因最终找到两个：

1.采用的jet  数据库连接方式存在问题：http://support.microsoft.com/?id=838306

补丁下载：

chs:WindowsServer2003-KB838306-x86-chs.exe

enu:WindowsServer2003-KB838306-x86-enu.exe

2.将access数据库扩展名改为asp

下面是我的差错过程和解决方案：

搜索一下发现类似问题还真不少，那个w3wp的进程是iis6.0的应用程序池，网上的说法有两种，一是因为asp或者asp.net代码中含有死循环引起的。但是服务器上这么多网站，谁知道那个网站出了问题。二是由于上面的jet连接数据库方式的bug引起的，下载838306的补丁，或者升级到sp1可以解决这个问题，但是打了这个补丁后，有些网站的问题依然存在。


又去搜索，有人说将每个网站建立独立的应用程序池，应用程序池的安全性帐户设为本地服务即可。方法如下:


首先新建应用程序池：


然后将网站的应用程序池指向刚才建立的应用程序池：


在建立完所有应用程序池后，统一修改应用程序池的属性：


将应用程序池安全帐户指定为本地服务：


设置完这些之后，问题依然存在，这样一个网站出现问题，不致影响其他网站，但是这个网站仍然占用大量资源，导致其它网站响应缓慢。不过在任务管理器中出现了每个应用程序池的进程，因此可以找到具体出问题的进程了。

下面是寻找出错网站的过程：要找到这个网站，必须把有问题的进程跟该网站的应用程序池联系起来。首先设置任务管理器的查看方式，加入PID的显示：



然后再命令行运行iisapp  -a，可以看到PID跟应用程序池的对应关系：


再去iis中看该应用程序池对应的网站，有问题的网站就找到了，剩下的就是这个网站代码中的问题了。

在某位网站管理员的纠缠不休下，我终于无法忍受，帮他找错误-  -  无数次配置iis，网站程序也换了，该升级的也升级了，问题还是存在，黔驴技穷，把网站下载到本地看看到底怎么回事。当我试图打开他的数据库的时候，问题出现了：

他的数据库是.asp的扩展名，要先修改为.mdb才能打开，但是当我点击要改名字的时候，我的电脑没有响应了~！看来问题在这个数据库了。

用命令行rename之后，打开数据库，修复，似乎没有任何问题，但是再改为.asp时，又出现了刚才的问题。哈~原来是.asp的扩展名在作怪。

但是我试着将其他的数据库改为.asp，没有问题。根本原因不得而知，望知情者告知。

最后，在iis中随便添加了一个isapi对应到mdb，造成mdb无法执行，防止下载，将所有的.asp的数据库改回.mdb，问题解决。