Isolated (Reg Free) COM component behavior

Question

Hi,

I have a rather awkward situation.

I have one small COM exposed component (let's call it SmallCOM) which is a (Delphi) win32 dll, which I use from a managed C# assembly (through COM).

I have one big COM exposed component (let's call it BigCOM) which is a (Delphi) win32 dll, and which I use from the same managed c# assembly (through COM again).

And the "funny" part is that BigCOM also instanciates and uses SmallCOM through COM.

All this happens in the same process, and for some reason, I endup with low level uncatchable exception sometimes, telling me (when analzyed using windgb) that:

STACK_COMMAND:  .cxr 00000000 ; kb ; ~10s; .ecxr ; kb 

SYMBOL_STACK_INDEX:  2 

SYMBOL_NAME:  SmallCOM+178c6

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: SmallCOM 

IMAGE_NAME: SmallCOM.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  2a425e19

FAILURE_BUCKET_ID: 

NULL_CLASS_PTR_DEREFERENCE_c0000005_SmallCOM.dll!Unloaded

BUCKET_ID: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_WRITE_SmallCOM+178c6

WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/C#Service_exe/2_4_0_1/4ad7147f/ntdll_dll/5_2_3790_3959/45d70ad8/c0000005/0004afb2.htm?Retriage=1

Followup: MachineOwner

I guess BigCOM has done working with SmallCOM and has freed it, making it impossible to use again from the C# exe (and reloading it is out of question, the exe is a service, which is highly multi-threaded, and it uses this SmallCOM even while BigCOM is working).

So, my question is : would using Isolated Reg-Free COM to isolate SmallCOM in my C# exe solve the issue ? Or would the BigCOM and the C# exe, still sharing the same process, use the same SmallCOM.dll no matter what ?

Thanks in advance! Etienne.

Answer 1

If it is that the dll has been unloaded (which is something the COM runtime will do, it isn't done directly by an application) then it would seem to be likely that the library is returning values prematurely from DllCanUnloadNow (assuming that is the DLL implements the function).

If that is the case either it is a bug in SmallCOM which needs fixing or as a band aid you call GetModuleHandleEx with the GET_MODULE_HANDLE_EX_FLAG_PIN flag which will stop the DLL ever being unloaded.