asp.net - .NET 4.6 升级后 w3wp.exe 间歇性崩溃并出现 ThreadAbortException

Question

在过去的几天里，我们看到为我们公司网站的主应用程序池提供服务的 w3wp.exe 工作进程间歇性崩溃。有时崩溃是孤立的，IIS 能够成功地重新启动工作进程。但是，如果 5 分钟内发生 5 次以上的崩溃，IIS 快速故障保护就会启动并停止应用程序池。以下是崩溃前应用程序事件日志中的一个示例条目:

An unhandled exception occurred and the process was terminated.
Application ID: /LM/W3SVC/2/ROOT
Process ID: 3640
Exception: System.Threading.ThreadAbortException
Message: Thread was being aborted.
StackTrace:    at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
   at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)

由于 ThreadAbortException 导致崩溃后，立即记录了一个更严重的事件:

Faulting application name: w3wp.exe, version: 8.0.9200.16384, time stamp: 0x5010885f
Faulting module name: KERNELBASE.dll, version: 6.2.9200.17366, time stamp: 0x554d16f6
Exception code: 0xe0434352
Fault offset: 0x00010192
Faulting process id: 0xe38
Faulting application start time: 0x01d100dc662652d6
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\SYSTEM32\KERNELBASE.dll
Report Id: db5b0d5b-6cd0-11e5-9418-005056900458
Faulting package full name: 
Faulting package-relative application ID: 

现在，ThreadAbortException 永远不会导致 w3wp.exe 崩溃，因为每次执行标准 Response.Redirect() 时都会抛出它。 MSDN confirms this ，我也用 simple test 确认了.然而，最近至少有另一个人在类似的环境下看到了类似的崩溃: Thread.Abort in ASP.NET app causes w3wp.exe to crash . (但这可能是一个无关的问题。)

我们的环境:

带有购物车和合作伙伴网络服务的公司网站；面向 .NET 4.5。 (900,000 多行自定义代码，包括业务逻辑 DLL 和内部库。)

使用 Windows NLB 的负载平衡池中的 2 个 VMWare Web 服务器

IIS 8.0/Windows 2012 服务器标准版/.NET 4.6.00081

应用程序池在 32 位模式下运行，因为我们必须支持少数调用旧 VB6 DLL 的经典 ASP 页面。

背景:

在崩溃开始前几天，我们升级到 .NET 4.6。我们启用了新的 RyuJIT(默认设置)并且我们已经安装了所有更新来解决这里描述的关键编译器问题: http://blogs.msdn.com/b/dotnet/archive/2015/07/28/ryujit-bug-advisory-in-the-net-framework-4-6.aspx .

我们还部署了新版本的 Web 代码(就像我们每周做的那样)。自然地，我们仔细检查了代码更改是否有任何潜在的崩溃漏洞，但我们的任何更改似乎都不会受到无限循环、递归堆栈溢出或高内存使用率的影响——这是 w3wp.exe 因未处理的异常而崩溃时的正常罪魁祸首。

有时崩溃会在几分钟内影响另一台 Web 服务器，但有时只有一台 Web 服务器受到影响。

我试过的东西:

重新启动服务器并安装所有 Windows 更新。

分析 IIS 日志以查看在崩溃之前是否有任何可疑/错误请求。我找不到任何模式——所有的请求
看起来很正常。

为 w3wp.exe 启用自动崩溃小型转储(如 https://msdn.microsoft.com/en-us/library/bb787181.aspx 所述)并使用 WinDbg 对其进行分析。不幸的是，CLR“感兴趣的堆栈跟踪”没有显示任何有用的东西，只有几个与我们的代码无关的空 GC 帧:

> 0:026> !clrstack
> OS Thread Id: 0x1ff0 (26)
> Child SP       IP Call Site
> 2321f96c 771bdf8c [GCFrame: 2321f96c]
> 2321f9a4 771bdf8c [GCFrame: 2321f9a4]

有任何想法吗？

更新:

我们已经在我们的 Web 服务器上回滚了 .NET 4.6 和最近的 Windows 更新。我们已经监控了 2 天或 3 天，具体取决于服务器回滚的时间，在每种情况下，尽管维护了相同的应用程序代码，但随后的崩溃为零。这非常明确地证明 .NET 4.6 或其他 Windows 更新导致了间歇性崩溃， 不是我们的代码 ，因为 w3wp.exe 以前每天都会崩溃几次。

我们现在正试图向 Microsoft 支持部门证明这一点，但这是一场艰苦的战斗，因为该问题是随机的、间歇性的，而且我们无法可靠地重现它。 (他们提供了 dump analysis，但它似乎是一个红鲱鱼。)我们还在分组重新应用更新并等待几天以观察崩溃，以努力隔离有问题的更新。显然，这是一个乏味的过程。

更新 #2:

我们现在重新应用了在故障排除中删除的所有 .NET 4.6 之前的 Windows 更新，并且服务器已经运行了几天没有崩溃。唯一需要重新应用的是 .NET 4.6 和它自己的更新，但我的管理层不愿意安装可能会导致生产崩溃的东西是可以理解的。因此，我将继续与 MS 合作分析不同的故障转储以查明问题。

Answer 1

@Jordan Rieger，此错误应在 .NET 4.6.1 中修复
能否请您确认问题是否在新框架中修复？或者如果它仍然存在？谢谢。