Sorry, the GCHandle exception is a red herring, the real issue is further up the call stack

later

 We are using the C++ TIBCO RV class, and have wrappered them in Managed C++, hence no COM.  

 It looks to me like the TIBCO RV OTibrvCmMsgCallback::OnMsg C++ method callback is call from the wrong domain.  Once can possibly assume that the OnMsg is called when a message is received on a subject in a similar fashion to the MFC class CAsyncSocket::OnReceive.  Assuming this is a good guess, then CAsyncSocket::OnReceive appear to be called in the wrong domain.

 later

   "Dave" <noSpamdlevineNNTP2@wi.rr.com> wrote in message news:etQwzuZtDHA.1764@TK2MSFTNGP10.phx.gbl...
   This may be some COM related callback problem that occurs when an event fires. I'd get Adam Nathan's book on COM interop. On his blog he also has an interceptor program that looks at transitions between managed and unmanaged code. If your problem lies in that area this might help.

   It sounds like the problem is related to marshalling an object across appdomain boundaries within a callback. When a failure occurs the exception is reflected back into the unmanaged wrapper, probably by translation into an error code, where it is then passed back again into the managed world as a COM error, where it is translated back again into an exception. This managed-unmanaged-managed transition is losing context data along the way.

   One possible means of checking if this is the problem is configuring your debugger to break on first-chance exceptions. You will probably get loads of breaks due to exceptions that you don't care about and will want to ignore but eventually you should see the one you are interested in (and can then add filters so you don't have to deal with all the other exceptions). (A 1st chance exception is delivered to attached debuggers by the OS before the app processes it with SEH).

     "Matt Davey" <Matt.Davey@finetix.com> wrote in message news:eKFei%23QtDHA.1224@TK2MSFTNGP09.phx.gbl...
     Sorry, forgot the last bit of info.  The GCHandle exception is from our RV wrapper, which is good and bad.  Good since it get into our code when run on the Longhorn CLR, bad because we should not get the exception

     Later
       "Matt Davey" <matt.davey@finetix.com> wrote in message news:exC3RXQtDHA.2244@TK2MSFTNGP09.phx.gbl...
       Hi,

       Tried all that.  The code works fine in the new domain until a message comes over RV, at which point I am guessing that TIBCO's RV library recrive a message on a socket, and invokes a callback, which we get via a function pointer in C++, and then fire the message into C# via a managed event.  However, when the get the exception as detailed below, none of our code has been hit, and there is no callstack in the debug showing the TIBCO dll - there is no call stack full stop.

       Interesting, if one run the same code compiled on VS 2003, on a Longhorn machine with Whidbey install, we get a completely different exception - System.ArgumentException: Can not pass a GCHandle across appDomains.  What is strange is that we are not passing anything across appdomains.  The main app just creates an appdomain and says ExecuteAssembly.

       Later
         "Sebastien Lambla" <sebastien.lambla@6sens.com> wrote in message news:u9f5S7PtDHA.2060@TK2MSFTNGP10.phx.gbl...
         This is really wierd behavior... If you have a managed dll loading problem, and fusion loader doesn't show you anything, then your managed C++ wrapper must have either a bug or lack a security authorization or is not probing where needed or can't find what it wants for some wierd reason.

         What I'd be really looking at is specifying manually all the folders with all the dlls needed by the app to the appdomain when creating it (not after), including any associated ocx files for unmanaged calls. If nothing works, try to copy everything in your system folder, try again. If it still doesn't work, I can't help you cause I have no other ideas.
         --
         Sebastien Lambla
         http://thetechnologist.is-a-geek.com/blog/

           "Matt Davey" <matt.davey@finetix.com> a écrit dans le message de news: uhichMDtDHA.3532@TK2MSFTNGP11.phx.gbl...
           Sorry, more info:

           If I run in the debugger, breaking at the exception show no source and no disassembler.  Running www.sysinternals.com FileMon doesn't show any strange DLL's being requested.  Performing a CreateDomain with the CurrentDomain.Evidence and CurrentDomain.AppDomainSetup doesn't help either.  Using CLRSpy just shows a loada pinvoke calls to ReadFile and that is about it.

           Hence kinda lost as the why the code runs ok in the default domain, but not in a created domain

           Later

             "Matt Davey" <matt.davey@finetix.com> wrote in message news:O91GbHDtDHA.1088@tk2msftngp13.phx.gbl...
             If I run some code in the default domain of a console applicaiton, all works fine, if I create a new domain:

             AppDomain newDomain = AppDomain.CreateDomain("New"+FriendlyName)
             And run the same code, I get:

             Unhandled Exception: System.DllNotFoundException: Exception from HRESULT: 0x80131524

             But no stack trace and no idea what it can't find.  Any ideas or help would be useful

             later