Cross-Thread DLL Callback Into VB?

[shadypalm88]

I have a Visual Basic program that calls a function in a DLL, myriad_net_connect (which was written in C) that creates a socket and then starts a worker thread.  The thread connects said socket and start listening for incoming data.  Event notifications are signalled to the VB program via a callback.  Calling the callback function from myriad_net_connect works fine, but when the worker thread tries, it triggers an access violation exception.  The worker thread is accessing the thread data OK, and getting the same address of the callback function (net_event_proc) as myriad_net_connect is.  The thread can also properly access the only variable argument being passed to net_event_proc.  When I tried this from a C application, the callback from the thread went through fine.

So, is this even possible, or is there some security setting I need to set?  Because debugging this looks like hell, especially since I constantly get this other exception (EXCEPTION_FLT_INEXACT_RESULT):

(e34.b24): Unknown exception - code c000008f (first chance)

Program received signal SIGFPE, Arithmetic exception.
0x7c81eb33 in _libversion_a_iname ()

and GDB breaks on those exceptions.

[Adron]

Do you use On Error Resume Next in your VB program? Because that exception is what VB uses to signal a run-time error. If you fix your VB program never ever to generate a run-time error (handled or unhandled), you won't get those messages from the debugger anymore. For windbg I know you can also disable displaying that exception, but it does make sense to display if you only get run-time errors when there is an error that actually needs debugging.

[shadypalm88]

Ah, I see.  Some more effective debugging yielded this:

(10d8.898): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=00000008 edx=01f4fb34 esi=0047a103 edi=01f4fb00
eip=6600a12a esp=01f4fab4 ebp=01f4fab8 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\MSVBVM60.DLL -
MSVBVM60!rtcCommandBstr+0xcf:
6600a12a 8b700c           mov     esi,[eax+0xc]     ds:0023:0000000c=??
0:003> KB
ChildEBP RetAddr  Args to Child             
WARNING: Stack unwind information not available. Following frames may be wrong.
01f4fab8 660e42b4 00000000 66107975 00000003 MSVBVM60!rtcCommandBstr+0xcf
01f4fb14 66100fcd 00d05efc 00000005 00000003 MSVBVM60!_vbaCySgn+0x28
01f4fc84 660fd37b 004910cc 01f4fd04 00000000 MSVBVM60!_vbaFreeVar+0x2581
01f4fda8 660fd37b 004910cc 01f4fe6c 01f4fe68 MSVBVM60!ProcCallEngine+0x31e
*** WARNING: Unable to verify checksum for C:\Program Files\Myriad\myriadhelp.dll
01f4ff00 00dd1f1a 0049141c 00000000 00000000 MSVBVM60!ProcCallEngine+0x31e
01f4ffb4 7c80b50b 00e03f30 0012f10c 7c926a44 myriadhelp!myriad_net_listener+0x5a [b:\myriadhelp\network.c @ 232]
01f4ffec 00000000 00dd1028 00e03f30 00000000 kernel32!BaseThreadStart+0x37

Now, I don't know any x86 assembler, but what I get from that and some previous tweaking is that VB function calls from another (as far as VB is concerned, foreign) thread are going to fail.  (It was even failing in a call to MsgBox before!)

Hm.  Well, the entire purpose of this was to get a cleaner solution for networking then the one I'm using now.  The current one uses WSAAsyncSelect and subclasses some unused controls on a form to handle the socket event messages, and is overall very kludgy.  Anyone have any alternative suggestions?

[Adron]

Do everything in one thread, a loop with MsgWaitForMultipleObjects and a DoEvents when you find that there are window messages waiting.