Приложение ASP.NET Переходит к 500,21 …, пока Сброс IIS + Не Очищает Кэш ASP.NET Tempoary
Мы видим нечетный шаблон в нашей QA Lab. У нас есть два приложения ASP.NET, каждый развернутый на том же поле Windows 2008 SP2 +. Мы имеем наш Пул приложений, работающий в Учетной записи домена, и устанавливаем, чтобы никогда переработать. Тот же 1 Пул приложений используется обоими приложениями.
После того, как несколько часов хорошо работающих, новых пользователей, перемещающихся к странице в нашем приложении, получают Ошибочную Страницу IIS7 с 500,21 ошибками.
Если мы делаем только:
1) IISRESET 2) папка Change в c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Файлы и "ул." эти 2 приложения.
И затем перемещение к нашим веб-приложениям, все в порядке.
Затем несколько часов спустя, однако, эти 500,21 ошибочных возврата.
То, что кажется мне нечетный, является кажущимися отношениями между очисткой папок "Temporary ASP.NET Files" и проблемой, уходящей. У меня есть практика очистки папок "Temporary ASP.NET Files" при установке новой версии нашего приложения (приложений), но не иначе.
Эти отношения звонят знакомый кому-либо? Есть ли некоторая довольно новая функция IIS7 на работе здесь?
Текст ошибки:
Ошибка сервера в приложении "ВЕБ-САЙТ ПО УМОЛЧАНИЮ/PAIS"
Internet Information Services 7.0
Ошибочная сводка
Ошибка HTTP 500.21 - внутренняя ошибка сервера
"PageHandlerFactory-интегрированный" обработчик имеет плохой модуль "ManagedPipelineHandler" в его списке модулей
Подробная информация об ошибке
Модуль веб-ядро IIS
Уведомление ExecuteRequestHandler
PageHandlerFactory-интегрированный обработчик
Код ошибки 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/handlers@modules находятся в system.webServer/modules@name.
• Предварительные условия обзора в и разделы.
Ссылки и Больше информации ядро IIS не распознают модуль.
Просмотрите больше информации»
Заранее спасибо,
Howard Hoffman
2 ответа
Мы нашли настоящую проблему с помощью поддержки MS ASP.NET. Это довольно тонко. Я думаю, что MS заявила, что исправит проблему в следующем выпуске App Fabric (который сейчас является RTM). Скрещенные пальцы.
Проблема постоянно возникает в этом сценарии:
1) Веб-приложение ASP.NET еще не запущено. Он включает привязки WCF Net.Pipe и / или Net.Tcp. Я думаю, что то же самое произойдет и с NetMsmq, но не пробовал.
2) Входящий запрос службы активации Windows NetPipe или NetTcp WCF - это начальный запрос, запускающий домен приложения.
3) Приложение использует «интегрированный» пул приложений IIS (IIS7 или IIS 7.5)
4) Приложение использует HttpServerUtility.Execute во время этого 1-го запроса.
Оказывается, наше приложение запускало событие мониторинга работоспособности ASP.NET во время самой первой операции WCF - той самой операции, которая заставила службу активации Windows (WAS) запустить наше приложение. Наша конфигурация мониторинга работоспособности включает TemplatedMailWebEventProvider.
Наше приложение использует «интегрированный» пул приложений IIS.
TemplatedMailWebEventProvider реализован для создания тела сообщения электронной почты в формате HTML. Он использует перегрузку System.Web.HttpServerUtility.Execute (string, TextWriter, Boolean) .
Для этого варианта использования эта перегрузка делает неправильную вещь - она инициализирует «классический» HTTP-конвейер на основе пула приложений IIS. Поскольку это неправильный конвейер для «интегрированного» пула приложений IIS, конвейер повреждается при следующем HTTP-запросе, который на самом деле является первым входящим HTTP-запросом.
Таким образом, вы получите ошибку 500.21 для всех будущих HTTP-запросов, пока приложение не будет перезапущено. Вам не нужно выполнять относительно радикальные шаги IISRESET, очищая временный кеш ASP.NET для устранения ошибки - просто перезапустите приложение, сохранив файл web.config, и избегайте определенного пути запуска, который вызывает ошибку.
MS предложила нам обходной путь - использовать SimpleMailWebEventProvider вместо TemplatedMailWebEventProvider. Это действительно работает, поскольку для первого запроса требуется HttpServerUtility.Execute из пути кода.
Я предлагал MS представить новый логический параметр web.config - UseIntegrated - который позволяет приложению указывать тип пула приложений для инициализации. с участием. Очевидно, что IIS не пересылает тип пула приложений в ASP.NET, поэтому я предлагаю обойти , что .
Провайдер TemplatedMailWebEvent гораздо удобнее для пользователя, чем SimpleMailWebEventProvider, и мы надеемся, что MS решит эту проблему.
Спасибо всем за чтение,
Говард Хоффман
Проблема, скорее, в коде приложения. Папка Temporary ASP.NET Files содержит предварительно скомпилированные копии вашего приложения и будет обновляться при каждом доступе к файлам приложения. Вы можете предварительно скомпилировать эти файлы с помощью aspnet_compiler.exe в папке \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \. Используйте параметр -errorstack, чтобы получить дополнительную информацию о полученной вами ошибке. Длительно работающие приложения, которые не рециркулируют, столкнутся с проблемами, если они используют много памяти или сохраняют большие объемы данных в состоянии сеанса inproc. если ваши сеансы содержат большой объем информации, рассмотрите возможность использования диспетчера сеансов на основе sqlserver.