What if subscriber dies?   

Sorry for the cross-post, I really don't know where to post this question 
...

An object in my EXE uses CoCreateInstance() to create a COM object, which 
happens to live in a DLL (in-process, apartment threading).  Everything is 
written in C++ under VS 2005.

The DLL generates events that the EXE needs to know about, so the EXE 
creates an object that implements a particular interface, and then passes a 
pointer to that object (interface) to the DLL's object.  Now, when the DLL 
wants to tell the EXE something, it just calls a function on that interface 
and the magic happens.  Yes, I do all the proper QueryInterface() and such.

What is strange, is that even though the DLL is supposedly running 
in-process, sometimes when the EXE crashes, the DLL seems to live on.  The 
next time I run the EXE, I get strange errors from the DLL's COM object.  I 
shut down the EXE, restart it, and all is well.  These strange errors only 
occur the first time I run the EXE after the EXE has crashed (or been 
stopped by the debugger).

So I guess two questions ....

1) Why would my COM object (in the DLL) live on?  Why doesn't it die when 
the EXE crashes?

2) Is there a better way to handle this, so that the EXE crashing doesn't 
leave the DLL with a bad pointer?

Thanks!
Chris

date: Fri, 21 Dec 2007 13:04:27 -0700   author:   Chris Shearer Cooper

Re: What if subscriber dies?   

Unless we are talking COM+, your in-proc COM server (your
DLL) dies with the host process (your EXE). Why you get errors
after you restart the process is a matter of you debugging your
DLL to find out what's happening after a crash. Just don't delude
yourself that your DLL has magically survived the crash...

-- 
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Chris Shearer Cooper"  wrote in message 
news:13mo72epsratr33@corp.supernews.com...
> Sorry for the cross-post, I really don't know where to post this question 
> ...
>
> An object in my EXE uses CoCreateInstance() to create a COM object, which 
> happens to live in a DLL (in-process, apartment threading).  Everything is 
> written in C++ under VS 2005.
>
> The DLL generates events that the EXE needs to know about, so the EXE 
> creates an object that implements a particular interface, and then passes 
> a pointer to that object (interface) to the DLL's object.  Now, when the 
> DLL wants to tell the EXE something, it just calls a function on that 
> interface and the magic happens.  Yes, I do all the proper 
> QueryInterface() and such.
>
> What is strange, is that even though the DLL is supposedly running 
> in-process, sometimes when the EXE crashes, the DLL seems to live on.  The 
> next time I run the EXE, I get strange errors from the DLL's COM object. 
> I shut down the EXE, restart it, and all is well.  These strange errors 
> only occur the first time I run the EXE after the EXE has crashed (or been 
> stopped by the debugger).
>
> So I guess two questions ....
>
> 1) Why would my COM object (in the DLL) live on?  Why doesn't it die when 
> the EXE crashes?
>
> 2) Is there a better way to handle this, so that the EXE crashing doesn't 
> leave the DLL with a bad pointer?
>
> Thanks!
> Chris
>
>

date: Fri, 21 Dec 2007 14:26:20 -0800   author:   Alexander Nickolov

Re: What if subscriber dies?   

>
> What is strange, is that even though the DLL is supposedly running in-process, sometimes when the EXE crashes, the DLL seems to 
> live on.

That is quite simply impossible. Once the EXE is unloaded, the DLL is unloaded. I think you need to explain what you are 
experiencing, rather than what is your interpretation.



> The next time I run the EXE, I get strange errors from the DLL's COM object.  I shut down the EXE, restart it, and all is well.

So, the original EXE never got unloaded?

These strange errors only
> occur the first time I run the EXE after the EXE has crashed (or been stopped by the debugger).
>

I think you should describe what a "crash" is.

Brian

date: Fri, 21 Dec 2007 14:40:34 -0800   author:   Brian Muth