VB has gone mad - one for the real gurus

I'm getting a consistent error from a middle tier dll and can't find any information
anywhere on the vb procedure causing it.

The error log reports the following

MSVBVM60!__vbaCVarAryUdt + 0x47
ITSServerExtensions + 0x13CFF8
ITSServerExtensions + 0x10C324
RPCRT4!NdrServerInitialize + 0x1E8
RPCRT4!NdrStubCall2 + 0x586
RPCRT4!CStdStubBuffer_Invoke + 0xC5
OLEAUT32!UserEXCEPINFO_free_local + 0x20C4
+ 0xFFFFFFF7
+ 0x9008DA77

Does anyone know what this does ? or can advise how I can determine which
procedure in my dll used the vb procedure. I presume the hex numbers are
memory offsets but I'm not sure how this helps me.

"richard" <a@b.c> wrote in message news:3c627a03@10.1.10.29...
>
> I'm getting a consistent error from a middle tier dll and can't find any
information
> anywhere on the vb procedure causing it.
>
> The error log reports the following
>
> MSVBVM60!__vbaCVarAryUdt + 0x47
> ITSServerExtensions + 0x13CFF8
> ITSServerExtensions + 0x10C324
> RPCRT4!NdrServerInitialize + 0x1E8
> RPCRT4!NdrStubCall2 + 0x586
> RPCRT4!CStdStubBuffer_Invoke + 0xC5
> OLEAUT32!UserEXCEPINFO_free_local + 0x20C4
> + 0xFFFFFFF7
> + 0x9008DA77
>
> Does anyone know what this does ? or can advise how I can determine which
> procedure in my dll used the vb procedure. I presume the hex numbers are
> memory offsets but I'm not sure how this helps me.

If you are using Native Compilation, then try compiling with the "Create
Symbolic Debug Info" option checked. Then, if you have a nice debugger like
VC++, you can actually see the Visual Basic source code where the error
occurred. You might also consider using P-Code compilation. It's not common
for business logic code to see improvements from native code compilation, and
p-code crashes less.

Also, make sure you have the latest service pack for Visual Basic (SP5).

Good luck!
Matthew Solnit

The other habit you can get into is to create .map files whenever you
compile. This is easy enough to do: simply set the following environment
variable on your dev box and restart the IDE:
LINK=/MAP
or (bigger file, but more data)
LINK=/MAP /MAPINFO:LINES

You can now use the numbers in the call stack, combined with the .map file,
to track down the error. This is a little tedious for a big call stack, but
is a lot less invasive than putting .pdb files everywhere.

It looks like you're assigning an array of objects or UDTs to a Variant,
possible as part of an argument list. -Matt

"Matthew Solnit" <msolnit@y@hoo.c0m> wrote in message
news:3c628312$1@10.1.10.29...
> "richard" <a@b.c> wrote in message news:3c627a03@10.1.10.29...
> >
> > I'm getting a consistent error from a middle tier dll and can't find any
> information
> > anywhere on the vb procedure causing it.
> >
> > The error log reports the following
> >
> > MSVBVM60!__vbaCVarAryUdt + 0x47
> > ITSServerExtensions + 0x13CFF8
> > ITSServerExtensions + 0x10C324
> > RPCRT4!NdrServerInitialize + 0x1E8
> > RPCRT4!NdrStubCall2 + 0x586
> > RPCRT4!CStdStubBuffer_Invoke + 0xC5
> > OLEAUT32!UserEXCEPINFO_free_local + 0x20C4
> > + 0xFFFFFFF7
> > + 0x9008DA77
> >
> > Does anyone know what this does ? or can advise how I can determine
which
> > procedure in my dll used the vb procedure. I presume the hex numbers
are
> > memory offsets but I'm not sure how this helps me.
>
> If you are using Native Compilation, then try compiling with the "Create
> Symbolic Debug Info" option checked. Then, if you have a nice debugger
like
> VC++, you can actually see the Visual Basic source code where the error
> occurred. You might also consider using P-Code compilation. It's not
common
> for business logic code to see improvements from native code compilation,
and
> p-code crashes less.
>
> Also, make sure you have the latest service pack for Visual Basic (SP5).
>
> Good luck!
> Matthew Solnit
>
>

Do you make what I call "drivers" for your middle-tier components? I'll explain:
Create a standard exe, and add a class to it. On the class' code module page
add the code from your DLL to it. Put break points in the class starting
at the beginning. From the form code module in your exe instantiate the class
(e.g., the "form_onload()" event). When it hits your break point in the class,
start F8-ing through until the error occurs. Then stop execution. Put a break
where the error propogated, and start again. When it hits the break, the
error is about to occur. So, use the debug window and watch window to view
the status of all variables, objects, UDTs, arrays, etc. and see if any of
those contain unexpected values. You can even customize the form module to
do any type of thing to display information gleaned from class execution.

Before I deploy any component, I always test it rigorously with a driver.

Hope this helps.

Randy

"Matthew Curland" <mattcur@microsoft.com> wrote:
>The other habit you can get into is to create .map files whenever you
>compile. This is easy enough to do: simply set the following environment
>variable on your dev box and restart the IDE:
>LINK=/MAP
>or (bigger file, but more data)
>LINK=/MAP /MAPINFO:LINES
>
>You can now use the numbers in the call stack, combined with the .map file,
>to track down the error. This is a little tedious for a big call stack,
but
>is a lot less invasive than putting .pdb files everywhere.
>
>It looks like you're assigning an array of objects or UDTs to a Variant,
>possible as part of an argument list. -Matt
>
>"Matthew Solnit" <msolnit@y@hoo.c0m> wrote in message
>news:3c628312$1@10.1.10.29...
>> "richard" <a@b.c> wrote in message news:3c627a03@10.1.10.29...
>> >
>> > I'm getting a consistent error from a middle tier dll and can't find
any
>> information
>> > anywhere on the vb procedure causing it.
>> >
>> > The error log reports the following
>> >
>> > MSVBVM60!__vbaCVarAryUdt + 0x47
>> > ITSServerExtensions + 0x13CFF8
>> > ITSServerExtensions + 0x10C324
>> > RPCRT4!NdrServerInitialize + 0x1E8
>> > RPCRT4!NdrStubCall2 + 0x586
>> > RPCRT4!CStdStubBuffer_Invoke + 0xC5
>> > OLEAUT32!UserEXCEPINFO_free_local + 0x20C4
>> > + 0xFFFFFFF7
>> > + 0x9008DA77
>> >
>> > Does anyone know what this does ? or can advise how I can determine
>which
>> > procedure in my dll used the vb procedure. I presume the hex numbers
>are
>> > memory offsets but I'm not sure how this helps me.
>>
>> If you are using Native Compilation, then try compiling with the "Create
>> Symbolic Debug Info" option checked. Then, if you have a nice debugger
>like
>> VC++, you can actually see the Visual Basic source code where the error
>> occurred. You might also consider using P-Code compilation. It's not
>common
>> for business logic code to see improvements from native code compilation,
>and
>> p-code crashes less.
>>
>> Also, make sure you have the latest service pack for Visual Basic (SP5).
>>
>> Good luck!
>> Matthew Solnit
>>
>>
>
>