在过去的几天里,我们看到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, 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.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服务器。
我尝试过的事情:
> 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以前每天都会崩溃几次。 < / p>
我们现在正试图向微软支持证明这一点,但这是一场艰苦的战斗,因为这个问题是随机的,间歇性的,我们无法可靠地重现它。 (他们提供了dump analysis,但它似乎是一个红色的鲱鱼。)我们也正在重新应用组中的更新并等待几天观察崩溃,以便隔离错误的更新。显然这是一个繁琐的过程。
更新#2:
我们现在重新应用了在故障排除中删除的所有.NET 4.6以前的Windows更新,并且服务器已运行了几天而没有崩溃。重新应用的唯一事情是.NET 4.6及其自己的更新,但我的管理层可能不愿意安装可能导致生产崩溃的事情。因此,我继续与MS合作分析不同的故障转储以查明问题。
答案 0 :(得分:5)
您没有显示任何代码,但证据表明这是您的应用程序代码的问题,而不是.NET 4.6或ThreadAbortException
专门的问题。
此处的基本故障排除步骤:您说有代码更改和环境更改;所以要把其中一个排除在外。
在安装了.NET 4.5的VM上测试应用程序。如果您没有收到错误,可能是.NET 4.6的原因。
在同一台服务器上测试旧版应用。如果没有注意到问题,可能会导致代码更改。
在安装了VS.NET的计算机上测试应用,附加到w3wp.exe
进程并进行调试(工具&gt;附加到进程)。抓住ThreadAbortException
并追踪它。
如果您还没有,那么您应该记录您的w3wp.exe
进程停止的事件..虽然这显然不会处理所有异常。谷歌这个,但this guy describes a solution that I also use
如果您还没有,请在Application_Error
中定义Global
处理程序以记录异常。 Microsoft demonstrates this。创建一个System.Web.Configuration
选项,您可以在web.config
文件中切换以启用不同级别的日志记录,包括写入本地文件,以及写入Windows事件日志。您还可以安装日志处理程序工具,如Elmah。
创建一个准确的简单Web应用程序并测试Response.Redirect
以验证它是否使用.NET 4.6崩溃w3wp.exe
(工作进程)。我做了这个,但没有,所以我怀疑你的代码。或者可能是奇怪的服务器/补丁级紧急问题..这些步骤应该可以帮助您查明它。
附注:即使它不应影响应用程序流程,我建议修复Response.Redirect()
问题。我们最近在一个企业应用程序中做了这个,是的,这是一个广泛的范围的变化,但我们不再获得TAE例外。修复很简单:只需调用Response.Redirect(false);
,然后确保在调用该函数后没有代码将运行(例如,调用return
)。 This post explains
答案 1 :(得分:2)
@Jordan Rieger,这个bug应该在.NET 4.6.1中修复 您能否确认新框架中是否修复了问题?或者它是否仍然存在?感谢。
答案 2 :(得分:0)
4.6不稳定(http://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/),如果可能,请恢复为4.5.x.