在主生产服务器上，IIS 工作进程有时会崩溃。从事件查看器中我得到以下信息。
错误应用程序名称：w3wp.exe，版本：7.5.7601.17514，时间戳：0x4ce7a5f8 错误模块名称：KERNELBASE.dll，版本：6.1.7601.17651，时间戳：0x4e211319 异常代码：0xe053534f 错误偏移量：0x0000b9bc 错误进程 ID：0x%9 错误应用程序启动时间：0x%10 错误应用程序路径：%11 错误模块路径：%12 报告 ID：%13
这在生产服务器上随机发生，我无法在其他任何地方重现此崩溃。这发生在 IIS 6 上，我们最近迁移到 Windows Server 2008 和 IIS 7.5，崩溃也在那里发生。
如何找到这一问题的根本原因？
答案1
以下是 Tess Ferrandez 博客中提供的分步指南：
https://blogs.msdn.com/b/tess/archive/2009/03/20/debugging-a-net-crash-with-rules-in-debug-diag.aspx
本质上，您将设置 DebugDiag 1.2 x64 来触发该异常代码，并创建完整的用户转储。创建转储后，您可以使用 DebugDiag 为您分析转储。尽管对于该特定异常，您可能需要使用 WinDbg+SOS。
一些更相关的信息：
“对于堆栈溢出，大多数人可能都知道，最常见的原因是我们处于某种类型的递归循环中，因此我们真正想知道的是这个堆栈上有什么……它只显示地址而不是方法名称的原因是因为调试诊断不理解.net，所以我们必须将转储带到 windbg 进行分析并检查.net 堆栈。
“然后我们可以在 windbg 中加载 sos（.loadby sos mscorwks) 并在活动堆栈上运行 !clrstack 以获取调用堆栈。”
（如果您正在运行 .NET 4，则加载 sos 的命令是： .loadby sos clr）
最终，您要查找的是应用程序中导致递归的有问题的代码。加载 SOS 时 WinDbg 中出现的方法名称可能会为您指明正确的方向。
答案2
答案3
我也遇到了同样的问题。在我的代码中，有以下几行 vb.net 代码
Dim mPath 作为字符串 = Environment.GetFolderPath(Environment.SpecialFolder.Desktop)
我的整个 ASP.NET 崩溃了，因为它在运行时无法访问此文件夹。错误处理不起作用。Clr 完全崩溃了。
用现有目录替换此行解决了我的问题。