如何调试 w3wp clr.dll 错误答案

【问题标题】：How to debug w3wp clr.dll error如何调试 w3wp clr.dll 错误
【发布时间】：2013-08-22 12:59:26
【问题描述】：

我的客户端在两台生产服务器上安装了一个 ASP.NET 应用程序（与 NLB 平衡，但这无关紧要）。两台服务器每 3-4 小时崩溃一次，并记录以下事件查看器错误：

错误应用程序名称：w3wp.exe，版本：7.5.7601.17514，时间戳：0x4ce7afa2
错误模块名称：clr.dll，版本：4.0.30319.18034，时间戳：0x50b5a783
异常代码：0xc00000fd 故障偏移量：0x000000000001a840
错误进程 ID：0xd50
错误的应用程序启动时间：0x01ce97fe076d27b4
错误的应用程序路径：c:\windows\system32\inetsrv\w3wp.exe
错误模块路径：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll 报告 ID：e0c90a5f-0455-11e3-8f0e-005056891553

我不知道如何调试或从哪里开始。当崩溃即将发生时，服务器处理器的使用率会跃升至 100% 并保持在那里。出错的进程是 w3wp.exe。我什至不确定我的代码是否产生了错误。它是 IIS 7.5。任何指针将不胜感激。

【问题讨论】：

标签： asp.net iis crash-reports w3wp

【解决方案1】：

看起来你有一个 StackOverflow 异常，这是由无限递归（一个函数重复调用自身等）引起的。这不能被常规的 try/catch 块捕获。您可以使用 DebugDiag 和 WinDbg 跟踪问题。

DebugDiag 可以配置为在发生 StackOverflowException 时生成故障转储。在https://www.microsoft.com/en-us/download/details.aspx?id=58210下载。

打开 DebugDiag 并单击添加规则。
“崩溃”应该已经被选中。点击下一步。
选择“A specific IIS web application pool”并点击下一步。
选择应用程序池并单击下一步。
您应该在高级配置窗口中。点击高级设置下的例外。
单击添加异常并选择堆栈溢出，操作类型为完整用户转储
单击“确定”并保存并关闭。

下次发生 StackOverflowException 时，您将获得崩溃转储。现在需要解释转储文件。

Windows 调试工具是 Windows SDK 的一部分，可以在 http://msdn.microsoft.com/en-US/windows/hardware/gg463009/ 下载。

要使用 WinDbg，您需要获取符号文件。 Download the symbol files 并将它们放在本地文件夹中。
打开 WinDbg。在文件菜单上，单击符号文件路径。
在符号路径框中，文档说要键入以下命令：SRV*your local folder for symbols*http://msdl.microsoft.com/download/symbols，但是我只是将符号放入本地文件夹中，它工作正常。
退出并再次打开WinDbg，然后打开故障转储并找到由DebugDiag创建的转储文件。
在命令行中输入.loadby sos clr
现在输入!CLRStack

在结果中，应该清楚问题是什么（您可能会看到一堆行显示重复调用的函数）。

【讨论】：

终于设法让它工作了。不幸的是，调用堆栈没有帮助：OS Thread Id: 0xdd0 (42) Child SP IP Call Site 0000000011b1ef48 000007fef7a5c91b [GCFrame: 0000000011b1ef48] 0000000011b1ef88 000007fef7a5c91b [ContextTransitionFrame: 0000000011b1ef88] 0000000011b1efc8 000007fef7a5c91b [GCFrame: 0000000011b1efc8] 0000000011b1f1b0 000007fef7a5c91b [ComMethodFrame: 0000000011b1f1b0]
这是一篇很棒的文章。帮助我深入了解烦人的 IIS SO。
对我来说，尝试在 DebugDiag 中添加新规则会导致“无法启动 DbgSVC。GetLastError 返回 0x00000422”。修复在这里：stackoverflow.com/q/26127366/12484
@JonSchneider Thx 了解后续详情。
这就像一个魅力，为我节省了大量时间。谢谢你。注意：链接已过时，但快速 google 会找到它们。

【解决方案2】：

我能够检查事件查看器 -> Windows 日志 -> 系统并找到

应用程序池“DankAppPool”由于以下原因被自动禁用为该应用程序池提供服务的进程中出现一系列故障。

下面：

为应用程序池“DankAppPool”提供服务的进程遭遇致命攻击与 Windows Process Activation Service 的通信错误。这进程 ID 为“5704”。数据字段包含错误号。

还有：

QueueMonitor 服务意外终止。它已经做到了 32 时间。 60000将采取以下纠正措施毫秒：重启服务。

至少 QueueMonitor 服务是一个起点。

【讨论】：

【解决方案3】：

另一个原因可能是“无限递归函数”。当发生无限循环时，Windows 会尽量避免死锁并禁用相关的应用程序池。

我今天遇到了同样的问题。我有一个列出 parentproject-sub 项目的递归函数。一个项目自己设置为父项目，当recusive function try list all parent-sub project时，出现死循环。

【讨论】：

【解决方案4】：

对上述答案的一些补充。开发在用户登录时出错的 Explorer 扩展。所以对于用户来说，它看起来是“闪烁的屏幕”（当资源管理器尝试启动并崩溃，然后重新启动等）。在另一个安装了DebugDiag 和WinDbg 的用户帐户下登录。我在今天（2014 年 1 月 13 日）使用带有 .Net 4.0 的 Windows 8.1 和所有最新更新尝试在本地下载几个符号，但是由于签名不正确，WinDbg 无法加载 clr.pdb。

在线使用符号解决了 - 使用“SRV*http://msdl.microsoft.com/download/symbols”作为符号路径。

【讨论】：