3

I'm using Microsoft Visual Studio Express 2012 for Windows Desktop (Administrator)

I have a project library FOO.DLL with "Copy to output directory" clicked to "Copy always".

Most of the time this DLL loads correctly and everybody is happy.

Sometimes, I get a System.DllNotFoundException with message:

Additional information: Unable to load DLL 'FOO.DLL': 
Invalid access to memory location. (Exception from HRESULT: 0x800703E6)

This error occurs both in Debug and Release. It occurs after a "clean" and after just running the same build a second or eighth time.

Is this an error in the DLL, the .NET runtime, or my .NET code?

Cuadue
  • 3,769
  • 3
  • 24
  • 38
  • I can't say this for sure, hence why it is only a comment. But this sounds like the sort of thing that will be resolved once your app is deployed. It *feels* more like a problem with the build process. – Gray Oct 04 '13 at 16:55
  • Is foo.dll managed or unmanaged? Also see http://stackoverflow.com/questions/5375675/native-loading-works-good-loading-from-net-gives-error-unable-to-load-dll-my?rq=1 – Anton Tykhyy Oct 04 '13 at 17:04
  • @Gray There's no "deployment process" for this project. It's just a few thousand lines which produces an EXE, along with the aforementioned DLL. – Cuadue Oct 04 '13 at 17:24
  • @AntonTykhyy This is an unmanaged DLL. Sometimes it works, sometimes it doesn't. I never see any DEP dialog, even when it does work. – Cuadue Oct 04 '13 at 17:27
  • @Cuadue What I meant was that once the project is distributed/running standalone/outside of Visual Studio, I'd think it would be fine. – Gray Oct 04 '13 at 17:38

2 Answers2

4

Invalid access to memory location. (Exception from HRESULT: 0x800703E6)

This error code is returned when code inside that DLL fails with an AccessViolation. Special code, run at a very critical time during DLL loading. The bad code is located in the DllMain() entrypoint of the DLL. That exception is swallowed, necessary to keep the Windows loader stable and all you see is the error code that it produces.

This is a very serious mishap and you'll need to work with the author of the DLL to get this problem resolved. You can debug the exception, use Debug + Exceptions, tick the Thrown checkbox for Win32 Exceptions. Make sure that Just My Code debugging is turned off, Tools + Options, Debugging, General. Enable unmanaged debugging, Project + Properties, Debug tab. The debugger stops when the exception is thrown. If you don't have the source code for the DLL then there's little to look at and nothing you can do to fix the problem, that requires help from the author. He will want the content of the Stack Trace window to have a shot at fixing the problem.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    Excellent explanation to the problem. However i'm experiencing the same issue as OP on different projects and this appears randomly on (usually) the same DLL, one build it works , 5 minutes later it doesn't. any ideas on that ? – Nikola Sivkov Oct 04 '13 at 18:32
0

Visual Studio is not very good at keeping track of these dependencies from one project to the next. If your project (that includes the FOO.DLL) is later included in another project I suspect that Visual Studio will not always have this extra file carried properly to the top level project.

I`ve had to create a small MSBuild task to scrub the content of a project so these files are carried over properly (and deleted on clean). That said our project layout was a tad bit on the unorthodox complex side of things YMMV.

Long story short that would be the first place I look into and make sure the file follows, shortest (though not cleanest) mean to this is to add the FOO.DLL again to projects where the original project that needs it is included. Works well on small structure, for larger project structure I would look into MSBuild Task or perhaps a packaging deployement solution (a la Nuget).

Hope this helps

Newtopian
  • 7,543
  • 4
  • 48
  • 71
  • Well, there's only one project in this solution. I can't see how adding the file again would do anything, as it's just an entry in an XML file, which looks clean to me. I've tried a fresh checkout from version control (no obj, bin folders, suo, user files) with the same result. – Cuadue Oct 04 '13 at 17:28