Вам действительно нужно было бы получить и просмотреть журналы событий приложений и системы сервера и HTTPERR за период, когда сервер сообщал об этих ошибках.
Без них было бы трудно догадаться, что было основной причинойпроблемы.
Обновление:
ОП неправильно пометил свой вопрос, поэтому следующий раздел больше не применяется.Однако я оставлю это на месте, потому что я думаю, что информация полезна для тех, кто сталкивается с этими проблемами и, возможно, думает о переходе на IIS7.x.
Вы правы, что запуск двух разных .NET Framework в одном и том же пуле приложений может привести к этим ошибкам, но вы склонны видеть это в Windows 2003 / IIS6, а не в Windows 2008 / IIS7.
IIS7использует немного другой подход к указанию, какая версия .NET Framework загружается, и это определяется свойством пула приложений managedRunTimeVersion.Когда запросы обрабатываются IIS / ASP.NET, сопоставление обработчиков сайта использует атрибут preCondition, чтобы определить, когда загружать требуемый обработчик (что похоже на сопоставление сценариев в предыдущих версиях IIS).
Этот механизм предотвращает загрузку неверной версии времени выполнения в рабочий процесс пула приложений.
Так что, если пул приложений настроен для запуска .NET Framework версии 4.0, будет загружаться только эта версия, даже если ваше приложение созданопротив v2.0.
Здесь есть отличная статья о том, как это работает:
Ахтунг!Предварительные условия IIS7
Раздел, посвященный обработчикам примерно на полпути, объясняет, почему опасность случайной загрузки неправильной версии .NET в пул смягчается функцией preCondition.
Ошибка недоступности серверного приложения обычно означает, что произошло что-то катастрофическое (например, загрузка ISAPI-фильтра неправильной версии ASP.NET в уже запущенный рабочий процесс).
Не закрытие соединений SQL вряд ли вызовет такой серьезный тип ошибки.ошибка.Вы бы, скорее всего, увидели бы желтый экран ошибок времени выполнения смерти, если бы это было так.Заканчивание соединений SQL обычно не приводит к изгибу ASP.NET настолько, что вся служба превосходит саму себя.
Мой главный подозрение - проблема с разрешениями, когда удостоверение пула приложений не может правильно получить доступ к приложениюпапки.Но это всего лишь догадка.
Опять же, вам нужно получить журналы событий приложений и системы и журналы HTTPERR (они находятся в %systemroot%\System32\LogFiles\HTTPERR. Это будет содержать подсказки и факты о том, что пошло не так.
Обновление 2:
В Windows 2003 / IIS6, если у вас два приложения с разными версиями ASP.NET, которые находятся в одном пуле, вы будете получите эту ошибку. По моему опыту (я работаю на веб-хостера), это основная причина этой печально известной страницы ошибки:
Также есть контрольное событиезарегистрирован в журнале событий приложений:
Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1062
Date: 12/01/2011
Time: 12:31:43
User: N/A
Computer: KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.
Хотя ваше корневое приложение может не записываться в ASP.NET, вполне вероятно, что что-то вызвало загрузку другой версии платформы в пул приложений вашего сайта.
- в корне есть мошенник
web.config ... это заставит ASP.NET загрузить - в картах сценариев сайта есть сопоставление с ASP.NET 1.1 (менее вероятно), но возможно)
Я склонен думать, что ваше новое приложение наверняка оказалось в пуле, где другие сайты или приложения работали с другой версией фреймворка.Единственный способ выяснить это - получить журналы событий приложений и найти событие, показанное выше.