2009-03-12 5 views
3

Мои пулы приложений продолжают беспорядочно разбиваться в IIS 6.0 MS Debug Diag указывает на kernel32.dll каждый раз.System.UnauthorizedAccessException в mscorwks.dll, вызывающем сбой в пуле приложений

Точка входа всегда mscorwks! CreateApplicationContext + bbef, и результатом всегда является System.UnauthorizedAccessException.

Трассировка стека:

Function          Arg 1  Arg 2  Arg 3 
kernel32!RaiseException+3c      e0434f4d  00000001  00000001  
mscorwks!GetMetaDataInternalInterface+84a9  18316b3c  00000000  00000000  
mscorwks!GetAddrOfContractShutoffFlag+ac01  18316b3c  00000000  023cfbd8  
mscorwks!GetAddrOfContractShutoffFlag+ac73  00000000  000e8c88  8038b2d0  
mscorwks!GetAddrOfContractShutoffFlag+aca4  18316b3c  00000000  023cfbe4  
mscorwks!GetAddrOfContractShutoffFlag+acb2  18316b3c  acc05c33  7a399bf0  
mscorwks!CoUninitializeCor+67be    00000000  023cfc1c  023cfc8c  
mscorwks!CoUninitializeCor+87a1    001056e8  79fd87f6  023cfeb0  
mscorwks!CorExitProcess+4ad3     023cfeb0  023cfd20  79f40574  
mscorwks!CorExitProcess+4abf     001056e8  79f405a6  023cfd04  
mscorwks!CorExitProcess+4b3e     000e8c88  00000000  023cfda7  
mscorwks!StrongNameErrorInfo+1ddab    00000000  00000000  023cfeb0  
mscorwks!StrongNameErrorInfo+1e07c    023cfeb0  00000000  00000000  
mscorwks!CoUninitializeEE+4e0b     023cfeb0  023cfe5c  79f7762b  
mscorwks!CoUninitializeEE+4da7     023cfeb0  acc05973  00000000  
mscorwks!CoUninitializeEE+4ccd     023cfeb0  00000000  001056e8  
mscorwks!GetPrivateContextsPerfCounters+f1cd 79fc24f9  00000008  023cff14  
mscorwks!GetPrivateContextsPerfCounters+f1de 79fc24f9  acc058c3  00000000  
mscorwks!CorExeMain+1374      00000000  00000003  00000002  
mscorwks!CreateApplicationContext+bc35   000e9458  00000000  00000000  
kernel32!GetModuleHandleA+df     79f9205f  000e9458  00000000 

Кто-нибудь знает, что это значит и как это исправить?

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

+0

Является ли ваше приложение делает что-нибудь интересное в то время? Может быть, загрузка другой сборки? – David

+1

Возможно. Кажется, мы можем воссоздать катастрофу, постукивая о хрустальных отчетах, но не последовательно. –

ответ

9

Ссылка на mscorwks.dll была только симптомом проблемы. mscorwks.dll - это DLL, которая содержит общую среду исполнения.

Чтобы диагностировать причину проблемы, я последовал за следующие действия:

  1. Использование DebugDiag для захвата аварийного дампа при IIS переработан приложением бассейна.
  2. Открыть аварийный сброс в windbg.
  3. Тип «.loadby sos mscorwks» (без кавычек) в командной строке windbg для загрузки средств отладки CLR
  4. Используйте команду! PrintException, чтобы распечатать последнее исключение, записанное в дампе сбоя. Это, скорее всего, один, который вызвал бассейн рециркуляцию приложения IIS
  5. Используйте clrstack команды! Для просмотра стека текущего потока, который выбросил исключение
  6. Больше ссылку Команды для WinDbg можно найти here и here. Наконец, this MSDN blog имеет отличные уроки по использованию windbg.

Удачи вам в приключении!

+0

Этот ответ был действительно полезен для моей собственной отладки. Благодаря! –

0

Ryan, Я знаю, что поведение необработанного исключения изменилось. из NET Framework 1.0 или 1.1 необработанные исключения игнорировались. 2.x и более поздние, необработанные исключения разрушат рабочий процесс (пул приложений). Добавьте следующую строку в ваш web.config, чтобы он игнорировал (но вы должны выяснить, почему его разваливается!)

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

Это может сделать трюк. , ,

0

Ваши символы разбиты - исправить их, и вы, вероятно, получите более содержательный стек вызовов