2015-06-10 1 views
2

В настоящее время я переношу платформу ASP из веб-серверов Windows 2003 R2 IIS 6 на веб-серверы Windows 2012 R2 IIS 8.5. Я нахожусь на том этапе, когда я переместил несколько сайтов на два отдельных веб-сервера 2012 года, все выглядело великолепно, клиенты и разработчики довольны ... Однако следующая ошибка появилась после нескольких дней хостинга на одном из новые серверы.ASP Ошибка 0223 - TypeLib Не найден, прерывистый, разрешен после перезапуска IIS

Active Server Pages error 'ASP 0223' 

TypeLib Not Found 

/jobboard/conf/constants.vbs.inc, line 1 

METADATA tag contains a Type Library specification that does not match any Registry entry. 

метаданным тег ниже:

<!--METADATA TYPE="typelib" NAME="Microsoft ActiveX Data Objects 2.8 Library" UUID="{2A75196C-D9EB-4129-B803-931327F72D5C}" VERSION="2.8"--> 

Перезапуск IIS на этом сервере решен вопрос (хотя и временно).

Впоследствии другой веб-сервер 2012 года в производстве представил такую ​​же ошибку через пару дней, снова перезапустил IIS и работает пока.

Я проверил реестр и соответствующий тег существует с правильным UUID и правильными разрешениями.

Это не влияет на все сайты на сервере, а всего на всех сайтах в определенном пуле приложений.

Пулы приложений используют идентификатор пользователя домена, а сайты разделяются на несколько общих пулов.

+0

Является ли пул приложений запущенным в 32-битном режиме? Единственная причина, по которой я могу думать, что для IIS не найти запись в реестре, было то, что она искала неправильный куст реестра * (32 или 64 бит) * – Lankymart

+0

На серверах с 64-битной архитектурой 32-разрядные классы хранятся в 'HKEY_LOCAL_MACHINE \ Software \ Wow6432Node \ Классы, а 64-разрядные классы хранятся в 'HKEY_LOCAL_MACHINE \ Software \ Classes'. – Lankymart

+0

Тот факт, что это прерывистый, хотя и не указывает на это. – Lankymart

ответ

1

Я теперь определял, что вызывает вышеупомянутую проблему ...

Наших сайтов на IIS работает в ряде общих пулов приложений, работающих в качестве пользователя домена. У нас также есть задание планировщика Windows, которое запускает несколько сценариев за ночь, которые также работают как один и тот же пользователь домена.

Кажется, что случаи, когда это задание диспетчера запускаются, мешают рабочим процессам IIS. Когда он завершает и заканчивает свой сеанс пользователя, он выгружает файл реестра в память, который также могут использовать процессы w3wp.exe.

Эта ошибка представлена ​​в журнале событий ...

ОС Windows обнаружила, что файл реестра по-прежнему используется другими приложениями или службами. Теперь файл будет выгружен. Приложения , содержащие файл реестра, могут неправильно функционировать . От пользователя не потребуется никаких действий.

Наряду с ссылками на выполняемые в настоящее время процессы w3wp.exe.

Он был реплицирован, когда я терминал обслуживался в качестве пользователя домена и выходил из системы через некоторое время. В журнале событий была представлена ​​ошибка, и вскоре все бомбы бомбили.

Выполнение запланированного задания другим пользователем устраняет эту проблему для нас.

+1

Спасибо! У нас была такая же проблема, но другая причина. У нас была служба Windows с использованием того же пользователя, что и пул приложений. Чтобы воссоздать, мы убили сервисный процесс (остановки обслуживания было недостаточно). – Spongeboy

0

Я помню, что у меня есть файл include для ADOVBS.inc со всеми константами ADO внутри и включая его как стандартный ASP, внутри моего глобального файла include, который включен на каждую страницу сайта.

Это было до того, как я использовал способ META для включения файла.

Так что, возможно, последнее средство - вернуться к такому способу загрузки в константах ADO.

Похоже, что какой-то порог попадает, CPU/Memory ?, который затем предотвращает кеширование IIS/загрузку файла из реестра. Затем это вызывает ошибку и повторную загрузку пула. Поскольку перенаправление не выполняется на страницу обработчика ошибок 500.100.asp, которая скрывает данные об ошибке от пользователя. Это предполагает, что ошибка в IIS и связана с сервером.

Благодаря