VB Forum / Win API / January 2007

I posted to this group rather than microsoft.public.vb.com because this
group seems to be more active and I think that the API gurus here might
better appreciate the low-level hackery that I'm going to espouse near
the end.

Every now and then, I'll get "Object does not support Automation or
does not support expected interface" runtime error when running a VB6
app where I can't immediately determine the cause("Duh! I forgot to
register component X" or "Duh! I am referencing an older version of
X"). This is especially true in a large application I'm trying to
debug. The application is multi-tier, consisting of a "main" EXE and
various ActiveX DLL's and EXE servers. The application is a
records-management system - there is one ActiveX DLL that handles error
logging for every other EXE/DLL in the application, one DLL which
provides the low-level database access layer, and various DLL's (along
with one or two EXE servers throw in) which taken form an intermediate
abstraction layer between the main application and the database access
layer. In simpler, graphical terms:

To Database: Main application ---> Intermediate DLLs ---> DB Access
Layer ---> Database

---> Main application

The product is in it's 8th year, and in the beginning, it was
apparently straight-forward to debug, even though multiple EXEs and
DLLs were involved. Back then, if you wanted to debug A.dll, you could
just fire load the main app's VBP and A.VBP into the IDE, set a
breakpoint in A, start it up, and then start the main app. The VB6
debugger worked fine, breaking into A's code without a hitch, as anyone
would reasonably expect. These days, it ain't so simple. For example,
our database access layer is wrapped up in one DLL (it always has
been), but if want to break into code, loading the main app project and
the DB access layer project into the IDE and running no longer works. I
will say straight away that none of the components involved are
MTS/COM+ components (I hear the VB6 debugger doesn't always play nice
with COM+). Anyway, if I start up the DB access layer component in the
IDE, and then fire up the main app (in the same IDE or in another IDE
instance), it always blows up with an "Object does not support
Automation or does not support expected interface" runtime error. The
odd thing is that my code isn't directly causing the error, because
even with Break on All Errors set, the error actually pops up in a
standard message box. The caption is "VBDataViewWindow", but I'm not
sure if it's telling the truth (and anyway, I don't think it's worth
trying stepping into the VB6 runtime to figure out why my code is
breaking the Data View Window - trying to interpret COM-intensive code
in x86 assembly isn't my idea of a good time; I still think it's
strange). The application works fine outside of the IDE, so I suspect
it's indirectly related to the fact that, in the IDE, VB6DEBUG.DLL
impersonates any COM components also running in the IDE - I read
somewhere that when the debugger hosts a COM component in this way,
although the component still looks like an in-process server to the
outside world, it's actually running out-of-process, which can
apparently in rare cases hose things up because the debugger might not
be able to marshal all of the types that the component deals with.

My point with all this is simple: I assume that the VB6 Automation
error is what the IDE pops ups whenever a QueryInterface call returns
E_NOINTERFACE. So, my question is, is there any (fairly
straightforward) way to figure out what the VB6's last call to
QueryInterface looked like, so that I can figure out what interface it
was trying to get at. I suspect the missing interface is IMarshal, but
that's only a wild guess since I'm not too familiar with the ins and
outs of COM marshalling.

I was thinking I could write a VB6 add-in to do this, but it would
pretty hackish, because I would have to cheat by finding VB6's IUnknown
vtable (I believe the same one is shared by all VB6 components in a
given process), pointing QueryInterface to my own custom version,
logging the parameters I receive to a window, and then calling the
original QueryInterface function. In essence, the add-in would generate
a history of all the QueryInterface calls up to the point where I get
an Automation error. Then it would be pretty safe to assume the most
recent call was the one that failed and based on the IID parameter
passed to that call I can at least put a name on the interface and
(maybe) get a better idea of what the heck is going on. I'm wondering
if that makes sense or if anyone has encountered similar spurious
errors apparently coming from VBDataViewWindow when debugging multiple
components in the IDE (the add-in code runs great in my head, but
haven't tried it out yet ;-)

---
Mike S