在 IIS 应用程序池回收期间调试应用程序行为答案

【问题标题】：Debugging application behavior during IIS App pool recycle在 IIS 应用程序池回收期间调试应用程序行为
【发布时间】：2011-04-15 14:07:40
【问题描述】：

我有一个用 C# 编写的 Web 服务。它在池回收过程中表现得相当奇怪。

如果我配置一个包含 5 个工作进程的池，应该在 100 个请求后回收（在生产中它实际上是 10000 个，但没关系）。我对每个进程的前 100 个（即 500 个请求）得到了正确的响应，但之后一些请求返回了不正确的结果（我也得到了超时，但这没关系，因为进程正在回收）。

由于这些不正确的结果似乎发生在回收之后，因此在服务启动时，仅附加调试器并查看会发生什么有点困难（因为在回收发生时调试器已分离）。

所以我的问题是：
1.有没有人知道调试这种东西的好方法

编辑：2. 碰巧知道可能出了什么问题的人（服务在请求之间没有状态信息）-我通过附加调试器并幸运地看到异常（在全局异常中捕获）发现了错误处理程序-上帝我讨厌那些）：但是第一个问题仍然存在。有没有比附加调试器更简单的方法，希望你能及时看到错误。

【问题讨论】：

【解决方案1】：

你应该清楚什么是不正确的结果。如果不是 .NET 错误，您应该检查您的代码并在您自己的代码上添加一些应用程序级别的日志记录。

调试器只能在您没有其他可求助的情况下提供帮助。

【讨论】：

好吧，我得到一个空结果，格式正确但没有内容 - 所以很可能是某个地方的空值。该代码是一个大型库的一部分，没有人真正关心正确的日志记录，而且我不打算在数千行代码行中散布随机日志记录语句来找出我的空值是在哪里“创建”的（如果这样的事情可以说的是空值）。如果我可以附加调试器并查找 nullreferenceexception（或类似的），至少不会。
我个人会捕获异常转储并分析原因。但是，当您需要专家时，您可以通过support.microsoft.com 打开支持案例。

【解决方案2】：

我最终要做的（目前）是删除大多数“半全局”try/catch/do-nothing 处理程序，然后编写一个 SoapExtension 来处理“未处理的异常”，并转储所有我可以接近的信息。

我从 Jeff Atwood 在 CodeProject 上的文章中获得了大部分灵感：http://www.codeproject.com/kb/aspnet/ASPNETExceptionHandling.aspx

它实际上与附加调试器不同，但现在必须这样做。

【讨论】：