.NET 4.6 升级后 w3wp.exe 间歇性崩溃并出现 ThreadAbortException
Intermittent crash of w3wp.exe with ThreadAbortException after .NET 4.6 upgrade
在过去的几天里，我们发现服务于我们公司网站的主应用程序池的 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, and I also confirmed it with a simple test. However, at least one other person has seen a similar crash recently with a similar environment: 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/Windows2012 服务器标准/.NET 4.6.00081
- 32 位模式下的应用程序池 运行，因为我们必须支持一些经典的 ASP 页面调用遗留 VB6 DLL。
背景：
在崩溃开始前几天，我们升级到了 .NET 4.6。我们启用了新的 RyuJIT（默认设置）并且我们已经安装了所有更新以解决此处描述的关键编译器问题：http://blogs.msdn.com/b/dotnet/archive/2015/07/28/ryujit-bug-advisory-in-the-net-framework-4-6.aspx.
我们还部署了新版本的网络代码（我们每周都会部署几次）。自然地，我们仔细检查了代码更改是否存在任何潜在的崩溃漏洞，但是 none 我们的更改似乎容易受到无限循环、递归堆栈溢出或高内存使用率的影响 - w3wp.exe 崩溃时的常见罪魁祸首未处理的异常。
有时崩溃会在几分钟内影响另一台 Web 服务器，但有时只有一台 Web 服务器受到影响。
我尝试过的事情：
- 重新启动服务器并安装所有 Windows 更新。
- 分析 IIS 日志以查看是否有任何 suspicious/bad 请求在崩溃前进入。我找不到任何模式——所有的请求
看起来很正常。
- 为 w3wp.exe 启用自动崩溃小型转储（如 https://msdn.microsoft.com/en-us/library/bb787181.aspx 所述）并使用 WinDbg 对其进行分析。不幸的是，CLR "stack trace of interest" 没有显示任何有用的信息，只有几个与我们的代码无关的空 GC 帧：
> 0:026> !clrstack
> OS Thread Id: 0x1ff0 (26)
> Child SP IP Call Site
> 2321f96c 771bdf8c [GCFrame: 2321f96c]
> 2321f9a4 771bdf8c [GCFrame: 2321f9a4]
有什么想法吗？
更新：
我们已经回滚了 .NET 4.6 和最近的 Windows 我们网络服务器上的更新。我们已经对此进行了 2 天或 3 天的监控，具体取决于服务器回滚的时间，并且在每种情况下，尽管维护了相同的应用程序代码，但后续崩溃为零。 这非常明确地证明了 .NET 4.6 或其他 Windows 更新导致了间歇性崩溃，不是我们的代码，因为 w3wp.exe 之前是每天崩溃几次。
我们现在正试图向 Microsoft 支持证明这一点，但这是一场艰苦的战斗，因为问题是随机的、间歇性的，我们无法可靠地重现它。 （他们提供了一个 dump analysis 但它似乎是一个转移注意力的问题。）我们也在重新分组更新并等待几天以观察崩溃，以努力隔离有故障的更新。显然这是一个乏味的过程。
更新#2：
我们现在重新应用了所有在故障排除中删除的 .NET 4.6 之前的 Windows 更新，并且服务器已经 运行 几天没有崩溃。唯一需要重新应用的是 .NET 4.6 和它自己的更新，但我的管理层不愿意安装可能导致生产崩溃的东西是可以理解的。因此，我将继续与 MS 合作，分析不同的故障转储以查明问题所在。
4.6 不稳定（http://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/），如果可能，恢复到 4。5.x。
您没有显示任何代码，但有证据表明这是您的应用程序代码的问题，而不是 .NET 4.6 或 ThreadAbortException 具体的问题。
这里是基本的故障排除步骤：你说有代码更改和环境更改；所以排除其中之一。
在安装了 .NET 4.5 的 VM 上测试应用程序。如果您没有收到错误，.NET 4.6 可能是原因。
在同一台服务器上测试旧版本的应用程序。如果未发现问题，则可能是代码更改。
在安装了 VS.NET 的机器上测试应用程序，附加到 w3wp.exe 进程，然后调试它（工具 > 附加到进程）。抓住 ThreadAbortException 并追踪它。
如果您还没有，您应该记录您的 w3wp.exe 进程停止的事件。虽然这显然不会处理所有异常。 Google这个，但是this guy describes a solution that I also use
如果您还没有，请在 Global 中定义一个 Application_Error 处理程序来记录异常。 Microsoft demonstrates this. Create a System.Web.Configuration option that you can toggle in your web.config file to enable different levels of logging, including writing to a local file, and writing to the windows event logs, for example. You can also install a logging handler tool like Elmah.
创建一个基本的简单 Web 应用程序并测试 Response.Redirect 以验证它是否使 w3wp.exe（工作进程）与 .NET 4.6 崩溃。我这样做了，但没有，所以我怀疑你的代码。或者可能是奇怪的 server/patch 级紧急问题。这些步骤应该可以帮助您查明它。
旁注：即使它不应该影响应用进程，我还是建议修复 Response.Redirect() 问题。我们最近在一个企业应用程序中这样做了，是的，这是一个范围很广的变化，但我们不再遇到 TAE 异常。解决方法很简单：只需调用 Response.Redirect(false);，然后确保在调用该函数后没有代码会 运行（例如调用 return）。 This post explains
@Jordan Rieger，此错误应在 .NET 4.6.1 中修复
能否请您确认问题是否已在新框架中得到解决？或者如果它仍然存在？谢谢。
在过去的几天里，我们发现服务于我们公司网站的主应用程序池的 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, and I also confirmed it with a simple test. However, at least one other person has seen a similar crash recently with a similar environment: 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/Windows2012 服务器标准/.NET 4.6.00081
- 32 位模式下的应用程序池 运行，因为我们必须支持一些经典的 ASP 页面调用遗留 VB6 DLL。
背景：
在崩溃开始前几天，我们升级到了 .NET 4.6。我们启用了新的 RyuJIT（默认设置）并且我们已经安装了所有更新以解决此处描述的关键编译器问题：http://blogs.msdn.com/b/dotnet/archive/2015/07/28/ryujit-bug-advisory-in-the-net-framework-4-6.aspx.
我们还部署了新版本的网络代码（我们每周都会部署几次）。自然地，我们仔细检查了代码更改是否存在任何潜在的崩溃漏洞，但是 none 我们的更改似乎容易受到无限循环、递归堆栈溢出或高内存使用率的影响 - w3wp.exe 崩溃时的常见罪魁祸首未处理的异常。
有时崩溃会在几分钟内影响另一台 Web 服务器，但有时只有一台 Web 服务器受到影响。
我尝试过的事情：
- 重新启动服务器并安装所有 Windows 更新。
- 分析 IIS 日志以查看是否有任何 suspicious/bad 请求在崩溃前进入。我找不到任何模式——所有的请求 看起来很正常。
- 为 w3wp.exe 启用自动崩溃小型转储（如 https://msdn.microsoft.com/en-us/library/bb787181.aspx 所述）并使用 WinDbg 对其进行分析。不幸的是，CLR "stack trace of interest" 没有显示任何有用的信息，只有几个与我们的代码无关的空 GC 帧：
> 0:026> !clrstack > OS Thread Id: 0x1ff0 (26) > Child SP IP Call Site > 2321f96c 771bdf8c [GCFrame: 2321f96c] > 2321f9a4 771bdf8c [GCFrame: 2321f9a4]
有什么想法吗？
更新：
我们已经回滚了 .NET 4.6 和最近的 Windows 我们网络服务器上的更新。我们已经对此进行了 2 天或 3 天的监控，具体取决于服务器回滚的时间，并且在每种情况下，尽管维护了相同的应用程序代码，但后续崩溃为零。 这非常明确地证明了 .NET 4.6 或其他 Windows 更新导致了间歇性崩溃，不是我们的代码，因为 w3wp.exe 之前是每天崩溃几次。
我们现在正试图向 Microsoft 支持证明这一点，但这是一场艰苦的战斗，因为问题是随机的、间歇性的，我们无法可靠地重现它。 （他们提供了一个 dump analysis 但它似乎是一个转移注意力的问题。）我们也在重新分组更新并等待几天以观察崩溃，以努力隔离有故障的更新。显然这是一个乏味的过程。
更新#2：
我们现在重新应用了所有在故障排除中删除的 .NET 4.6 之前的 Windows 更新，并且服务器已经 运行 几天没有崩溃。唯一需要重新应用的是 .NET 4.6 和它自己的更新，但我的管理层不愿意安装可能导致生产崩溃的东西是可以理解的。因此，我将继续与 MS 合作，分析不同的故障转储以查明问题所在。
4.6 不稳定（http://nickcraver.com/blog/2015/07/27/why-you-should-wait-on-dotnet-46/），如果可能，恢复到 4。5.x。
您没有显示任何代码，但有证据表明这是您的应用程序代码的问题，而不是 .NET 4.6 或 ThreadAbortException 具体的问题。
这里是基本的故障排除步骤：你说有代码更改和环境更改；所以排除其中之一。
在安装了 .NET 4.5 的 VM 上测试应用程序。如果您没有收到错误，.NET 4.6 可能是原因。
在同一台服务器上测试旧版本的应用程序。如果未发现问题，则可能是代码更改。
在安装了 VS.NET 的机器上测试应用程序，附加到
w3wp.exe进程，然后调试它（工具 > 附加到进程）。抓住ThreadAbortException并追踪它。如果您还没有，您应该记录您的
w3wp.exe进程停止的事件。虽然这显然不会处理所有异常。 Google这个，但是this guy describes a solution that I also use如果您还没有，请在
Global中定义一个Application_Error处理程序来记录异常。 Microsoft demonstrates this. Create aSystem.Web.Configurationoption that you can toggle in yourweb.configfile to enable different levels of logging, including writing to a local file, and writing to the windows event logs, for example. You can also install a logging handler tool like Elmah.创建一个基本的简单 Web 应用程序并测试
Response.Redirect以验证它是否使w3wp.exe（工作进程）与 .NET 4.6 崩溃。我这样做了，但没有，所以我怀疑你的代码。或者可能是奇怪的 server/patch 级紧急问题。这些步骤应该可以帮助您查明它。
旁注：即使它不应该影响应用进程，我还是建议修复 Response.Redirect() 问题。我们最近在一个企业应用程序中这样做了，是的，这是一个范围很广的变化，但我们不再遇到 TAE 异常。解决方法很简单：只需调用 Response.Redirect(false);，然后确保在调用该函数后没有代码会 运行（例如调用 return）。 This post explains
@Jordan Rieger，此错误应在 .NET 4.6.1 中修复 能否请您确认问题是否已在新框架中得到解决？或者如果它仍然存在？谢谢。