Active X exe doesn't die itself.

[manipradhan]

I am using a timer control on a form to activate an Active X exe which does some work and at the end just unloads the form cleans up all the objects. This should ensure that the component gets unloaded but sometimes it doesn't. I can use the END statement to end the Active X exe forcibly but I have read that it is not a good idea. I checked up MSDN and it says that the component should get unloaded after all its forms are unloaded and no client holds a reference to one of its public components.
Is there something I am missing here?

[jim mcnamara]

IUknown implements the Release method - as you know.
Release has to be called the same number of times that the AddRef method (usually called by QueryInterface) has been called, so the reference count is zero. When it's zero the ActiveX component exits.

Clearly your reference count is not being decremented somewhere in the client-side code.

The reason this is very likely to be true is that it only happens sometimes - meaning that there is/are code path(s) invoked in which the

 Set Obj = Nothing

or it's equivalent is not executed. Losing scope also causes the object reference count to be decremented, unless the function is interrupted by something like a timer event that subsequently unloads the form.
This same kind of thing causes memory leaks, which is technically what you have.

[manipradhan]

Thanks for the info.
But, the client is just a standard exe. I checked up and the object reference is explicitly set to nothing and there are no timers involved with the client exe.

Is it advisable to do an END in this case, when nothing else works. And the most frustrating part is that this problem only occurs occasionally.

[jim mcnamara]

I guess I read the same MSDN article.

END is supposed to go out and zero out any outstanding references. It does that, in my experience. I think the idea of 'bad' is that incomplete data transactions may not complete, or buffers aren't flushed to disk. I've not seen this, but it doesn't mean it can't happen.

I've had to resort to END once before, and so far I can't see a problem. It's either END or a dangling process wasting resources.
Of the two I vote for END.

[manipradhan]

Yes, I guess I will have to resort to the same technique and hope that everything turns out well.