Ny safe way to keep member pointers to COM objects from another dll in a singleton COM object

comdllsingletonwinapi

I recently ran into a problem with a COM object that was using a singleton class factory and had members that were pointers to other COM objects implemented in a different DLL than the singleton object.

These other COM objects were created by the singleton object and that was the only reference to them.

Since the singleton object is never destroyed until its module is unloaded, what seemed to be happening is that sometimes at that point the DLL where the other COM objects (members of the singleton) were implemented had already been unloaded and in that case there would be a crash when the singleton released its references to those objects in its destructor.

The DLL implementing the other COM objects is aware that there are references held to the objects and returns S_FALSE from its DllCanUnloadNow method.

However, this doesn't seem to prevent the DLL from being unloaded always.

Is there any safe way to keep member pointers to COM objects from another dll in a singleton COM object?

Best Answer

You may very well be suffering from a "wrong" module unload order. See Why are DLLs unloaded in the "wrong" order? for more information.