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:\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. (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一起分析不同的崩溃转储,以确定问题.
