I posted this on vb groups, no answer. I am sorry if posting this here
offends you, but here it is.

c++ com server. Dll. One custom (!) interface. Three methods. Inside the com
server is a state-machine that gets created upon object construction,
destroyed on object destruction. The state-machine maintains a pool of
threads to process data coming through MS queues.

c++ client. MFC-based. The client creates instantiates the server object,
uses it and destroys it. Everything goes fine. BoundsChecker reports memory
leaks inside CRT (I think.. reports leaks in ./xlocale, locale0.cpp, etc.)
but they are not reported in the output window of the IDE. I assume then
everything is fine. I think BC tends to overwork.

Created an _extremely_ simple vb client. That does the same thing the c++
client does. When run outside of vb IDE the client runs fine. Inside vb IDE
is another story.
First run inside vb IDE the client runs OK. Upon client exit, Task Manager
shows the thread count number of vb.exe remaining at the level when client
was running (as if the server object is still active). At second run of the
client in vb IDE, the object is dead, does not report back to client
anything, and any attempt to call it shows me an _uninitialized_ server
object (assertion fires, the c++ IDE pops-up and de{*filter*} shows server
object in the state mentioned). The same uninitialized state the object
would be after deactivation. This while the thread count number the object
would have at normal run (cannot emphasize this enuff). As if the code
inside the server object does not stop the threads.

Any ideas and insights on how the _crappy_ vb instantiates com objects? Does
it do pooling of some sort?? I know vb has no destructor concept but
releasing an object reference should send that com object to sleep, doesn't
it?

Thanks,
An exhausted fellow programmer