ASP.Net MVC 3 应用程序在应用程序池回收时随机失败答案

【问题标题】：ASP.Net MVC 3 application failing randomly upon application pool recycleASP.Net MVC 3 应用程序在应用程序池回收时随机失败
【发布时间】：2013-08-15 06:51:49
【问题描述】：

我有一个 Windows 2008 R2 服务器和一个 ASP.Net 2.0 Web 应用程序，在 IIS 的默认网站上运行，使用经典 .NET AppPool。下面我有一个使用 ASP.NET v4.0 集成管道 AppPool 运行 MVC 3 的虚拟应用程序。

在应用程序池自动回收后，MVC 虚拟应用程序经常失败。修复方法是手动回收 ASP.NET 4.0 AppPool。我只需要回收一次，它总能解决问题。

我收到的应用程序错误看起来像是程序集未正确加载时出现的错误。它们由NullReferenceException 和Object reference not set to an instance of an object 组成，用于控制器和视图模型。

问题是我无法按需重现此问题以正确调试问题。我曾认为应用程序池回收的顺序可能是一个问题，因此我将经典池设置为每晚凌晨 1 点重新启动，集成池在凌晨 1:15 重新启动。不幸的是，这没有帮助。

这个关于assemblies being loaded on demand 的答案很有趣，但是我不确定为什么这个错误很少发生，而且似乎是随机的。

有没有人知道我如何能够不断地重现问题和/或潜在的解决方案？谢谢。

更新以包含示例堆栈跟踪：

Exception information: 
    Exception type: NullReferenceException 
    Exception message: Object reference not set to an instance of an object.
   at Bookstore.Controllers.BooksController.<>c__DisplayClass78.<Details>b__76(Grade g)
   at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at Bookstore.Controllers.BooksController.Details(String booktitle)
   at lambda_method(Closure , ControllerBase , Object[] )
   at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters)
   at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass37.<>c__DisplayClass39.<BeginInvokeActionMethodWithFilters>b__33()
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass4f.<InvokeActionMethodFilterAsynchronously>b__49()
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass37.<BeginInvokeActionMethodWithFilters>b__36(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.<>c__DisplayClass2a.<BeginInvokeAction>b__20()
   at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.<BeginInvokeAction>b__22(IAsyncResult asyncResult)
   at System.Web.Mvc.Controller.<>c__DisplayClass1d.<BeginExecuteCore>b__18(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
   at System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
   at System.Web.Mvc.MvcHandler.<>c__DisplayClass6.<>c__DisplayClassb.<BeginProcessRequest>b__4(IAsyncResult asyncResult)
   at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

【问题讨论】：

堆栈跟踪会很有用
刚刚更新了要包含的问题，谢谢。
您是否尝试过将 MVC 应用程序设置为单独的站点（不是嵌套的）以查看是否会有所改变？不应该，但尝试一下可能有用。
如果您在应用程序池回收期间浏览站点，通常会看到这些错误 - 所有资源都被释放，因此当您返回使用它们时，您的所有“对象”都为“空”。 a) 禁用应用程序池回收 b) 不要将 InProc 用于 SessionState（使用 DB），另请参阅此页面以启用在回收应用程序池时登录 IIS 以确认：blogs.iis.net/ganekar/archive/2008/12/12/…

标签： asp.net asp.net-mvc iis

【解决方案1】：

查看多个堆栈跟踪后，罪魁祸首似乎总是与实体框架有关。

This question 听起来与我们发现的非常相似。我们有一个类似的理论：在 ASP.Net 加载程序集的顺序中可能存在竞争条件，导致实体框架有时会“中断”。我们实现了答案as mentioned，到目前为止它一直在工作。令人沮丧的是，我们从未能够始终如一地重现该问题，因此只有时间才能证明修复是否有效。

【讨论】：