Приложение ASP.NET переходит к 500.21... до тех пор, пока IIS Reset + Clear Tempoary ASP.NET Cache

Мы наблюдаем странный образец в нашей Лаборатории QA. У нас есть два приложения ASP.NET, каждый из которых развернут в одном окне Windows 2008 SP2+. У нас есть наш пул приложений, работающий в учетной записи домена, и настроен так, чтобы никогда не перестраиваться. Один и тот же 1 пул приложений используется обоими приложениями.

После нескольких часов работы, новые пользователи, просматривающие страницу в нашем приложении, получают страницу ошибок IIS7 с ошибкой 500.21.

Если мы ничего не делаем:

1) IISRESET 2) Измените папку на c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Временные файлы ASP.NET и "rd" 2 приложения.

И затем перейдите в наши веб-приложения, все в порядке.

Затем, спустя несколько часов, возвращаются ошибки 500.21.

То, что поражает меня как нечетное, - это кажущаяся связь между очисткой папок "Временные файлы ASP.NET" и проблемой. У меня есть практика очистки папок "Временные файлы ASP.NET" при установке новой версии наших приложений, но не иначе.

Знает ли это отношение кого-либо? Существует ли какая-то новая функция IIS7?

Текст ошибки:

Ошибка сервера в приложении "ВЕБ-САЙТ ПО УМОЛЧАНИЮ/ПАЙС"
Internet Information Services 7.0
Краткое описание ошибки
Ошибка HTTP 500.21 - Внутренняя ошибка сервера
Обработчик "PageHandlerFactory-Integrated" имеет плохой модуль "ManagedPipelineHandler" в своем списке модулей
Подробная информация об ошибках
Модуль IIS Web Core
Уведомление ExecuteRequestHandler
Обработчик PageHandlerFactory-Integrated
Код ошибки 0x8007000d
Запрошенный URL http://localhost:80/PAIS/Admin.aspx

Физический путь C:\0_Georgia\GA_IS_100142\PortfolioArchiveImageServer\Admin.aspx
Метод входа анонимный
Анонимный пользователь входа в систему | Скорее всего, причины:
• ASP.NET не установлен или не установлен. • Произошла типографская ошибка конфигурации.
• Неблагоприятная предварительная оценка существует.
Что вы можете попробовать:
• Если ManagedPipelineHandler отсутствует, убедитесь, что:
o ManagedEngine находится.
o ManagedPipelineHandler находится с правильными предварительными условиями.
• Установка ASP.NET.
• Убедитесь, что все system.webServer/[email protected] находятся в файле system.webServer/[email protected]
• Просмотрите предварительные условия в разделах и разделах.
Ссылки и дополнительная информация Ядро IIS не распознает модуль.
Просмотреть дополнительную информацию "

Спасибо заранее,

Говард Хоффман

Ответ 1

Мы нашли актуальную проблему, с поддержкой поддержки MS ASP.NET. Это довольно тонко. Я думаю, что MS заявила, что исправит проблему в следующем выпуске App Fabric (который теперь RTM). Пальцы пересекли.

В этом случае проблема последовательно возникает:

1) Веб-приложение ASP.NET еще не запущено. Он включает в себя привязки WCF Net.Pipe и/или Net.Tcp. Я думаю, что то же самое произойдет и для NetMsmq, но не пробовал.

2) Запрос входящей NetPipe или NetTcp WCF Windows Activation Service является начальным запросом, который запускает домен приложения.

3) Приложение использует "интегрированный" пул приложений IIS (IIS7 или IIS 7.5)

4) Приложение использует HttpServerUtility.Execute во время этого 1-го запроса.

Оказалось, что наше приложение запускало событие ASP.NET Health Monitoring во время самой первой операции WCF - самой операции, которая вызвала службу активации Windows (WAS), чтобы запустить наше приложение. Наша конфигурация мониторинга работоспособности включает в себя TemplatedMailWebEventProvider.

В нашем приложении используется "интегрированный" пул приложений IIS.

TemplatedMailWebEventProvider реализуется для создания тела сообщения электронной почты как HTML. Он использует перегрузку System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean).

Для этого случая использования перегрузка делает неправильную вещь - он инициализирует HTTP-конвейер "Классический" IIS App Pool. Поскольку этот неправильный конвейер для "интегрированного" пула приложений IIS конвейер поврежден следующим HTTP-запросом, который на самом деле является первым входящим HTTP-запросом.

Итак, вы получаете ошибку 500.21 для всех будущих HTTP-запросов до тех пор, пока приложение не будет повторно циклически изменено. Вам не нужно выполнять относительно радикальные шаги IISRESET, очищая временный кэш ASP.NET, чтобы очистить ошибку - просто перезапустите приложение, сохранив файл web.config и избегая определенного пути запуска, который вызывает ошибку.

MS предложила обходной путь для нас - используйте SimpleMailWebEventProvider вместо TemplatedMailWebEventProvider. Это работает, так как он принимает HttpServerUtility.Execute из пути кода для первого запроса.

Я предположил, что MS представит новый параметр web.config <system.web> boolean - UseIntegrated - который позволяет приложению указать тип App Pool для инициализации. Очевидно, что IIS не перенаправляет тип пула приложений на ASP.NET, поэтому мое задержка - это обход.

Поставщик TemplatedMailWebEvent гораздо удобнее, чем SimpleMailWebEventProvider, и мы надеемся, что MS решит проблему.

Спасибо всем за чтение,

Говард Хоффман

Ответ 2

Столкнулась с той же проблемой, и исправление было легко.

1) Откройте командную строку Visual Studio 2010.

2) Запустите команду aspnet_regiis.exe -i

Ответ 3

1. IIS 7 выдает исключение, как показано ниже

2. Откройте командную строку Visual Studio 2010 в режиме администратора и выполните команду aspnet_regiis.exe -i

3. Проблема исправлена, как показано ниже. Приложение ASP.Net и приложение ASP.Net MCV работают бесперебойно.

Ответ 4

Проблема скорее в коде приложения. Временная папка файлов ASP.NET содержит предварительно скомпилированные копии вашего приложения и будет обновляться каждый раз при обращении к файлам приложений. Вы можете предварительно скомпилировать эти файлы с помощью aspnet_compiler.exe в папке \Windows\Microsoft.NET\Framework\v2.0.50727 \. Используйте параметр -errorstack, чтобы получить дополнительную информацию об ошибке, которую вы получаете. Длинные приложения, которые не перерабатываются, столкнутся с проблемами, если они используют много памяти или сохраняют большие объемы данных в состоянии сеанса inproc. если ваши сессии содержат большое количество информации, рассмотрите возможность использования диспетчера сеансов на основе sqlserver.