尝试解决无响应/挂起/损坏的 IIS 网站时应采取哪些步骤？

Question 1

我发现以下指导作为一般收集指南非常有效。

确定症状

尝试（尽快）确定问题的表面积：

连接性？（Telnet 很好；如果您在浏览器中看到返回的错误页面，则显然某些东西正在运行 - 请先消除连接）
常规应用程序池故障，或者特定于内容类型？（ASPX 文件可以工作/不工作，但 .HTM 可以工作吗？您是否有针对每个应用程序和内容类型的金丝雀文件？）
特定的应用程序内故障、挂起或崩溃？（大部分都是针对挂起和应用程序故障；崩溃决定了它们自己的方法：获取崩溃转储，进行调试）

一般来说，一定要把它写下来，因为你可能要处理多种症状，而且能够参考你对早期事件的记录是非常有价值的。

收集数据

又称为“收集临时数据” - 在发生中断时，您只有有限的时间来收集某些数据。某些数据（如进程内存）是短暂的，如果您先采取纠正措施，它们就会消失。其他数据（如日志）可能需要一些时间来复制，但您可以轻松地在之后获取它们。因此，了解您现在需要收集哪些数据，以及恢复后需要收集哪些数据。

随便抓时间敏感/及时数据您需要稍后解决该问题。不要担心持久性的东西 - 事件日志和 IIS 日志会保留下来，除非您是一个强迫性清除者，在这种情况下：停下来。（那些没有上周事件日志的人注定会重蹈覆辙）
确定受影响的工作进程（然后丢弃）
- APPCMD LIST WP可以帮助解决这个问题，或者工作进程 GUI在服务器等级。
- 如果使用 GUI，请不要忘记通过右键单击工作进程来查看当前请求 - 如果您得到它，它会向您显示请求被卡在哪个模块（DLL）中，这可以帮助您尽早猜测原因。
- 确定范围（即只有一个应用程序池，多个应用程序池，两个具有依赖关系的应用程序池 - 这取决于您的应用程序和网站布局）
- 获取内存转储的工作进程- 确定哪个应用程序池存在问题后，确定相关的工作进程，然后使用任务管理器通过右键单击该进程来创建内存转储。记下文件名以备后用。
- 注意任务管理器位数：您需要使用任务管理器的位数相同作为您攻击的工作进程 - 如果您使用 64 位任务管理器转储 32 位 WP (w3wp*32)，它将无法解释。如果在 64 位 Windows 上转储 32 位进程，您需要退出任务管理器，运行 %WINDIR%\SYSWOW64\TaskMgr.exe 以获取 32 位版本，然后使用相同位数转储。（绕行十秒钟，但您必须当时这样做）。

恢复服务

现在，您已经获得了诊断所需的所有时间点信息，因此是时候让网站客户重新开始业务了。

回收这最小工作进程数以恢复服务。
- 不必费心停止和启动网站，通常需要刷新应用程序池才能使网站重新运行，这就是回收站所做的。
- 回收应用程序池9/10次就足够了。
- 请注意，回收似乎发生在下一个请求进来时（即使现有的 WP 已被告知消失），因此工作进程不得立即重新出现。这并不意味着它没有起作用，只是没有请求在等待。
- IIS重置通常是不懂行的人使用的工具。不要使用它除非你需要所有网站同时终止并重新启动。（这就像试图用砖头把钉子钉进墙上。它可能会起作用，但你看起来像个白痴，而且在某个时候会有附带损害）。
- 您可能有其他应用程序依赖项 - 应用程序池依赖于其他应用程序池、数据库或外部系统... 您必须执行的操作才能恢复服务，这告诉您有关问题范围的信息。列表中的最后一个是完全重新启动，但除非内核级驱动程序真的搞砸了，否则这通常不是必要的，只是您无法确定哪些事情是必要的，这是一个有用的万能方法...

确定原因 即查看并思考您收集的数据。

获取日志和内存转储，寻找共同点，与应用程序开发人员联系，使用以下工具调试转储：调试诊断（或更新版本）或 WinDBG，等等。

为下次设置

您知道您已经修复了这个问题吗？如果没有，尤其是如果其他方面似乎没有变化，请考虑一下如果再次发生这种情况，您可以更好地做好准备，并记录下哪些信息。

不要以为这是最后一次- 制定计划为了下次你需要收集什么，以此时间为准。
- 例如，如果所有请求都针对同一个 URL，则需要实施一些额外的检测或日志记录，或者实施失败请求跟踪规则，以帮助识别页面上出现问题的位置。
- 性能监视器日志很有用（如果有疑问，也可以获取 perfmon 日志）。
- 看看其他可能有用的工具——ProcDump、XPerf/WPT/WPR 等等。如果你只有一把锤子，那么每个问题必须是钉子…
- 想想在寻找实际根本原因时“掩盖”问题是否可以接受 - 如果中断真的很严重，那么调整应用程序池的回收设置之类的操作可能是可以接受的，以尽量减少可能性或持续时间（除非这与能够解决问题相冲突）...

Answer