L
Lucas
I have written a COM dll using vc++ and ATL. I am using this dll from
an application written in VB. When the VB application finishes with
the object it sets the object = nothing. Somewhere between my objects
destructor, and the vb setting the object to nothing, the dll will
lockup. To ensure that it's not my code that's locking up, I inserted
a message box at the very beginning of the object's destructor. This
message box doesn't come up when the object locks up. However, the
object doesn't always lockup, and I have not been able to find any
pattern to indicate why it would lockup. I was wondering if anyone
has had any experience with the COM base objects locking up upon
destruction and what a possible cause might be. I don't believe it
has to do with reference counts: 1) the object is only referenced in
one place in the vb and that reference is never copied. 2) If the
reference count was not 0, the destructor wouldn't be hit, and the
"set object = nothing" call would simply return.
I am almost certain that it has to do with something I've done wrong,
but at this point, I don't even know where to begin looking.
The object supports dual interfaces, and is using a free-threaded
marshalling system. All thread synchronization (in my code) is
handled by a custom mutex object that cannot lockup in debug mode,
since it has a 1-second timeout.
Any ideas are greatly appreciated.
Thanks.
an application written in VB. When the VB application finishes with
the object it sets the object = nothing. Somewhere between my objects
destructor, and the vb setting the object to nothing, the dll will
lockup. To ensure that it's not my code that's locking up, I inserted
a message box at the very beginning of the object's destructor. This
message box doesn't come up when the object locks up. However, the
object doesn't always lockup, and I have not been able to find any
pattern to indicate why it would lockup. I was wondering if anyone
has had any experience with the COM base objects locking up upon
destruction and what a possible cause might be. I don't believe it
has to do with reference counts: 1) the object is only referenced in
one place in the vb and that reference is never copied. 2) If the
reference count was not 0, the destructor wouldn't be hit, and the
"set object = nothing" call would simply return.
I am almost certain that it has to do with something I've done wrong,
but at this point, I don't even know where to begin looking.
The object supports dual interfaces, and is using a free-threaded
marshalling system. All thread synchronization (in my code) is
handled by a custom mutex object that cannot lockup in debug mode,
since it has a 1-second timeout.
Any ideas are greatly appreciated.
Thanks.