来源：IT168
如果你刚刚把你的应用程序转移到IIS7服务器，现在当你向它发出请求时，你就会得到一个错误，这好像是近来IIS.NET论坛上的热门话题，当回答了一百多个左右的问题时，我觉得自己应该做一些事情，以帮助大家追踪并解决这些问题。
具体来说，服务器软件和网络服务器是复杂且高度可配置的系统，它们支持多层网络架构应用程序，多层网络架构应用程序使用不同技术以及子系统，因为服务器软件和网络服务器对安全、性能、以及可靠性的要求，它能承受更多的复杂性，所以它直到最后都能工作得很好，这一点很让人惊讶。IIS7力图提高诊断和解决问题的能力（当它们发生时），因此在帮助你成为一个为服务器问题排错专家方面，知道怎样使用新的IIS7 诊断学特点，将给你很大的帮助。
1.问题是什么？
当别人提出像“帮帮我，我移到IIS7，我的应用程序停止工作了”这样的问题时，我发现自己经常在论坛上问这样一个问题：它为什么不能运行？当你的网站停止工作，你要做的第一件事情就是在我们继续向前移动之前，决定这个错误到底是什么。IIS7有更好的错误信息，它们将告诉你问题到底是什么，并且帮你解决问题。
不幸的是，有时候找到这个错误是一个主要的挑战，首先让我们了解一下要解决这个问题时，你所要了解的事情。
1)解除IE “Friendly HTTP error messages”
IE将默认地代替真正的错误信息，此错误信息来自于一个附带有“友好的”错误信息的服务器，隐藏了我们需要看到的错误内容。例如：没有找到一个404错误信息，相反，你会看到下面的情况：
解除这个误解，找到真正的来自于服务器的错误，你需要去“工具> 网络选择”,选择高级键，清除“表现友好的HTTP错误信息”检验栏，然后，关掉浏览器，重新打开它，再次请求此页面。
现在假设你看到的仍然是“不能显示此网页”或者是“没找到该网页”的错误。这是因为IE没有成功地连接到你的网站，因此这里不会看到服务器错误信息。在Where did my IIS7 server go? Troubleshooting "server not found" errors.我详细地告诉大家怎样处理这样的情况。
另外： 如果你排错时，不想与IE产生混乱（尤其是因为IE的超攻击性的高速缓存，你发现自己得到一些高速缓存页面），最好的办法就是使用选择的一个可信的简单的http工具，并且重新请求它。我推荐WFETCH，它包含在IIS6 Resource Kit tools中（你可以只在XP/Windows 2003安装它，然后要么在那里运转它，或者是把wfetch.exe复制到你的Vista/LHS框）。
2.找到IIS7详细错误
IIS7引进了一种新的特定的错误特点，这种新的错误特点默认地隐藏错误反应（此错误反应是由服务器发送到远程客户的），用一个基本的错误信息代替它们。这对你的网站的安全非常重要，因为错误经常包含一些敏感的信息，而你不想让其它人看到这些敏感信息，但是因为你不能看到错误的具体信息，所以更难找出问题的根源。因此，如果你从另一台机器重新访问你的网站，你仍然会得到一个与下面情况相似的基本错误：
在这里你有两个选择 ：
1)从服务器机器上发出本地请求。在默认的情况下，你将得到一个详细的错误。
2)为远程客户找到详细错误 。
首先，如果你的错误是一个ASP.NET特例（你可以分辨出它是否是“运转时间错误”，它是否含有框架版本），请注意ASP.NET用它自己安装的特定错误覆盖了IIS定制错误机制，因此你能关掉ASP.NET特定错误，检查详细的ASP.NET特例。你没必要为了ASP.NET特例安装IIS7特定错误（在两个地方都做这件事是非常愚蠢的）。关掉ASP.NET特定错误，把下面的内容放到你的web.config:
如果该错误不是ASP.NET错误，关掉IIS7特定错误，允许错误响应（自于你的应用程序）被发送到远程客户，而且不会被IIS7特定错误模块审查。.
通过运行“开始>运行>inetmgr.exe”,，选择你的网站/应用程序/左侧树形图的虚拟目录，点击“错误页码”光标，再点击“编辑特点设置”行为，然后选择“详细错误”，你就从IIS7 Admin工具完成了这一过程。
你也可以从一个提升的命令行提示符（作为网络管理员运转）完成这一过程：
> %windir%/system32/inetsrv/appcmd.exe set config "Default Web Site/yourapp" /section:httpErrors /errorMode:Detailed
这里就是你就要用你的网站名代替“默认网站”的地方，以及用虚拟途径代替“/yourapp”的地方，以方便你能找到错误的详细信息。
注意：当你调试时，请为远程请求将设置返回到特定错误，否则会威胁到你的网站的安全。下面是使用AppCmd怎样完成它的步骤：
> %windir%/system32/inetsrv/appcmd.exe set config "Default Web Site/yourapp" /section:httpErrors /errorMode:DetailedLocalOnly
现在，你应该得到了错误的详细信息—例如，我先前得到的错误如下（这是Vista错误页码—Longhorn Server 和Vista SP1错误页码会更好看些，在这里看例子）：
注意这个错误包含许多有用的信息：
1) 标题包括次状态代码，次状态代码是一个IIS特别代码，进一步描述问题。大部分常见问题有一个典型的<状态代码>.<次状态_代码>联合，你可以在google上寻找额外的信息。
2) 这个页码暗示了IIS Web Core是什么模块，在哪种MapRequestHandler情况下会发生错误。当你在调试服务器问题时，这个信息非常重要，尤其是在IIS7+世界中，当大部分错误发生在其中一个模块上，而此模块参与了请求运转，这个信息更加重要。
3) 页码给你提供了许多有用的请求信息，例如：被请求的url，以及它解决问题的物理途径。看到请求变成一个错误的url，或者因为错误的虚拟目录映射，而被发送到错误的物理途径时，大部分404错误就在这里解决了。
4) “最可能的原因”以及“你能干什么”版块为错误提供了最有可能的解释，以及你可以做些什么。对于大部分常见的IIS7错误，它们就是完全正确的。
5) 注意：当你带着错误来到论坛，我期望你能提供一个详细的错误，帮助我们为你解决问题。关于IIS7里的特定错误支持的更多信息，请参考http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Diagnostics-in-IIS7/Deciphering-Error-Messages/How-to-Use-HTTP-Detailed-Errors-in-IIS7.
3.绕过—503“无可用服务”错误
有时候，你可能得到一个像这样的错误：
这个错误最可能要么暗示了服务器的关键性错误配置，因此导致IIS不能成功开始一个工作者进程/处理你的请求，要么暗示了一个系统超载，因此导致过早就拒绝了请求，从而在响应中不会有更多的错误信息可用。如果你得到这样的一个错误，请遵循我的详细指导Where did my IIS7 server go? Troubleshooting "service unavailable" errors.
使用失败请求追踪深入诊断（官方称为FREB）
如果单独只有错误不能诊断这一情况，或者需要更多的信息来决定到底是什么导致了这一错误，或者，这里没有错误（例如，链接超时），你可以利用IIS7特点，此特点非常有用，被称为“失败请求追踪”。
这个功能可以用于生成一个详细的、失败的事件追踪，与ETW非常相像，但是现在它具有更多的信息，更容易打开，能用于排错。
更重要的是，你可以组装一个失败信息追踪，仅仅追踪那些特殊的、失败了的请求，例如：一个特别的响应状态/次状态代码，特别的冗长的事件，或者超时事件。
为了完成这些，如果你还没有安装它，你首先要安装它。
在Vista上： 控制面版→程序，打开或者关闭Windows 特性，检查网络信息服务→环球网服务→安全和诊断→追踪
在Windows 2008服务器上：开始→运行→服务器管理→任务→网络服务(IIS)→添加任务服务，检测网络服务器→安全和诊断→追踪
然后，要使IIS产生这些登入，你需要做两件事：
1)向你想要追踪的网页发送失败请求追踪。
在InetMgr,中，在左边的树形图中选择你的网站，然后点击Actions窗口下面的“失败请求追踪…”.，在那里，选择Enable框。
2)对事件和选择失败定义建立一个失败请求追踪
在InetMgr中，选择你在树形图中想要追踪的网站/应用程序/虚拟目录,点击“失败请求追踪规则”图标，点击“补充”，按向导建立规则。
你可能会被问到想要追踪什么内容（基于扩展名），什么时候认为请求是失败的（在Longhorn 服务器里的响应状态代码以及冗长事件）或者什么时候超时，最后才是你要追踪的事件。除非你确定自己要找的信息，否则我推荐采用默认来选择事件。
现在，当你发出请求，如果它遇到失败定义，详细追踪将作为XML文件登录，你可以查看XML文件，还可以在%systemdrive%/inetpub/logs/FailedReqLogFiles/W3SVC 文件夹中找到这个文件。
如果你双击这个文件，打开它，可以看到里面早已有XSL样式表，XSL样式表显示了追踪事件。在Longhorn服务器，这个样式表有一个大的修改，可以更好地突出重要信息。如果你想要了解更多的信息，可以看http://blogs.iis.net/bills/archive/2006/10/19/Making-Failed-Request-Tracing-More-Approachable.aspx。你可以下载新的样式表，把它用在你的Vista机器上。
失败的请求追踪日志给请求提供了详细的操作信息，此请求可以用于许多不同的方式中，进一步诊断更复杂的问题，而这些复杂问题可能来自于多个模块操作。例如：如果一个url重写模块改变了请求里的url，后来导致静态的文件处理器不能找到文件，SetUrl事件可以提供需要的信息。日志也提供这样重要的信息：每一个模块执行的时间，每一个嵌入模块操作的结果（经常包括事物不能工作的原因），也包括每次通过设置一个错误响应状态代码时，模块操作请求失败的情况。
最后，失败请求追踪的其中一个好处就是你没必要作为客户来接受错误信息。作为管理者，你可以安装它来控制错误，当错误发生时，登录执行法定追踪，允许你把功能留在生产中。把它看成是增强型标记上的登录请求。想了解更多与失败请求追踪的信息，请看http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Diagnostics-in-IIS7/Using-Failed-Request-Tracing/Troubleshooting-Failed-Requests-using-Tracing-in-I.
将来，我会发表更多的怎样使用失败请求追踪日志来排错的具体解决方案。同时，当错误产生时，你应该做更多的准备来应付它，在你把它输入论坛之前就应该解决它。
如果你刚刚把你的应用程序转移到IIS7服务器，现在当你向它发出请求时，你就会得到一个错误，这好像是近来IIS.NET论坛上的热门话题，当回答了一百多个左右的问题时，我觉得自己应该做一些事情，以帮助大家追踪并解决这些问题。
具体来说，服务器软件和网络服务器是复杂且高度可配置的系统，它们支持多层网络架构应用程序，多层网络架构应用程序使用不同技术以及子系统，因为服务器软件和网络服务器对安全、性能、以及可靠性的要求，它能承受更多的复杂性，所以它直到最后都能工作得很好，这一点很让人惊讶。IIS7力图提高诊断和解决问题的能力（当它们发生时），因此在帮助你成为一个为服务器问题排错专家方面，知道怎样使用新的IIS7 诊断学特点，将给你很大的帮助。
1.问题是什么？
当别人提出像“帮帮我，我移到IIS7，我的应用程序停止工作了”这样的问题时，我发现自己经常在论坛上问这样一个问题：它为什么不能运行？当你的网站停止工作，你要做的第一件事情就是在我们继续向前移动之前，决定这个错误到底是什么。IIS7有更好的错误信息，它们将告诉你问题到底是什么，并且帮你解决问题。
不幸的是，有时候找到这个错误是一个主要的挑战，首先让我们了解一下要解决这个问题时，你所要了解的事情。
1)解除IE “Friendly HTTP error messages”
IE将默认地代替真正的错误信息，此错误信息来自于一个附带有“友好的”错误信息的服务器，隐藏了我们需要看到的错误内容。例如：没有找到一个404错误信息，相反，你会看到下面的情况：
解除这个误解，找到真正的来自于服务器的错误，你需要去“工具> 网络选择”,选择高级键，清除“表现友好的HTTP错误信息”检验栏，然后，关掉浏览器，重新打开它，再次请求此页面。
现在假设你看到的仍然是“不能显示此网页”或者是“没找到该网页”的错误。这是因为IE没有成功地连接到你的网站，因此这里不会看到服务器错误信息。在Where did my IIS7 server go? Troubleshooting "server not found" errors.我详细地告诉大家怎样处理这样的情况。
另外： 如果你排错时，不想与IE产生混乱（尤其是因为IE的超攻击性的高速缓存，你发现自己得到一些高速缓存页面），最好的办法就是使用选择的一个可信的简单的http工具，并且重新请求它。我推荐WFETCH，它包含在IIS6 Resource Kit tools中（你可以只在XP/Windows 2003安装它，然后要么在那里运转它，或者是把wfetch.exe复制到你的Vista/LHS框）。
2.找到IIS7详细错误
IIS7引进了一种新的特定的错误特点，这种新的错误特点默认地隐藏错误反应（此错误反应是由服务器发送到远程客户的），用一个基本的错误信息代替它们。这对你的网站的安全非常重要，因为错误经常包含一些敏感的信息，而你不想让其它人看到这些敏感信息，但是因为你不能看到错误的具体信息，所以更难找出问题的根源。因此，如果你从另一台机器重新访问你的网站，你仍然会得到一个与下面情况相似的基本错误：
在这里你有两个选择 ：
1)从服务器机器上发出本地请求。在默认的情况下，你将得到一个详细的错误。
2)为远程客户找到详细错误 。
首先，如果你的错误是一个ASP.NET特例（你可以分辨出它是否是“运转时间错误”，它是否含有框架版本），请注意ASP.NET用它自己安装的特定错误覆盖了IIS定制错误机制，因此你能关掉ASP.NET特定错误，检查详细的ASP.NET特例。你没必要为了ASP.NET特例安装IIS7特定错误（在两个地方都做这件事是非常愚蠢的）。关掉ASP.NET特定错误，把下面的内容放到你的web.config:
如果该错误不是ASP.NET错误，关掉IIS7特定错误，允许错误响应（自于你的应用程序）被发送到远程客户，而且不会被IIS7特定错误模块审查。.
通过运行“开始>运行>inetmgr.exe”,，选择你的网站/应用程序/左侧树形图的虚拟目录，点击“错误页码”光标，再点击“编辑特点设置”行为，然后选择“详细错误”，你就从IIS7 Admin工具完成了这一过程。
你也可以从一个提升的命令行提示符（作为网络管理员运转）完成这一过程：
> %windir%/system32/inetsrv/appcmd.exe set config "Default Web Site/yourapp" /section:httpErrors /errorMode:Detailed
这里就是你就要用你的网站名代替“默认网站”的地方，以及用虚拟途径代替“/yourapp”的地方，以方便你能找到错误的详细信息。
注意：当你调试时，请为远程请求将设置返回到特定错误，否则会威胁到你的网站的安全。下面是使用AppCmd怎样完成它的步骤：
> %windir%/system32/inetsrv/appcmd.exe set config "Default Web Site/yourapp" /section:httpErrors /errorMode:DetailedLocalOnly
现在，你应该得到了错误的详细信息—例如，我先前得到的错误如下（这是Vista错误页码—Longhorn Server 和Vista SP1错误页码会更好看些，在这里看例子）：
注意这个错误包含许多有用的信息：
1) 标题包括次状态代码，次状态代码是一个IIS特别代码，进一步描述问题。大部分常见问题有一个典型的<状态代码>.<次状态_代码>联合，你可以在google上寻找额外的信息。
2) 这个页码暗示了IIS Web Core是什么模块，在哪种MapRequestHandler情况下会发生错误。当你在调试服务器问题时，这个信息非常重要，尤其是在IIS7+世界中，当大部分错误发生在其中一个模块上，而此模块参与了请求运转，这个信息更加重要。
3) 页码给你提供了许多有用的请求信息，例如：被请求的url，以及它解决问题的物理途径。看到请求变成一个错误的url，或者因为错误的虚拟目录映射，而被发送到错误的物理途径时，大部分404错误就在这里解决了。
4) “最可能的原因”以及“你能干什么”版块为错误提供了最有可能的解释，以及你可以做些什么。对于大部分常见的IIS7错误，它们就是完全正确的。
5) 注意：当你带着错误来到论坛，我期望你能提供一个详细的错误，帮助我们为你解决问题。关于IIS7里的特定错误支持的更多信息，请参考http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Diagnostics-in-IIS7/Deciphering-Error-Messages/How-to-Use-HTTP-Detailed-Errors-in-IIS7.
3.绕过—503“无可用服务”错误
有时候，你可能得到一个像这样的错误：
这个错误最可能要么暗示了服务器的关键性错误配置，因此导致IIS不能成功开始一个工作者进程/处理你的请求，要么暗示了一个系统超载，因此导致过早就拒绝了请求，从而在响应中不会有更多的错误信息可用。如果你得到这样的一个错误，请遵循我的详细指导Where did my IIS7 server go? Troubleshooting "service unavailable" errors.
使用失败请求追踪深入诊断（官方称为FREB）
如果单独只有错误不能诊断这一情况，或者需要更多的信息来决定到底是什么导致了这一错误，或者，这里没有错误（例如，链接超时），你可以利用IIS7特点，此特点非常有用，被称为“失败请求追踪”。
这个功能可以用于生成一个详细的、失败的事件追踪，与ETW非常相像，但是现在它具有更多的信息，更容易打开，能用于排错。
更重要的是，你可以组装一个失败信息追踪，仅仅追踪那些特殊的、失败了的请求，例如：一个特别的响应状态/次状态代码，特别的冗长的事件，或者超时事件。
为了完成这些，如果你还没有安装它，你首先要安装它。
在Vista上： 控制面版→程序，打开或者关闭Windows 特性，检查网络信息服务→环球网服务→安全和诊断→追踪
在Windows 2008服务器上：开始→运行→服务器管理→任务→网络服务(IIS)→添加任务服务，检测网络服务器→安全和诊断→追踪
然后，要使IIS产生这些登入，你需要做两件事：
1)向你想要追踪的网页发送失败请求追踪。
在InetMgr,中，在左边的树形图中选择你的网站，然后点击Actions窗口下面的“失败请求追踪…”.，在那里，选择Enable框。
2)对事件和选择失败定义建立一个失败请求追踪
在InetMgr中，选择你在树形图中想要追踪的网站/应用程序/虚拟目录,点击“失败请求追踪规则”图标，点击“补充”，按向导建立规则。
你可能会被问到想要追踪什么内容（基于扩展名），什么时候认为请求是失败的（在Longhorn 服务器里的响应状态代码以及冗长事件）或者什么时候超时，最后才是你要追踪的事件。除非你确定自己要找的信息，否则我推荐采用默认来选择事件。
现在，当你发出请求，如果它遇到失败定义，详细追踪将作为XML文件登录，你可以查看XML文件，还可以在%systemdrive%/inetpub/logs/FailedReqLogFiles/W3SVC 文件夹中找到这个文件。
如果你双击这个文件，打开它，可以看到里面早已有XSL样式表，XSL样式表显示了追踪事件。在Longhorn服务器，这个样式表有一个大的修改，可以更好地突出重要信息。如果你想要了解更多的信息，可以看http://blogs.iis.net/bills/archive/2006/10/19/Making-Failed-Request-Tracing-More-Approachable.aspx。你可以下载新的样式表，把它用在你的Vista机器上。
失败的请求追踪日志给请求提供了详细的操作信息，此请求可以用于许多不同的方式中，进一步诊断更复杂的问题，而这些复杂问题可能来自于多个模块操作。例如：如果一个url重写模块改变了请求里的url，后来导致静态的文件处理器不能找到文件，SetUrl事件可以提供需要的信息。日志也提供这样重要的信息：每一个模块执行的时间，每一个嵌入模块操作的结果（经常包括事物不能工作的原因），也包括每次通过设置一个错误响应状态代码时，模块操作请求失败的情况。
最后，失败请求追踪的其中一个好处就是你没必要作为客户来接受错误信息。作为管理者，你可以安装它来控制错误，当错误发生时，登录执行法定追踪，允许你把功能留在生产中。把它看成是增强型标记上的登录请求。想了解更多与失败请求追踪的信息，请看http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Diagnostics-in-IIS7/Using-Failed-Request-Tracing/Troubleshooting-Failed-Requests-using-Tracing-in-I.
将来，我会发表更多的怎样使用失败请求追踪日志来排错的具体解决方案。同时，当错误产生时，你应该做更多的准备来应付它，在你把它输入论坛之前就应该解决它。
扫一扫
129
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
