На основном производственном сервере рабочий процесс IIS иногда дает сбой. Из средства просмотра событий я получаю следующую информацию.
Имя сбойного приложения: w3wp.exe, версия: 7.5.7601.17514, отметка времени: 0x4ce7a5f8 Имя сбойного модуля: KERNELBASE.dll, версия: 6.1.7601.17651, отметка времени: 0x4e211319 Код исключения: 0xe053534f Смещение ошибки: 0x0000b9bc Идентификатор сбойного процесса: 0x% 9 Время запуска сбойного приложения: 0x% 10 Путь сбойного приложения:% 11 Путь сбойного модуля:% 12 Идентификатор отчета:% 13
Это происходит случайным образом на сервере prod, и мне не удалось воспроизвести этот сбой где-либо еще. Это происходило в IIS 6, а недавно мы перешли на Windows Server 2008 и IIS 7.5, и там тоже происходит сбой.
Как найти первопричину этого?
Пошаговое руководство из блога Тесс Феррандес включено сюда:
https://blogs.msdn.com/b/tess/archive/2009/03/20/debugging-a-net-crash-with-rules-in-debug-diag.aspx
По сути, вы настроите DebugDiag 1.2 x64 для запуска по этому коду исключения и создадите полный пользовательский дамп. После создания дампа вы можете использовать DebugDiag для анализа дампа. Хотя с этим конкретным исключением вам, вероятно, потребуется использовать WinDbg + SOS.
Некоторые из наиболее важных сведений:
«Для переполнения стека, как большинство из вас, вероятно, знает, наиболее частая причина заключается в том, что мы находимся в каком-то рекурсивном цикле, поэтому мы действительно хотели бы знать, что находится в этом стеке ... Причина, по которой он появляется с просто адреса, а не имена методов, потому что debug diag не понимает .net, поэтому нам придется передать дамп в windbg, чтобы проанализировать его и проверить стек .net.
"В windbg мы можем загрузить sos (.loadby sos mscorwks) и запустите! clrstack в активном стеке, чтобы получить стек вызовов ».
(Если вы используете .NET 4, команда для загрузки sos: .loadby sos clr)
В конечном итоге вы ищете оскорбительный код в вашем приложении, который вызывает рекурсию. Имена методов, которые появляются в WinDbg при загрузке SOS, вероятно, укажут вам правильное направление.
Получить ProcDump и настройте его для создания дампов при сбое процессов w3wp.exe. Когда у вас есть дамп, проверьте его с помощью Visual Studio или Windbg.
У меня такая же проблема. В моем коде у меня была следующая строка кода vb.net
Dim mPath as string = Environment.GetFolderPath (Environment.SpecialFolder.Desktop)
Весь мой ASP.NET разбился, потому что он не мог получить доступ к этой папке во время выполнения. Обработка ошибок не работает. Clr просто вылетает.
Замена этой строки существующим каталогом решила мою проблему.