What if subscriber dies?

[Chris Shearer Cooper]

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

[Alexander Nickolov]

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: ***@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

Post by Chris Shearer Cooper
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

[Brian Muth]

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