Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

312 views
Skip to first unread message

Matt Davey

unread,
Nov 26, 2003, 10:32:41 AM11/26/03
to
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

Matt Davey

unread,
Nov 26, 2003, 10:41:23 AM11/26/03
to
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
 

Sebastien Lambla

unread,
Nov 26, 2003, 10:38:26 AM11/26/03
to
Maybe with a definition of "some code" we might be able to help. also notice that the DllNotFoundException just means the fusion loader didn't find the dlls you were referencing, like other projects you reference in your solution. You have to configure the new appdomain to probe for the dlls.
 
 
"Matt Davey" <matt....@finetix.com> a écrit dans le message de news: O91GbHDt...@tk2msftngp13.phx.gbl...

Matt Davey

unread,
Nov 26, 2003, 11:07:54 AM11/26/03
to
We have a managed C++ wrapper over TIBCO RV that is used by C#.  When the code is run in the newly created domain, everything works fine, apart from when we get a message off the RV, and hence some code deep inside the RV Dll's is called because it was probably waiting on a socket or something.  Anyway at this point we appear to get the exception. 
 
Sample code is difficult to send, since there is a lot of it, and even a simple 5 line same requires the RV wrapper etc
 
Do U mean do a AddAssembly to the evidence for all assemblies ?  Currently I don't do an AddAssembly, but everything in the app work fine from the 10 or so assemblies it uses, apart from the above problem.
 
Running in the default domain as I said, everything works fine. 
 
Thanks for the reply
 
Later
 
 
"Sebastien Lambla" <sebastie...@6sens.com> wrote in message news:OYlmYNDt...@TK2MSFTNGP10.phx.gbl...

Matt Davey

unread,
Nov 27, 2003, 9:13:44 AM11/27/03
to
Additionally, the fusionvw.exe shows no errors - even when I force logging by setting ForceLog=1 in the registry
 
Later

Sebastien Lambla

unread,
Nov 27, 2003, 10:54:58 AM11/27/03
to
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.
 
 
"Matt Davey" <matt....@finetix.com> a écrit dans le message de news: uhichMDt...@TK2MSFTNGP11.phx.gbl...

Matt Davey

unread,
Nov 27, 2003, 11:49:23 AM11/27/03
to
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" <sebastie...@6sens.com> wrote in message news:u9f5S7Pt...@TK2MSFTNGP10.phx.gbl...

Matt Davey

unread,
Nov 27, 2003, 12:55:29 PM11/27/03
to
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

Conrad Zhang

unread,
Nov 27, 2003, 8:06:49 PM11/27/03
to
Be sure to read Suzanne's blog before asking. It is probably already
answered there.

http://blogs.gotdotnet.com/suzcook/

"Matt Davey" <matt....@finetix.com> wrote in message
news:O91GbHDt...@tk2msftngp13.phx.gbl...

Matt Davey

unread,
Nov 28, 2003, 12:55:17 AM11/28/03
to
Read it, and no its not answered as far as I can see

Later

"Conrad Zhang" <Conrad_zhang AT Yahoo DOT com> wrote in message
news:uPS$nvUtDH...@TK2MSFTNGP11.phx.gbl...

Dave

unread,
Nov 28, 2003, 5:36:00 AM11/28/03
to
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

unread,
Nov 28, 2003, 6:03:13 AM11/28/03
to
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
 

Matt Davey

unread,
Nov 28, 2003, 6:07:28 AM11/28/03
to
Sorry, the GCHandle exception is a red herring, the real issue is further up the call stack
 
later
 
0 new messages