2010-06-02 1 views
1

Я создал приложение ASP.NET MVC, у которого есть инициализатор, прикрепленный к PreApplicationStartMethodAttribute. При инициализации создается экземпляр коллекции, которая реализует интерфейс, который я определил. Когда я создаю экземпляр этой коллекции, w3wp.exe падает со следующими двумя непонятных записей в журнале событий:Авария W3WP при инициализации коллекции

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 (я бегу на Windows 7 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 является правильным. Я подозреваю, что IISState тоже может отлаживать процессы x86. Установка точки останова в любом месте приложения абсолютно ничего не делает. Точка прерывания не попадает, и w3wp аварийно завершает работу, как только запрос поступает в IIS из браузера. Запуск приложения с помощью F5 в Visual Studio 2010 или запуск другого приложения для запуска процесса w3wp и последующего присоединения к нему отладчика VS2010, а затем посещение приложения с ошибкой не помогает.

Я также пробовал добавить модуль HTTP, как описано в KB-911816, а также добавить это к моему web.config файла:

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

Излишне говорить, что это делает абсолютно никакой разницы. Таким образом, мне не удавалось отлаживать процесс w3wp, не извлекать из него никакой информации и заполнять мусор, сбрасываемый в моем журнале событий. Если кто-нибудь знает, как отладить эту проблему, сообщите мне!

ответ

1

Я отвечу на свой вопрос, чтобы получить закрытие, хотя я понимаю, что это не единственное решение множества проблем, которые могут привести к сбою W3WP.

Моя коллекция была инициализирована на основе RouteTable.Routes, которая, возможно, создала исключение (возможно, не будучи само инициализированным еще на ранней стадии жизненного цикла ASP.NET). Отложив сообщение с RouteTable.Routes до более позднего этапа, решила проблему.

Хотя это не решение, которое будет работать для всех, это сработало для меня, и я нахожу проблему настолько неясной, что я оставлю ее для комментирования и ответа, потому что я не нашел никакого сообщения по этой проблеме в любом месте, поэтому в будущем это может быть хорошей ссылкой.

0

Использовать 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).