COM architecture - Random Lock

[toon]

Hi all,
This is a long shot, but I am running out of idea's

The Architecture:
I have a VB ActiveX control, and an ATL COM server.
The COM sever is instantiated by an MFC dll, which then instantiates the
VB Ax control & passes it the Dispatch pointer to the ATL dll.
The VB Ax requests several interface pointers from the ATL dll.

The Problem:
Around 33% of the time we get a complete lock up. I have a log file
which traces how far we get through the code. And the lock doesn't always
occur in the same place, but usually when requesting the Interface Pointers
from the COM server.
I have _ASSERT s on the Ipointers within the ATL dll which verify they
are valid.
Once the lock occurs, the debugger cannot attach to the process so I
cannot debug it, and it has never happened once the debugger is already
attached.

Anyone got any ideas for how I can debug this? I am lost

Yours Hopefully

(sad) Toon

[jonnin]

Most likely, you have a pointer/memory foo. Look for over run of array, delete
of pointer that is not valid, etc. Also, Determine if a series of button
pushes etc always trips a lockup. Use the log to find a place the code never
crashes before, and trace by hand from there until you find it. But its
probably the memory thing, esp if it doesn't do it in the debugger.

Any use of hardware or dll, com, etc that you don't trust? Esp the hardware,
that can foo things up fast. But check this stuff if you still can't find
it...


"toon" <sbitz23@yahoo.com> wrote:
>Hi all,
> This is a long shot, but I am running out of idea's
>
>The Architecture:
> I have a VB ActiveX control, and an ATL COM server.
> The COM sever is instantiated by an MFC dll, which then instantiates
the
>VB Ax control & passes it the Dispatch pointer to the ATL dll.
> The VB Ax requests several interface pointers from the ATL dll.
>
>The Problem:
> Around 33% of the time we get a complete lock up. I have a log file
>which traces how far we get through the code. And the lock doesn't always
>occur in the same place, but usually when requesting the Interface Pointers
>from the COM server.
> I have _ASSERT s on the Ipointers within the ATL dll which verify they
>are valid.
> Once the lock occurs, the debugger cannot attach to the process so I
>cannot debug it, and it has never happened once the debugger is already
>attached.
>
>Anyone got any ideas for how I can debug this? I am lost
>
>Yours Hopefully
>
>(sad) Toon
>
>
>
>
>

[Ted]

Is this classic COM or COM+?

"toon" <sbitz23@yahoo.com> wrote:
>Hi all,
> This is a long shot, but I am running out of idea's
>
>The Architecture:
> I have a VB ActiveX control, and an ATL COM server.
> The COM sever is instantiated by an MFC dll, which then instantiates
the
>VB Ax control & passes it the Dispatch pointer to the ATL dll.
> The VB Ax requests several interface pointers from the ATL dll.
>
>The Problem:
> Around 33% of the time we get a complete lock up. I have a log file
>which traces how far we get through the code. And the lock doesn't always
>occur in the same place, but usually when requesting the Interface Pointers
>from the COM server.
> I have _ASSERT s on the Ipointers within the ATL dll which verify they
>are valid.
> Once the lock occurs, the debugger cannot attach to the process so I
>cannot debug it, and it has never happened once the debugger is already
>attached.
>
>Anyone got any ideas for how I can debug this? I am lost
>
>Yours Hopefully
>
>(sad) Toon
>
>
>
>
>

[toon]

"Ted" <TTarney@hotmail.com> wrote in message
news:3b976d98$1@news.devx.com...

> Is this classic COM or COM+?


Classic COM.

I am wondering if the problem is in the VB client though, as the COM server
has remained unchanged for 3 months - whereas the client has been under
development since.

Could the following cause a problem? ...
The VB client is a UserControl, which contains 8 other UserControls
We have a class that monitors what inputs are selected by the user on the
various controls & fires events to when required input is complete or has
been changed.

I have just noticed that during control initialization these events are
fired by several routines (the control is hosted on a C++ modal dialog)
including the UC_Show procedures before the dialog is displayed.

Could these events cause unpredicable lock ups?