如何debugging：由于堆栈溢出，w3wp.exe进程被终止（在一台机器上工作，但不在另一台机器上）

问题
我有一个ASP.NET 4.0应用程序崩溃，在一台计算机上的堆栈溢出，但没有另一台。 它在我的开发环境中运行良好。 当我将站点移动到生产服务器时，它将引发堆栈溢出exception（在事件日志中看到），并且w3wp.exe工作进程死亡，并被replace为另一个。

到目前为止，我已经尝试过
作为参考，我使用debugging诊断工具来试图确定哪些代码导致溢出，但我不知道如何解释它的输出。 输出包括在下面。

ASP.NET网站如何在一台机器上导致堆栈溢出，而在另一台机器上则不会溢出？
经验丰富的线索表示赞赏。 我会将结果解决scheme发布到导致我的答案之下。

debugging输出

应用程序：w3wp.exe Framework版本：v4.0.30319说明：由于堆栈溢出，进程已终止。

In w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp the assembly instruction at nlssorting!SortGetSortKey+25 in C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll from Microsoft Corporation has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x01d12fc0 on thread 16 Please follow up with the vendor Microsoft Corporation for C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll Information:DebugDiag determined that this dump file (w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the IISAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True. Entry point clr!ThreadpoolMgr::intermediateThreadProc Create time 2/18/2011 9:07:10 PM Function Arg 1 Arg 2 Arg 3 Source nlssorting!SortGetSortKey+25 01115a98 00000001 0651a88c clr!SortVersioning::SortDllGetSortKey+3b 01115a98 08000001 0651a88c clr!COMNlsInfo::InternalGetGlobalizedHashCode+f0 01115a98 05e90268 0651a88c mscorlib_ni+2becff 08000001 0000000f 0651a884 mscorlib_ni+255c10 00000001 09ed57bc 01d14348 mscorlib_ni+255bc4 79b29e90 01d14350 79b39ab0 mscorlib_ni+2a9eb8 01d14364 79b39a53 000dbb78 mscorlib_ni+2b9ab0 000dbb78 09ed57bc 01ff39f4 mscorlib_ni+2b9a53 01d14398 01d1439c 00000011 mscorlib_ni+2b9948 0651a884 01d143ec 7a97bf5d System_ni+15bd65 6785b114 00000000 09ed5748 System_ni+15bf5d 1c5ab292 1b3c01dc 05ebc494 System_Web_ni+6fb165 ***These lines below are repeated many times in the log, so I just posted one block of them 1c5a928c 00000000 0627e880 000192ba 1c5a9dce 00000000 0627e7c4 00000000 1c5a93ce 1b3c01dc 05ebc494 1b3c01dc 1c5a92e2 .....(repeated sequence from above) System_Web_ni+16779c 1b338528 00000003 0629b7a0 System_Web_ni+1677fb 00000000 00000017 0629ac3c System_Web_ni+167843 00000000 00000003 0629ab78 System_Web_ni+167843 00000000 00000005 0629963c System_Web_ni+167843 00000000 00000001 0627e290 System_Web_ni+167843 00000000 0627e290 1a813508 System_Web_ni+167843 01d4f21c 79141c49 79141c5c System_Web_ni+1651c0 00000001 0627e290 00000000 System_Web_ni+16478d 00000001 01ea7730 01ea76dc System_Web_ni+1646af 0627e290 01d4f4c0 672c43f2 System_Web_ni+164646 00000000 06273aa8 0627e290 System_Web_ni+1643f2 672d1b65 06273aa8 00000000 1c5a41b5 00000000 01d4f520 06273aa8 System_Web_ni+18610c 01d4f55c 0df2a42c 06273f14 System_Web_ni+19c0fe 01d4fa08 0df2a42c 06273e5c System_Web_ni+152ccd 06273aa8 05e9f214 06273aa8 System_Web_ni+19a8e2 05e973b4 062736cc 01d4f65c System_Web_ni+19a62d 06a21c6c 79145d80 01d4f7fc System_Web_ni+199c2d 00000002 672695e8 00000000 System_Web_ni+7b65cc 01d4fa28 00000002 01c52c0c clr!COMToCLRDispatchHelper+28 679165b0 672695e8 09ee2038 clr!BaseWrapper<Stub *,FunctionBase<Stub *,&DoNothing<Stub *>,&StubRelease<Stub>,2>,0,&CompareDefault<Stub *>,2>::~BaseWrapper<Stub *,FunctionBase<Stub *,&DoNothing<Stub *>,&StubRelease<Stub>,2>,0,&CompareDefault<Stub *>,2>+fa 672695e8 09ee2038 00000001 clr!COMToCLRWorkerBody+b4 000dbb78 01d4f9f8 1a78ffe0 clr!COMToCLRWorkerDebuggerWrapper+34 000dbb78 01d4f9f8 1a78ffe0 clr!COMToCLRWorker+614 000dbb78 01d4f9f8 06a21c6c 1dda1aa 00000001 01b6c7a8 00000000 webengine4!HttpCompletion::ProcessRequestInManagedCode+1cd 01b6c7a8 69f1aa72 01d4fd6c webengine4!HttpCompletion::ProcessCompletion+4a 01b6c7a8 00000000 00000000 webengine4!CorThreadPoolWorkitemCallback+1c 01b6c7a8 0636a718 0000ffff clr!UnManagedPerAppDomainTPCount::DispatchWorkItem+195 01d4fe1f 01d4fe1e 0636a488 clr!ThreadpoolMgr::NewWorkerThreadStart+20b 00000000 0636a430 00000000 clr!ThreadpoolMgr::WorkerThreadStart+3d1 00000000 00000000 00000000 clr!ThreadpoolMgr::intermediateThreadProc+4b 000c3470 00000000 00000000 kernel32!BaseThreadStart+34 792b0b2b 000c3470 00000000 NLSSORTING!SORTGETSORTKEY+25In w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp the assembly instruction at nlssorting!SortGetSortKey+25 in C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll from Microsoft Corporation has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x01d12fc0 on thread 16 

Answer 1

这个问题有点老，但我刚刚find了一个很好的方式来获取应用程序的堆栈跟踪溢出之前，我想与其他谷歌分享它：

1）当你的ASP.NET应用程序崩溃时，一组debbuging文件被转储到这个主文件夹中的一个“崩溃文件夹”中：

C：\ ProgramData \微软\的Windows \ WER \ ReportQueue

2）可以使用WinDbg分析这些文件，您可以从以下链接之一下载这些文件：

• Windows WinDbg x86安装程序
• Windows WinDbg x64安装程序

3）安装在你的应用程序崩溃的同一台机器上后，单击文件>打开崩溃转储，然后select“崩溃文件夹”（我有180 MB）最大的.tmp文件。 就像是：

AppCrash_w3wp.exe_3d6ded0d29abf2144c567e08f6b23316ff3a7_cab_849897b9 \ WER688D.tmp

4）然后，在刚刚打开的命令窗口中运行以下命令：

 .loadby sos clr !clrstack 

5）最后，生成的输出将在溢出之前包含您的应用程序堆栈跟踪，并且可以轻松追踪导致溢出的原因。 在我的情况下，这是一个错误的日志logging方法：

 000000dea63aed30 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception) 000000dea63aedd0 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception) 000000dea63aee70 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception) 000000dea63aef10 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception) 000000dea63aefb0 000007fd88de9d00 Library.Logging.RepositoryLogger.Error(System.Object, System.Exception) 000000dea63af040 000007fd88de9ba0 Library.WebServices.ErrorLogger.ProvideFault(System.Exception, System.ServiceModel.Channels.MessageVersion, System.ServiceModel.Channels.Message ByRef) 

感谢Paul White和他的博客文章： debugging错误应用程序w3wp.exe崩溃

Answer 2

w3wp.exe的默认堆栈限制是一个笑话。 我总是用editbin /stack:9000000 w3wp.exe提高它editbin /stack:9000000 w3wp.exe ，应该足够了。 首先摆脱你的堆栈溢出，然后debugging任何你想要的。

Answer 3

获取崩溃转储，运行它对微软的debugging诊断工具，并告诉我们结果。

另请参阅http://support.microsoft.com/kb/919789/en-us ，其中详细解释了所有必要的步骤。

Answer 4

在分析任何内存转储之前，我会尝试两件事情。

1. 在Web服务器上安装远程debugging工具，并尝试以这种方式进行debugging。 您可以在Visual Studio安装DVD上find此工具。
2. 安装Elmah。 可以将Elmah添加到正在运行的ASP.NET应用程序中进行日志logging和debugging。 我可能会首先使用这个选项，这是最不痛苦的方法。 http://code.google.com/p/elmah/

Answer 5

对于您的应用程序来说，在生产和开发中可能会有不同的performance，可能是因为您在代码中有“#if DEBUG”之类的预处理指令，并且在部署到生产环境时，发布版本将具有与您的debugging版本不同的代码段。

另一个select是你的应用程序在生产中抛出一个无关的exception。 error handling代码以某种方式在一个无限的函数调用循环中结束。 你可能想要寻找一个无限循环，有一个函数调用自己或另一个调用这个函数的函数。 由于无限的for或while循环，这最终会在一个无限的函数callig循环中结束。 对于“无限”这个词，我很抱歉。

在我意外地创build了一个房产之前，我也发生过这种情况，而且我正在将房产归还给我。 喜欢：-

公共stringSomeProperty {得到{返回SomeProperty;}

另外，如果可能的话，你可以在global.asax的Application_error函数中做特殊的事情。 使用server.getlasterror（）来获取exception并logging/显示堆栈跟踪。 你可能也想要做同样的事情，以避免任何内隐错误或内隐错误等等。

你可能已经在做上面提到的事情了，但是我想提醒他们以防万一。

另外，从你的踪迹看来，错误发生在GetSortKey中。 在你的代码中是一个函数吗？ 如果是这样，那么你的无限自我呼叫可能会在那里开始。

希望这可以帮助。