在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类创建的并行线程正在运行。
第三方ISAPI筛选器可能会导致此问题。
在这种情况下，硬件错误偶尔会成为意料之外的罪魁祸首。除了一个不起眼的DLL中的一个小方法外，一切都可以完美地工作。
或者这也发生在多台机器上？尝试另一个。
当我的IHttpHandler.ProcessRequest()函数返回时我经历了这个问题，而我仍然在WriteAsync()或FlushAsync()上进行HttpResponse或HttpResponse.OutputStream操作（即，当我还没有等待从这些函数返回的Task时）。
虽然你的问题是在async / await引入C＃之前编写的，所以你不会使用这些关键字，听起来好像你在做很多异步操作（异步处理程序，并行线程等），所以我打赌很有可能这是您遇到的相同的潜在问题。
在某些情况下，可能只是一个错误，您的请求处理程序无法确保WriteAsync()或FlushAsync()操作完成，并且代码修复应该只是为了确保您在从ProcessRequest()返回之前等待操作完成。但是，在我的情况下，我在一些自定义超时逻辑中包装WriteAsync()或FlushAsync() Task，并且在客户端没有及时响应的情况下故意不等待底层的Task。
在我的本地计算机（Windows 1809，.NET 4.7.2）上，当我不想等待HttpContext.Request.Abort()或WriteAsync()操作完成时，似乎可以通过调用FlushAsync()来保持我的自定义超时逻辑，同时避免此AccessViolationException。但是，此修复程序似乎不适用于我测试的某些Windows Server 2016或2012 R2服务器。因此，在最近的Windows版本中，行为有可能发生了变化，尽管我并不是100％确定没有其他变量可以解释我测试过的机器之间的行为差异。