在GENERAL_REQUEST_ENTITY期间，POST结果在ASP .NET会话状态期间出错，永远无法解锁

我一直在试图追查一个ASP .NET会话状态保持locking的状态的根本原因，因为一个意外的错误终止了Web请求。我们使用SQL Server会话状态提供程序进行会话，因为我们在Web场中有多个服务器。这个问题首先以许多请求的forms出现，没有明显的原因，这些请求被卡在生命周期的“AcquireRequestState”事件中。我能够在SQL服务器的会话状态数据库中find相应的条目，这些条目都是locking的（列locking= 1）。我还能够将这些请求与HTTP状态码为500（子状态为0）的IIS日志中的条目关联起来。这些发现使我相信，在某些情况下，一个请求正在出错，但不会像应该的那样释放对会话状态的locking。

我在IIS中为状态码为500的网站启用了“失败的请求追踪”，其中所有可用的提供者都select了详细的“详细”设置。自从我收集了几个导致永久lockingASP .NET会话的失败痕迹。它们都具有相同的特征：

它们都是浏览器发布要处理/保存的数据的“POST”请求。
他们都有事件，表明'会话'模块在REQUEST_ACQUIRE_STATE事件中被调用。此时，请求会将会话状态数据库中的行标记为“locking”。这是正常的和预期的。
它们都具有GENERAL_READ_ENTITY_START，GENERAL_READ_ENTITY_END和GENERAL_REQUEST_ENTITY条目，这些条目似乎是在作为请求的一部分发布到服务器的数据中读取的。这似乎是一个缓冲的操作，因为这些事件重复一遍又一遍地读取发布数据的一些子集。
在“读取实体”相关事件期间的某一时刻发生错误。一些错误代码为“错误的函数（0x80070001）”，其他错误代码为“由于线程退出或应用程序请求（0x800703e3）”导致I / O操作中止。
一旦遇到错误，它们将直接跳转到END_REQUEST事件。

这里的问题是，在正常情况下，应该有一个RELEASE_REQUEST_STATE事件，它允许会话模块释放它在会话上的locking。 在这种情况下，此事件将被跳过。 可以肯定的是，我还启用了“200”状态代码的失败请求跟踪，并生成了几个成功请求的跟踪，这些请求确实通过Session模块处理了RELEASE_REQUEST_STATE事件。

我的理论在这一点是某种networking问题导致'不正确的function'和'I / O操作已被中止由于线程退出或应用程序请求'的错误，但我不明白为什么这似乎导致请求处理跳过RELEASE_REQUEST_STATE事件。如果请求经历了REQUEST_ACQUIRE_STATE，那么它也应该也是RELEASE_REQUEST_STATE。我不喜欢说这是IIS或ASP .NET中的一个错误，但是在这一点上它肯定会出现这种情况。

是否有任何configuration更改，可以帮助确保在所有错误情况下触发“RELEASE_REQUEST_STATE”？