COM对象是否负责将自己的模块保存在内存中？

Question

假设您执行以下操作：

1）使用LoadLibrary加载foo.dll。

2）使用GetProcAddress获取指向函数的指针。

3）调用该函数，为您提供对该模块中实现的COM对象的引用。

4）通过调用FreeLibrary免费获取foo.dll。

5）在COM对象上调用方法。

您是否希望第5步成功而不是AV？也就是说，COM对象本身是否负责调用LoadLibrary（再次）来增加Windows为每个模块保留的引用计数，确保它不会超过模块？

Answer 1

当然不是。模块引用计数由常规使用方法维护 - 您正在做的是运行时方案的后门程序。通常，您使用CoCreateInstance等来创建对象 - 这些是调用CoGetClassObject和DllGetClassObject的包装器。 CoGetClassObject调用CoLoadLibrary来维护dll上的引用计数。此外，您可以在类对象上调用LockServer以维护类对象的引用计数以提高性能，但这不是确保dll保持加载所必需的。

Answer 2

我期待AV。即使它今天不是AV，这可能是等待发生的崩溃。

对于这样的情况，通过自定义DLL导出返回COM对象，我不希望COM对象增加DLL的引用计数 - 只要应用程序正在使用DLL中的资源它加载后，应用程序负责保持加载该DLL。

对于通过普通CoCreateInstance路由创建的进程内COM对象，DLL通常会导出DllCanUnloadNow，只要有未完成的引用，它就应该返回S_FALSE。

但是，没有什么能阻止COM对象通过LoadLibrary递增DLL的引用计数 - 这样做没有任何违法或不安全的信息。