当您发现一个IIS网站时，您采取了哪些步骤没有响应？
我可能会尝试先telnet到指定的端口，然后检查网站绑定和身份validation，最后重新启动它。
我想知道有经验的pipe理员在面对这样的问题时会检查什么是非常有用的。
事实上，我自己花了半个多小时试图弄清楚是什么问题，没有什么不对。 我只是重新启动网站，问题仍然存在，但重新启动IIS服务后，问题已解决。
如果我能够知道更好的跟踪或至less有用的日志loggingfunction帮助我更快地解决问题，那将会使我节省半个多小时。
{FYI我正在使用IIS 7.5}
确定症状
尽量build立（尽可能快的）问题的表面积：
连接？ （Telnet是好的;如果你在浏览器中返回一个错误页面，显然是有效的 – 首先消除连接）
一般应用程序池失败 ，或特定于内容types？ （不要ASPX文件工作/不工作，但.HTM的工作？你有每个应用程序和内容types的金丝雀文件？
具体的应用内故障，挂起或崩溃？ （其中大部分是挂起和应用程序故障;崩溃决定了他们自己的方法：得到崩溃转储，debugging它）
收集数据
抓住任何时间敏感/及时的数据，你将需要以后解决这个问题。 不要担心持久的东西 – 事件日志和IIS日志坚持，除非你是一个强迫性的清晰，在这种情况下： 停止它 。 （那些没有上周的事件日志注定要重复）
确定受影响的工作进程
APPCMD LIST WP可以提供帮助，或者服务器级别的工作进程GUI 。 如果使用GUI，不要忘记通过右键单击工作进程来查看当前请求 – 这会告诉您哪个模块的请求被阻塞。
确定范围 （只有一个应用程序池，多个应用程序池，两个依赖关系 – 这取决于您的应用程序和网站布局）
抓取 工作进程 的内存转储 – 一旦您确定了哪个应用程序池出现问题，请确定相关的工作进程，然后使用任务pipe理器通过右键单击该进程来创build内存转储。 注意后面的文件名。
还原服务
回收 最less数量的工作进程以恢复服务。
不要打扰停止和启动网站，您通常需要刷新App Pool以使网站再次运行，这就是回收站所做的事情。
回收应用程序池足够9/10次。
请注意，回收似乎发生在下一个请求进入（即使现有的WP已被告知离开），所以工作进程可能不会立即重新出现。 这并不意味着它没有奏效，只是没有任何请求正在等待。
IISReset通常是不明白的人使用的工具。 除非您需要每个网站立即终止并重新启动 ，否则不要使用它 。 （就像试图用砖头钉钉在墙上，可能会起作用，但你看起来像一个白痴，会有附带的伤害）
确定原因，即查看并思考你收集的数据。
下次设置
不要以为这是最后一次发生 – 根据这个时间制定下一次需要收集的计划 。
例如，如果请求全部针对相同的URL，则实施一些附加的检测或日志logging或失败的请求跟踪规则，这将有助于识别出现问题的页面上的位置。
性能监视器日志是有帮助的（如果有疑问，也可以获取perfmon日志）。
为什么绑定或身份validation方法（应该是静态的）会导致网站无响应？ 那些不在我的支票清单上，或者至less他们不会在我的名单上。
我要检查的第一件事是网站是否从服务器本身加载。 如果没有，可以排除几乎所有可能的networking或DNS问题。