是否有人知道在 IIS 回收发生时记录当前正在运行的所有工作流程请求的最佳方法。
如果您转到 IIS > 工作进程 > 选择应用程序池 > 查看当前请求，您将获得请求列表。
我们偶尔会进行回收。如果我们能够看到服务器上 w3wp.exe 的 RAM 快速增加，并且我们检查请求列表，我们通常能够查明问题的根源（URL 为我们提供足够的信息来继续）。
我们已设置 logEventOnRecycle 来记录该事件，并且这可行，但细节却毫无用处。
在完美的世界中，请求列表将进入事件日志的详细信息。
在一个更加完美的世界中，我们的团队会通过电子邮件以循环方式收到请求。
还有人走过这条路吗？
答案1
尝试 DebugDiag 工具，这是迄今为止最容易使用的免费 MS 工具。它易于设置，可以捕获崩溃/挂起，并为您提供了一种不错的方法来查看其转储文件的内容。它多次将我们直接指向代码中的源代码。
这是一篇快速设置文章，捕获崩溃进程的简单“崩溃转储”的步骤来自一位 MS 博客作者。
值得一试，看看您是否能找到导致回收的原因。