IIS 7、ASP.NET：AccessViolationException答案

【问题标题】：IIS 7, ASP.NET: AccessViolationExceptionIIS 7、ASP.NET：AccessViolationException
【发布时间】：2009-05-08 21:52:43
【问题描述】：

IIS 7 下的 ASP.NET 应用程序出现以下异常的原因可能是什么？这是一个未处理的异常，会重新启动整个应用程序。

异常： System.AccessViolationException

消息：试图读取或写入受保护的内存。这通常表明其他内存已损坏。

堆栈跟踪：

   in System.Web.Hosting.UnsafeIISMethods.MgdIsLastNotification(IntPtr pRequestContext, RequestNotificationStatus dwStatus)
   in System.Web.HttpRuntime.FinishRequestNotification(IIS7WorkerRequest wr, HttpContext context, RequestNotificationStatus& status)
   in System.Web.HttpRuntime.OnRequestNotificationCompletionHelper(IAsyncResult ar)
   in System.Web.HttpRuntime.OnRequestNotificationCompletion(IAsyncResult ar)
   in System.Web.HttpAsyncResult.Complete(Boolean synchronous, Object result, Exception error, RequestNotificationStatus status)
   in System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)
   in System.Web.HttpApplication.ResumeStepsWaitCallback(Object error)
   in System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   in System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   in System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

[UPD]

系统： Windows Web Server 2008 64 位。

应用程序详细信息： 不使用页面架构的 ASP.NET 应用程序。它使用自定义 http 同步和异步处理程序处理请求。还有来自 ThreadPool 或由 Thread 类创建的并行线程正在运行。

【问题讨论】：

您找到解决问题的方法了吗？我有同样的问题，找不到任何解决方案。
很抱歉打扰您，您有什么想法吗？您遇到的问题是什么？

标签： asp.net iis-7 access-violation

【解决方案1】：

第三方 ISAPI 过滤器可能会导致此问题。

【讨论】：

感谢您的回答。我不使用任何第三方过滤器。纯 ASP.NET 应用程序。

【解决方案2】：

在这种情况下，硬件错误有时是意外的罪魁祸首。一切都可以完美运行，除了一个不起眼的 DLL 中的一个小方法。

或者这是否也发生在多台机器上？换一个试试。

【讨论】：

【解决方案3】：

当我的IHttpHandler.ProcessRequest() 函数返回时我遇到了这个问题，而我仍然在HttpResponse 或HttpResponse.OutputStream 上进行WriteAsync() 或FlushAsync() 操作（即，当我没有等待从返回的Task那些函数）。

虽然您的问题是在将 async/await 引入 C# 之前编写的，因此您不会使用这些关键字，但听起来您确实在执行大量异步操作（异步处理程序、并行线程等），所以我敢打赌，这很有可能与您遇到的根本问题相同。

在某些情况下，您的请求处理程序无法确保 WriteAsync() 或 FlushAsync() 操作完成可能只是一个错误，代码修复应该只是确保您等待操作完成后再从ProcessRequest()。但是，就我而言，我将WriteAsync() 或FlushAsync() Task 包装在一些自定义超时逻辑中，并且在客户端没有及时响应的情况下故意不等待底层Task。

在我的本地计算机（Windows 1809、.NET 4.7.2）上，当我不想等待 WriteAsync() 时，似乎可以通过调用 HttpContext.Request.Abort() 来保持我的自定义超时逻辑同时避免此 AccessViolationException或FlushAsync() 操作完成。但是，此修复似乎不适用于我测试过的某些 Windows Server 2016 或 2012 R2 服务器。因此，在最近的 Windows 版本中，这种行为有可能发生了变化，尽管我不能 100% 确定没有其他变量可以解释我测试过的机器之间的行为差异。

【讨论】：