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
>>
>>
>
>