IIS7+错误诊断要点

你是否有经历过文件存在却给你个404的迷茫？你又是否经历过面对错误却找不到一点线索的烦恼？其实，这些都是因为缺乏对于面对错误时所应采取的诊断步骤的了解。当然，诊断错误的方式也会因碰到不同的错误信息而不同，而这里我们就讲一些基础的IIS错误诊断要点。

1．       获取详细的错误信息

取消浏览器显示友好错误信息的功能

我们到底碰到了什么问题？这也许是一个网页没有正常显示出来所给我们带来的最大的疑问。而这时候，如果浏览器中给出的是“该网页无法显示”的话，那对于我们这些要排除错误的人而言就显得毫无意义。碰到这种情况，我们要做的第一步就是确认浏览器是否把错误信息隐藏了起来。就拿IE作为例子，IE在高级设置中有个“Showfriendly HTTP error messages”的选项，而且在默认情况下，这个功能是启动着的。在取消这个功能之后重新访问这个页面（ctrl+F5,防止从IE缓存中读），我们会发现错误信息已经和之前的不一样了。比如现在我们得到的是这样的信息:404错误-你所访问的文件或目录不存在，而这样的信息已经或多或少为我们的排错提供了些有意义的信息。

错误页面设置

碰到之前所提及的404时，我相信大多数情况下都会先去确认下自己的url是不是打错了导致找不到请求的文件。如果真是这样那很好，因为你已经找到了问题的根源。但是事实上错误的原因往往并没有那么简单，这时候我们就会产生迷惑，从而引发了下一个疑问：能不能在浏览器里提供再详细一点的错误信息？答案是可以的。在IIS7+中有一个错误页面（Error Pages）的功能，而在这个功能的设置中有3个选项，分别是：自定义错误页面（Custom error pages）、详细的错误（Detailed error）、本地请求显示详细错误远程请求显示自定义错误（Detailed errors for local requests and custom error pages for remote requests）。其中第三个是默认的选项。也就是说，如果你是远程管理的IIS服务器，那你获得的往往不是最详细的错误信息。所以这种情况下我们往往就需要选择详细信息，而之后我们在浏览器中获得就是我们所期待的在浏览器中所能获得的最详细的错误信息。其中最主要信息包括错误的状态码子状态码，哪个模块抛出的错误，哪个handler最终处理了当前的请求以及错误码。比如就刚才的那个例子，我们在启动详细错误之后得知了详细错误是404.2 - isapi或 cgi 限制，由isapiModule抛出，那我们就知道了错误的直接原因是isapi和cgi限制里面我们没有允许.net的isapi filter，这才导致了刚才的错误，而进行相对应的设置就能轻松解决这个问题。

2．       状态码和子状态码

任何一个成功发向服务器的网络请求最终都会有状态码和子状态码，其中4xx和5xx则是有错误时会返回的状态码。有了详细的状态码和子状态码我们就可以在下面这篇KB中找到对应的含义以及通常情况下的解决方法：

http://support.microsoft.com/kb/943891/zh-cn

3．       日志

当浏览器里所获得的信息并不能帮我们解决遇到的问题时，下一步我们应该获取更多信息的地方就是日志。以下介绍下一些对解决IIS疑难杂症能起到一定作用的日志。

IIS日志

在IIS中，通常我们碰到一个错误时候所说的查日志指的就是IIS日志。IIS日志本身也是IIS的一个模块，所以如果找不到IIS日志的话请确认三点：第一，确认在安装IIS的时候安装了日志模块；第二，确认在IIS日志设置中，日志记录时开启的；第三，确认你有权限在所设置的日志路径中进行读写操作。关于日志中记录的详细内容，大家可以参考下面这篇文章：

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/676400bc-8969-4aa7-851a-9319490a9bbb.mspx?mfr=true

注：以上链接里的信息也适用于IIS7+。

在日志中，我们最关心的可能就是HTTP的状态码、子状态码以及windows系统码(win32status code)，这些都将为找到错误根源起到一定的作用。如果打开一个日志文件，最新的一个请求没有被记录，这可能是2个原因导致的：一是请求还没有经过日志模块就结束了，发生这个现象的原因可能是一些严重的错误导致了IIS进程启动的失败，也有可能是http.sys本身驳回了请求，导致请求本身没有进入IIS的管道；二是日志文件本身还不是最新的版本，碰到这种情况，要么等一段时间再看，要么在命令行里运行“netsh httpflush logbuffer”强制日志获取最新请求的信息。

失败请求跟踪（Failed Request Tracing，FRT akaFreb）

失败请求跟踪（FRT）是IIS7里介绍的一个新的功能，它可以为我们提供一个请求在IIS中处理的详细过程，而往往导致错误的线索就在这详细的信息之中。关于FRT的应用，网上已经有了很多的介绍，这里就不再赘述。这里主要提及些使用这个功能时候可能碰到的问题。

首先，FRT做为一个IIS的模块，和IIS日志一样需要在安装的时候安装这个模块了才可使用；其次，FRT默认情况下是关闭的，如果不开启，就算你配置了相应的规则也不会有任何日志文件记录；最后，FRT日志文件有个默认的最大文件大小，默认是512KB，这个值是可以修改的，如果日志文件过大，FRT将不显示超过的内容并在日志 文件里抛出LOG_FILE_MAX_SIZE_TRUNCATE的错误提示，修改FRT日志文件允许的最大文件大小可以用这条命令：

%windir%\system32\inetsrv\appcmdset config -section:system.applicationHost/sites /"[name='Your SiteName']".traceFailedRequestsLogging.maxLogFileSizeKB:"Max File Size"

注：将以上命令中的Your Site Name替换成你实际网站的名字，将Max File Size替换成你所需要设置的最大文件大小，单位是KB。

还有值得注意的就是IIS日志无法捕捉到的错误，FRT同样无法捕捉到。下面提供2个如何运用FRT的链接：

http://mvolo.com/trace-iis-70-errors-like-a-pro-with-failed-request-tracing

http://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis

 

HTTP.sys日志

HTTP.sys作为一个协议监听器，是和客户端进行直接交户的（接收客户端请求，向客户端发出响应）。之前也提到过，由HTTP.sys直接驳回的请求（例如400错误），在IIS和FRT日志里都无法找到，所以碰到这种情况我们就需要在HTTP.sys日志里面去获得更多的信息。HTTP.sys日志位于“%windir%\system32\logfiles\httperr”,日志包含的内容与IIS日志类似，我们通常需要关心的是状态码、子状态码以及原因(s-reason)，其中原因更是直接明了的道出此次错误发生的原因。由HTTP.sys直接驳回的请求，如果不修改请求本身，只能通过修改注册表才能解决。而关于HTTP.sys相关的注册表的键可以在下面这篇KB里找到：

http://support.microsoft.com/kb/820129/zh-cn

注：若非必要，一般不建议直接修改注册表值，如需修改，请做好备份。

事件日志（EventLog）

事件日志应该是我们在完全没有头绪的时候第一个想到获取更多线索的地方。举个例子吧，你网站的应用程序池的用户设置的是你的域用户，你的域用户密码进行了修改，而你却忘记了更新IIS中的设置。这时候访问网站就会碰到著名的503 Service Unavailable，IIS、FRT什么都不会记录，就连这时候应该很可靠的HTTP.sys日志也在这时候在原因栏里留了空。但这时候如果你去检查事件日志的话，你会发现里面明确的记录了用户名或密码不正确导致IIS进程启动失败的信息，这就为你解决这个看似复杂实为简单的问题起到了决定性的作用。

4．       Debug

除了在浏览器中获得HTTP状态码的错误信息外，代码引起的错误（.net的黄页）也是常见的一个问题。这种情况下可能需要进行debug才能确定其根本原因。在IIS下debug需要注意以下两点：一是确定你网站或者页面允许了debug，网站的设置是web.config下system.web/compilation的debug属性（<compilationdebug=“true”>），而如果只想debug一个页面，则可以在网页的头加上<%@page debug=“true” %>；二是在允许debug的情况下你需要附着到IIS的进程中，看似复杂但VS本身就自带了这个功能，你只需要通过Debug->Attachto Process，然后找到相应的w3wp.exe就可对进入该进程请求进行debug。

5．       其他

以上已经包括了碰到一个IIS错误时我们所能做的绝大部分，下面简单介绍几个可以帮助诊断错误的工具。

Process Monitor

Process Monitor可以几乎完美地记录一个进程的读写操作，这里我们可以只看w3wp进程，注意其读写，这样可以轻松的诊断出一些由权限导致的问题。

Performance Monitor

Performance Monitor使你可以获得当前IIS服务器实况数据，从而使你能够更好的调控当前服务器的性能。

DebugDiag

当碰到内存溢出之类的错误时，debugdiag的dump可以帮助你更准确的定位错误根源的所在。

此外还有不少实用的工具这里没有提及（例如Network Monitor），而更多的工具并不在本文的范畴之内。希望通过本文可以对“在碰到一个IIS错误时我们应该怎么做”这个问题有个清楚的回答，也希望本文对那些对IIS错误无从下手的人有所帮助。