第497章
在win.ini文件中，在[Windows]下面，“run=”和“load=”是可能加载“木马”程序的途径，必须仔细留心它们。一般情况下，它们的等号后面什幺都没有，如果发现后面跟有路径与文件名不是你熟悉的启动文件，你的计算机就可能中上“木马”了。当然你也得看清楚，因为好多“木马”，如“AOLTrojan木马”，它把自身伪装成command.exe文件，如果不注意可能不会发现它不是真正的系统启动文件。
在system.ini文件中，在[BOOT]下面有个“shell=文件名”。正确的文件名应该是“explorer.exe”，如果不是“explorer.exe”，而是“shell=explorer.exe程序名”，那幺后面跟着的那个程序就是“木马”程序，就是说你已经中“木马”了。
在注册表中的情况最复杂，通过regedit命令打开注册表编辑器，在点击至:“HKEY-LOCAL-MACHINE\Software\Microsoft\Windows\CurrentVersion\Run”目录下，查看键值中有没有自己不熟悉的自动启动文件，扩展名为EXE，这里切记:有的“木马”程序生成的文件很像系统自身文件，想通过伪装蒙混过关，如“AcidBatteryv1.0木马”，它将注册表“HKEY-LOCAL-MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”下的Explorer键值改为Explorer=“C:\Windows\expiorer.exe”，“木马”程序与真正的Explorer之间只有“i”与“l”的差别。当然在注册表中还有很多地方都可以隐藏“木马”程序，如:“HKEY-CURRENT-USER\Software\Microsoft\Windows\CurrentVersion\Run”、“HKEY-USERS\****\Software\Microsoft\Windows\CurrentVersion\Run”的目录下都有可能，最好的办法就是在“HKEY-LOCAL-MACHINE\Software\Microsoft\Windows\CurrentVersion\Run”下找到“木马该病毒也称为“CodeRedII(红色代码2)”病毒，与早先在西方英文系统下流行“红色代码”病毒有点相反，在国际上被称为VirtualRoot(虚拟目录)病毒。
安装“一流信息监控拦截系统”，使用其中的“首席文件检查官IIS健康检查官”软件，
启用”查找死锁模块”，设置:
--wblock=yes
监控的目录，请指定您的主机的文件所在目录:
--wblockdir=d:\test
一些驱动程序有时也可能出现这样的现象，最好是选择微软认证的或者是官方发布的驱动来装，有时可以适当的升级驱动，不过记得最新的不是最好的。
CPU降温软件，由于软件在运行时会利用所以的CPU空闲时间来进行降温，但Windows不能分辨普通的CPU占用和降温软件的降温指令之间的区别，因此CPU始终显示100%，这个就不必担心了，不影响正常的系统运行。
在处理较大的word文件时由于word的拼写和语法检查会使得CPU累，只要打开word的工具-选项-拼写和语法把”检查拼写和检查语法“勾去掉。
单击avi视频文件后CPU占用率高是因为系统要先扫描该文件，并检查文件所有部分，并建立索引；解决办法:右击保存视频文件的文件夹-属性-常规-高级，去掉为了快速搜索，允许索引服务编制该文件夹的索引的勾。
CPU占用100%案例分析
监控生成的日志的文件保存位置在安装目录的log目录中，文件名为:logblock.htm
停止IIS，再启动“首席文件检查官IIS健康检查官”，再启动IIS，“首席文件检查官IIS健康检查官”会在logblock.htm中记录下最后写入的ACCESS文件的。
过了一段时间后，当问题出来时，例如CPU会再次一直处100%的水平，可以停止IIS，检查logblock.htm所记录的最后的十个文件，注意，最有问题的往往是计数器类的ACCESS文件，例如:”**COUNT.MDB”，”**COUNT.ASP”，可以先把最后十个文件或有所怀疑的文件删除到回收站中，再启动IIS，看看问题是否再次出现。我们相信，经过仔细的查找后，您肯定可以找到这个让您操心了一段时间的文件的。
找到这个文件后，可以删除它，或下载下来，用ACCESS2000修复它，问题就解决了。
2、svchost.exe造成CPU使用率占用100%
1、dllhost进程造成CPU使用率占用100%
特征:服务器正常CPU消耗应该在75%以下，而且CPU消耗应该是上下起伏的，出现这种问题的服务器，CPU会突然一直处100%的水平，而且不会下降。查看任务管理器，可以发现是DLLHOST.EXE消耗了所有的CPU空闲时间，管理员在这种情况下，只好重新启动IIS服务，奇怪的是，重新启动IIS服务后一切正常，但可能过了一段时间后，问题又再次出现了。
直接原因:
有一个或多个ACCESS数据库在多次读写过程中损坏，微软的MDAC系统在写入这个损坏的ACCESS文件时，ASP线程处于BLOCK状态，结果其它线程只能等待，IIS被死锁了，全部的CPU时间都消耗在DLLHOST中。
解决办法: