Hmm.. Considering that you can use the handle of a loaded DLL to get pointers to the exported functions inside, it would seem logical that the same procedure can be applied vice-versa. When you load an application, you usually get an instance handle. Passing this instance handle out of the application context (thread) into a DLL's handler function (residing in another thread), should allow you to use GetProcAddress or a similar function to get the exported symbols of your .Net application. This should be pretty easy to implement with MFC, just by using AfxGetInstanceHandle in the executable, and passing this handle over to the DLL, you can use the handle to get the exported symbols. But a case with VB .Net and VC++ DLL, I'm not sure. I don't know how you can export symbols from a VB.Net application/DLL. See the VB manual for instructions on this one. But the outline of the procedure I mentioned should work. An additional problem may arise because the .Net application most obviously runs over the CLR, and is thus considered 'managed'. Passing a handle of a managed application to an unmanaged DLL might prove "interesting" results :) All in all, try this out, and you'll see what happens.. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.