W3WP crashes when initializing a collection

I've created an ASP.NET MVC application that has an initializer attached to the PreApplicationStartMethodAttribute. When initializing, a collection is instantiated that implements an interface I've defined. When I instantiate this collection, w3wp.exe crashes with the following two incomprehensible entries in the event log:

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

And:

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

If I remove the instantiation of the collection, the a开发者_运维知识库pplication starts normally. If I leave the instantiation, w3wp crashes. If I modify the interface, w3wp still crashes. I've tried every variation I could come up with on the theme of keeping the instantiation but doing everything else differently, but w3wp still crashes.

My biggest issue here is that I have absolutely no idea why w3wp is crashing. It's not a StackOverflowException or anything concrete like that, all I get is the unintelligent junk cited above.

I've tried to use DebugDiag and IISState to debug the w3wp process, but DebugDiag is only available for post-dump analysis in x64 (I'm running on Windows 7 x64, so the w3wp process is thus 64 bit) and IISStat says the following when I try to run it:

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

I've double-checked 10 times that the process ID of my w3wp process is correct. I'm suspecting that IISState too only can debug x86 processes. Setting a breakpoint anywhere in the application does absolutely nothing. The break point isn't hit and w3wp crashes as soon as the request comes through to IIS from the browser. Starting the application with F5 in Visual Studio 2010 or starting another application to get the w3wp process up and running and then attaching the VS2010 debugger to it and then visiting the faulting application doesn't help.

I've also tried to add an HTTP module as described in KB-911816 as well as add this to my web.config file:

<configuration>
  <runtime>
    <legacyUnhandledExceptionPolicy enabled="true" />
  </runtime>
</configuration>

Needless to say, it makes absolutely no difference. So I'm left with no way to debug the w3wp process, no way to extract any information from it and complete garbage dumped in my event log. If anybody has any idea on how to debug this problem, please let me know!

I'll answer my own question just to get closure, although I realize it isn't the one and only solution to the variety of problems that might be causing W3WP to crash.

My collection was initialized based on RouteTable.Routes which might have thrown an exception (perhaps by not being initialized itself yet in such an early stage of the ASP.NET lifecycle). Postponing the communication with RouteTable.Routes until a later stage solved the problem.

While this isn't a solution that will work for everyone, it worked for me, and I find the problem to be so obscure that I'll leave it for anyone to comment on and answer, because I found no existing posts on this problem anywhere, so it might be of good reference in the future.

Utilize ADplus.exe in latest debugging tools for windows to capture crash dumps. Then dump analysis should show you what causes the crash,

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en

Version 6.12.2.633 is a must as only it contains a working copy of adplus.exe (note that you should not use adplus.vbs).