IIS 6 + веб-служба ASP.NET - DW20 и исключение stackoverflow

Исключения Stackoverflow - это особый случай, потому что затронутое приложение больше не может ничего делать (например, регистрировать трассировку стека) - в этом случае процесс пула приложений (w3p.exe) завершается ОС. Вот почему доктор Ватсон / DW20 участвует. Вы можете попробовать отладить дамп, сохраненный DW20, с помощью WinDbg с расширением SOS (ожидайте крутого обучения, если вы не знакомы с этим набором инструментов - я надеюсь, что с VS2010 это станет проще, как и было обещано).

Высокая загрузка ЦП (и часто высокая загрузка памяти) вызвана DW20, что особенно раздражает, если цикл «сбой и перезапуск» выполняется быстрее, чем DW20, и поэтому несколько процессов DW20 накапливаются.

По умолчанию пул приложений IIS должен перезапускать вышедшие из строя приложения не более 3 раз за короткий промежуток времени, в противном случае они будут остановлены для защиты сервера от DoS.

Что касается основной причины, stackoverflow: может быть что угодно ... но как насчет этого дикого предположения: доступ к базе данных не работает из-за неправильной конфигурации, генерируется исключение, и ваше приложение регистрирует исключения в базе данных, не перехватывая исключения при обработке исключений; )

Решение этой (вероятно, уникальной) проблемы:

• удалить и воссоздать все пулы приложений (вероятно, это было излишним и ненужным)
• удалить файлы приложений на диске
• повторное развертывание и новая сборка и версия приложения
• убедитесь, что все ссылки включены в каталог bin

У меня была эта проблема, и я обнаружил, что у меня есть инструкция LINQ, которая пытается удалить некоторые строки. Каждый день он выходил из строя, поэтому количество строк постоянно увеличивалось. Исключения фактически обрабатывались и записывались в созданную мной таблицу, поэтому я нашел ее там. Нашел проблемную таблицу, и это было 700k + сверхтяжелых строк. Мой LINQ выглядел так:

var db = new DatabaseDataContext();
        var updateQueueLogs = db.UpdateQueueLogs;

        List<UpdateQueueLog> listToDelete;

        using (new TransactionScope(
            TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = IsolationLevel.ReadUncommitted }))
        {
            listToDelete = (from updateQueueLog
                              in db.UpdateQueueLogs
                            where updateQueueLog.CreatedAt < DateTime.Now.AddDays(-7)
                            select updateQueueLog).ToList();
        }

        updateQueueLogs.DeleteAllOnSubmit(listToDelete);

        db.SubmitChanges();

Итак, он извлекал полные объекты и получал исключения OutofMemory. Я изменил этот код на сохраненный процесс:

delete from UpdateQueueLogs
 where CreatedAt < DATEADD(day,-7,getdate())

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

Похоже, вы можете получить необработанное исключение, которое, в свою очередь, убивает рабочий процесс asp.net. Посмотрите, поможет ли это:

http://support.microsoft.com/?id=911816

Проверьте в средстве просмотра событий наличие ошибок (обычно в журнале приложений). Он находится в разделе «Администрирование».

Кроме того, хорошая точка @ markus в том, что IIS имеет довольно жесткую настройку по умолчанию «не более X потоков сбоев за Y раз», так что если вы попадете на страницу всего пару раз с такой ошибкой, весь пул приложений будет отключен . Снова проверьте Просмотр событий.