在主生产服务器上，IIS辅助进程有时会崩溃。 从事件查看器中，我得到以下信息。
错误应用程序名称：w3wp.exe版本：7.5.7601.17514，时间戳：0x4ce7a5f8错误模块名称：KERNELBASE.dll，版本：6.1.7601.17651，时间戳：0x4e211319exception代码：0xe053534f错误偏移量：0x0000b9bc错误进程ID：0x％ 9错误应用程序开始时间：0x％10错误应用程序path：％11错误模块path：％12报告ID：％13
这在prod服务器上随机发生，我无法在其他地方重新创build这个崩溃。 这发生在IIS 6上，最近我们转移到Windows Server 2008和IIS 7.5，崩溃也发生在那里。
如何去find这个根本原因？
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触发该exception代码，并创build一个完整的用户转储。 创build转储后，可以使用DebugDiag为您分析转储。 虽然有这个特殊的例外，你可能需要使用WinDbg + SOS。
一些更相关的信息：
“对于大多数人可能知道的堆栈溢出来说，最常见的原因是我们处于某种types的recursion循环，所以我们真正想知道的是这个栈上的内容……它出现的原因只是地址而不是方法名称，是因为debugging诊断不理解.net，所以我们必须把转储到windbg来分析它，并签出.net堆栈。
“在windbg中，我们可以加载sos（ .loadby sos mscorwks ）并在活动堆栈上运行clrstack来获得调用堆栈。”
（如果你正在运行.NET 4，加载sos的命令是： .loadby sos clr ）
最终，你正在寻找的是你的应用程序中导致recursion的有问题的代码。 在加载SOS时WinDbg中出现的方法名称可能会使您指向正确的方向。
获取ProcDump并将其configuration为在w3wp.exe进程崩溃时生成转储。 一旦你有一个转储检查与Visual Studio或Windbg 。
我有同样的问题。 在我的代码中，我有以下的vb.net代码行
Dim mPath as string = Environment.GetFolderPath（Environment.SpecialFolder.Desktop）
我的整个ASP.NET崩溃，因为它不能在运行时访问此文件夹。 error handling不起作用。 Clr只是崩溃。
用现有的目录replace这一行解决了我的问题。