我已经创建了一个ASP.NET MVC应用程序,它有一个附加到PreApplicationStartMethodAttribute的初始化器。初始化时,会实例化一个实现我定义的接口的集合。当我实例化这个集合时,w3wp.exe崩溃了,事件日志中有以下两个无法理解的条目:
Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bd0eb
Faulting module name: clr.dll, version: 4.0.30319.1, time stamp: 0x4ba21eeb
Exception code: 0xc00000fd
Fault offset: 0x0000000000001177
Faulting process id: 0x1348
Faulting application start time: 0x01cb0224882f4723
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: c6a0941e-6e17-11df-864d-000acd16dcdb和:
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: w3wp.exe
P2: 7.5.7600.16385
P3: 4a5bd0eb
P4: clr.dll
P5: 4.0.30319.1
P6: 4ba21eeb
P7: c00000fd
P8: 0000000000001177
P9:
P10:
Attached files:
These files may be available here:
Analysis symbol:
Rechecking for solution: 0
Report Id: c6a0941e-6e17-11df-864d-000acd16dcdb
Report Status: 0如果删除集合的实例化,应用程序将正常启动。如果我离开实例化,w3wp就会崩溃。如果我修改接口,w3wp仍然会崩溃。我已经尝试了所有我能想到的关于保持实例化但做其他事情都不同的主题的变体,但w3wp仍然崩溃。
我最大的问题是,我完全不知道为什么w3wp会崩溃。这不是一个StackOverflowException或任何类似的具体东西,我得到的只是上面引用的愚蠢的垃圾。
我曾尝试使用DebugDiag和IISState来调试w3wp进程,但DebugDiag仅可用于x64中的转储后分析(我运行的是Windows7 x64,因此w3wp进程是64位的),当我尝试运行它时,IISStat会显示以下内容:
D:\Programs\iisstate>IISState.exe -p 9204 -d
Symbol search path is: SRV*D:\Programs\iisstate\symbols*http://msdl.microsoft.com/download/symbols
IISState is limited to processes associated with IIS.
If you require a generic debugger, please use WinDBG or CDB.
They are available for download from http://www.microsoft.com/ddk/debugging.
This error may also occur if a debugger is already attached to the process
being checked.
Incorrect Process Attachment我已经重复检查了10次,确认我的w3wp进程的进程ID是正确的。我怀疑IISState也只能调试x86进程。在应用程序中的任何位置设置断点绝对不会做任何事情。没有命中断点,一旦请求从浏览器传到IIS,w3wp就会崩溃。在Visual Studio2010中使用F5启动应用程序,或者启动另一个应用程序来启动并运行w3wp进程,然后将VS2010调试器附加到它上,然后访问出错的应用程序,这些都没有帮助。
我还尝试添加一个KB-911816中描述的超文本传输协议模块,并将其添加到我的web.config文件中:
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="true" />
</runtime>
</configuration>不用说,这完全没有区别。所以我没有办法调试w3wp进程,也没有办法从中提取任何信息,也没有办法在我的事件日志中完成垃圾转储。如果任何人对如何调试这个问题有任何想法,请让我知道!
发布于 2011-05-09 18:51:15
我将回答我自己的问题只是为了结束,尽管我意识到这不是导致W3WP崩溃的各种问题的唯一解决方案。
我的集合是基于RouteTable.Routes进行初始化的,这可能会抛出一个异常(可能是因为在ASP.NET生命周期的早期阶段本身还没有初始化)。将与RouteTable.Routes的通信推迟到稍后阶段解决问题。
虽然这不是一个对每个人都有效的解决方案,但它对我有效,我发现这个问题太晦涩了,我会把它留给任何人来评论和回答,因为我在任何地方都没有找到关于这个问题的现有帖子,所以它在未来可能会有很好的参考价值。
发布于 2010-06-05 20:38:23
在windows的最新调试工具中使用ADplus.exe来捕获崩溃转储。那么转储分析应该会告诉你是什么导致了崩溃,
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en
版本6.12.2.633是必须的,因为只有它包含adplus.exe的工作副本(请注意,您不应该使用adplus.vbs)。
https://stackoverflow.com/questions/2956040
复制相似问题