asp.net – 在.NET 4.6升级后,w3wp.exe与ThreadAbortException的

在过去的几天中,我们看到w3wp.exe工作进程的间歇性崩溃服务于我们公司网站的主应用程序池.有时崩溃是孤立的,IIS能够成功重新启动工作进程.但是如果在5分钟内发生超过5次崩溃,IIS Rapid Fail Protection将启动并停止应用程序池.以下是崩溃前的应用程序事件日志中的示例条目：

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,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:WindowsSysWOW64inetsrvw3wp.exe
Faulting module path: C:WindowsSYSTEM32KERNELBASE.dll
Report Id: db5b0d5b-6cd0-11e5-9418-005056900458
Faulting package full name: 
Faulting package-relative application ID:

现在,ThreadAbortException不应该导致w3wp.exe崩溃,每次执行标准的Res??ponse.Redirect()时都会抛出它. MSDN confirms this,我也用simple test证实了这一点.但是,至少有一个人最近遇到类似的一个类似的环境：Thread.Abort in ASP.NET app causes w3wp.exe to crash.(但这可能是一个无关的问题)

我们的环境：

>具有购物车和合作伙伴网络服务的企业网站;目标.NET 4.5. (90万行自定义代码,包括业务逻辑DLL和内部库).
> 2个使用Windows NLB的负载平衡池中的VMWare Web服务器
> IIS 8.0 / Windows 2012 Server Standard / .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.

我们还部署了一个新版本的网页代码(像我们每周做几次).自然地,我们对任何潜在的崩溃漏洞仔细检查了代码更改,但是我们的任何更改似乎都不容易受到无限循环,递归堆栈溢出或高内存使用的影响 – 当w3wp.exe遇到未处理的异常时,这是正常的肇事者.

有时,崩溃会在几分钟之内影响一个Web服务器,但其他时候只会影响一个Web服务器.

我试过的事情

>重新启动服务器并安装所有Windows更新.
>分析IIS日志,查看崩溃之前是否有可疑/坏请求.我找不到任何模式 – 所有的请求
看起来很正常
>启用w3wp.exe的自动崩溃minidumps(如https://msdn.microsoft.com/en-us/library/bb787181.aspx所述),并使用WinDbg对其进行分析.不幸的是,CLR“兴趣堆栈跟踪”并没有显示任何有用的东西,只是一些与我们的代码无关的空白GC框架：

06002

有任何想法吗？

更新：

我们已经在我们的Web服务器上回滚了.NET 4.6和最新的Windows更新.我们一直在监控这个2或3天,这取决于服务器何时回滚,并且在每种情况下,尽管维护了相同的应用程序代码,但是已经有零次后续的崩溃.这真的证明了.NET 4.6或其他Windows更新导致间歇性崩溃,而不是我们的代码,因为w3wp.exe以前每天都崩溃了几次.

我们现在正在试图向Microsoft支持部门证明这一点,但是这是一场艰苦的战斗,因为这个问题是随机的,间歇性的,我们无法可靠地重现. (他们提供了一个dump analysis,但似乎是一个红色的鲱鱼.)我们也正在重新应用更新组,等待几天来观看崩溃,以便隔离错误的更新.显然这是一个乏味的过程.

更新#2：

我们现在已经重新应用了所有在故障排除中删除的所有的“.NET.NET V6.0更新”,并且服务器已经运行了好几天而没有崩溃.重新应用的唯一的东西是.NET 4.6及其自己的更新,但我的管理是可以理解的,不太可能安装可能导致生产崩溃的东西.所以我继续与MS一起分析不同的崩溃转储,以确定问题.