Ответственны ли COM-объекты за хранение своего собственного модуля в памяти?

Question

Скажем, вы делаете следующее:

1) Загрузите foo.dll с помощью LoadLibrary.

2) Получить указатель на функцию, используя GetProcAddress.

3) Вызвать функцию, дав вам ссылку на COM-объект, реализованный в этом модуле.

4) Освободите foo.dll, позвонив в FreeLibrary.

5) Вызовите метод для COM-объекта.

Вы ожидаете, что шаг 5 будет успешным, а не AV? То есть сам COM-объект отвечает за вызов LoadLibrary (снова) для увеличения счетчика ссылок, который Windows хранит для каждого модуля, гарантируя, что он не переживает модуль?

Answer 1

Конечно, нет. Счетчик ссылок на модули поддерживается обычными методами использования - то, что вы делаете, это бэкдор в схему времени выполнения. Обычно вы используете CoCreateInstance и т. Д. Для создания ваших объектов - это обертка вокруг вызова CoGetClassObject и DllGetClassObject. CoGetClassObject вызывает CoLoadLibrary, который поддерживает счетчик ссылок на dll. Кроме того, вы можете вызвать LockServer для объекта класса, чтобы сохранить счетчик ссылок на объект класса для повышения производительности, но это не требуется, чтобы гарантировать, что DLL остается загруженным.

Answer 2

Я бы ожидал AV. Даже если сегодня не было AV, это, вероятно, аварийное завершение.

В случае, подобном этому, когда COM-объект возвращается через пользовательский экспорт DLL, я не ожидал бы, что COM-объект увеличит счетчик ссылок DLL - если приложение явно использует ресурсы из DLL, это явно Приложение загружено, так как приложение загружено.

Для внутрипроцессных COM-объектов, которые создаются с помощью обычного маршрута CoCreateInstance, DLL обычно экспортирует DllCanUnloadNow, который должен возвращать S_FALSE, пока есть ожидающие ссылки.

Однако ничто не мешает COM-объекту увеличить счетчик ссылок DLL через LoadLibrary - в этом нет ничего противозаконного или небезопасного.