Создание объектов внезапно начинает сбой после того, как они были успешно загружены в память

Поведение:
Приложение загружается и используется как ожидалось. Внезапно, конкретная DLL больше не может быть загружена. Сообщение об ошибке:
ActiveX компонент не может создать объект.
В каждом случае объект был успешно создан много раз перед сбоем. Все объекты отмечены как "сохранить в памяти".

Эта ошибка очищается, когда пул приложений перерабатывается. Это может быть несколько часов или месяцев до того, как он снова появится.

Проблема произошла в течение двух часов после обновления, а также никогда не происходило в месяцах безотказной работы.
Проблема произошла с сотнями одновременных пользователей (интенсивное использование), а также с 1-3 пользователями.

Пока проблема возникает, процесс, запускающий этот пул приложений, не может создать объект, который терпит неудачу. Однако он может создавать любые другие объекты. Память, ЦП и другие ресурсы остаются при нормальном использовании. Кроме того, другие процессы (например, автономные exe) могут успешно создать объект.

Первый экземпляр проблемы появился в середине 2008 года. С тех пор было менее пятидесяти экземпляров, несмотря на пул из сотен серверов, для которых это произошло. Все экземпляры, кроме одного, потерпели неудачу в одной DLL.

Информация об ошибке DLL:
наиболее распространенная - общая структура данных, реализующая b-дерево, не имеет ссылок, кроме интерфейса. Код состоит из массивов и одного использования функции события vb6. С 2005 года объект не был изменен.
одноразовое взаимодействие с модулем .NET. ошибка возникает при попытке создать объект interop, а не объект .NET. Этот объект обновляется несколько раз в год.

Среда приложения:
Приложение IIS для хостинга
VB6, классический ASP, некоторые взаимодействия с небольшими компонентами .NET
Windows Server 2003/Windows Server 2008 (обе проблемы были независимо)

Попытки воспроизвести:
Использование сценариев (и реальных людей) для запуска тех же рабочих процессов конечных пользователей, о которых сообщалось в журналах за несколько дней до возникновения проблемы.
Использование скриптов для создания/уничтожения подозрительных объектов как можно быстрее из нескольких одновременных сеансов.
Дикие предположения. Нет намеренного успеха, но он проявляется случайно на серверах сам по себе.

Устранение неполадок:
Обзор кодов
Испытательные жгуты для исследования верхних пределов создания/разрушения объектов
Проверка возможности создания объекта за пределами процесса, испытывающего проблему
Мониторинг ресурсов с течением времени на серверах под нагрузкой
Обзор журналов IIS, ошибок и событий, чтобы определить события, которые приводят к проблеме

Вопросы:
Любые идеи о том, как воспроизвести проблему?
Что может вызвать такое поведение?
Идеи обходить первые два вопроса в пользу быстрого решения?

Ответы

Ответ 1

DLL не на сетевом диске? Вы можете получить "глюки", когда диск не доступен мгновенно, а значит, COM не может делать то, что ему нужно, и может не заметить, что диск снова доступен.

Ответ 2

Я использовал Process Monitor для отладки аналогичной проблемы при доступе к стеку ADO/OLEDB. Выключенная среда в какой-то момент была повреждена, а классы ADO зарегистрированы в InprocServer32, где REG_EXPAND_SZ указывает на% CommonProgramFiles%\System\ado\msado15.dll или аналогичные OS x64.

Также, когда вы регистрируете приложение с Restart Manager, при сбое процесс перезапускается процессом winlogon, чья среда отличается от проводника, и, к сожалению, отсутствует% CommonProgramFiles% - ouch!

Ответ 3

Это похоже на случайный сбой; некоторые условия гонки.
Попробуйте VMWARE, чтобы записать состояние машины, на которой вы запускаете эту DLL. Когда произойдет ошибка, вы можете воспроизвести запись и проверить содержимое памяти. Вот почему вам не придется проигрывать try and catch ошибку. По крайней мере, у вас будет хорошая запись.

Пока я не могу предоставить решение, попробуйте catching ошибку и повторите попытку загрузки DLL, когда это произойдет после обновления среды.