Take the 2-minute tour ×

I am using DllImport to access some functions in a C++ dll from my C# application.

This code works fine on my dev laptop, which is Windows 7 64bit, the dll itself is 32 bit, so I run the process hosting the dll in 32bit and it works well. However when I try to run the exact same process on my target machine, which is again, Windows 7 64bit Ultimate i get the error 'Invalid access to memory location.' from the process.

I'm not sure what the problem is, i've looked at loads of resources on the net and none of them have solved it for me. I dont understand why it works fine on my dev box, but not on the target?

The dll itself is fine, the examples that come with the dll all work fine on my target box (which are C# apps doing DllImport).

Has anyone else had this problem? Been fighting it for two days now!

Exception: {"Unable to load DLL 'CLEyeMulticam.dll': Invalid access to memory location. (Exception from HRESULT: 0x800703E6)"}

share|improve this question
DEP is as OptIn (which is basically DEP Enabled) on my development box. But this has zero problems... I've been trying to find any differences but I set both machines up with the same ISO, both with VS2010, Robotics Framework RC3, and the same Dll i'm trying to access. But try as I might I cannot get this new machine to get robotics framework reading the dll properly!! –  James Jul 25 '10 at 15:26
I have also tried formatting the machine totally afresh, still have the same issue. –  James Jul 25 '10 at 15:47
Can you run with unmanaged debugging enabled (or use an unmanaged debugger like WinDbg) and find out more about where it's actually crashing? –  Will Dean Jul 28 '10 at 7:55
I was not able to solve this issue. It only happened whilst using the dll in Microsoft Robots Studio. In the end I had to create a new application to host the dll, and communicate cross process via WCF named pipes :( –  James Sep 1 '10 at 19:01
add comment

10 Answers

The DLL loading may crash because of unresolved dependencies, so open your DLL on target machine using Dependency Walker and see is there any problems.

share|improve this answer
dependencywalker.com –  Merlyn Morgan-Graham Jul 31 '10 at 6:42
add comment

I notice one big difference between your dev machine and your target machine, the dev environment. Make sure you have all the necessary redistributables on the target machine.

Edit: I have seen similar issues when some dlls were compiled to different versions of the .Net framework or if they were made with different versions of Visual Studio, as the redistributables for each version are different and the latest redistributables are not exactly backwards compatible.

share|improve this answer
add comment

I had the same problem here Native loading works good. Loading from .net gives error Unable to load DLL 'my.dll': Invalid access to memory location.

The problem was in DEP feature. When I switched on DEP for essential programs only, it gave no effect. But when I completely switched off DEP, and rebooted my server, error has gone. The one more thing I've done - installed latest updates for .net 4.0

The one notable thing - i didn't see any errors about DEP, just closing with "memory" error.

share|improve this answer
add comment

I've had this issue before. I think your problem is with VS trying to open the file but not having permissions to read it. You need to make sure the account you're using has access to the DLL. Try disabling UAC to see if it works, or use an Administrator account. Or try giving Full Control on the DLL to Everyone.

EDIT: Could you run VS as administrator (right click -> Run As Administrator)? Could you put the DLL onto your desktop to try? Is there a folder structure difference between your working computer and the one that's failing? Also, can the DLL run fine if you execute it outside of VS (try running it as admin as well)?


share|improve this answer
Thanks for your post. I've already done the following: Log in as Administrator account. Turn off UAC via the slider in the User Settings menu. Disable DEP by 'bcdedit.exe /set {current} nx AlwaysOff' Disabled DEP in my BIOS settings for my CPU. Given Full Control on entire folder structure to Everyone. Nothing works for this process - it works PERFECTLY for normal .NET applications. I think it might be something about the way DSS loads the assemblies after its started, when then try and load the unmanaged dll? I dont know... But thanks anyway. –  James Jul 25 '10 at 14:47
@James - See my edit above. –  TheCloudlessSky Jul 25 '10 at 15:04
Yes the folders are the same. The process I am trying to run is called DssHost.exe, part of the Microsoft Robotics Studio. It is in C:\Robotics\Bin\DssHost.exe along with my dll 'CLEyeMulticam.dll' (this is the same on both computers.) DssHost takes the .NET dll (PS3WebcamService.dll) I write in VS (deployed to C:\Robotics\Bin\, loads it with DssHost, and runs it. Only on my original dev box does this work, other new box complains about this above error. However my dev box has DEP turned on? (But UAC turned off.) Continued.... –  James Jul 25 '10 at 15:50
If I try to run same code that is in my .NET dll through a seperate .NET Windows Form application, it works properly on both computers. I do not understand what the difference is between my .NET windows application, and the .net DssHost which hosts the Service dlls, and why it is only affecting this second machine. Ps - Naughty I know, but I always run VS as Administrator. Starting DssHost from an Admin Cmd line gives me the same error. Thanks for your help :) –  James Jul 25 '10 at 15:52
I'm honestly stumped on this. Hope someone else can give you some insight! –  TheCloudlessSky Jul 25 '10 at 16:10
show 2 more comments

I have had similar problems before, try the following.

  • Check the .NET CLR version. Are there any SPs/KBs present in your target that is not in your dev?
  • Try loading the debug version of the C++ DLL. Are you able to load it? If it fails, I'd suggest starting your app under WinDBG in your target. Once the exception is hit, a simply !analyze -v will give you lots of info.
  • As a next step, I'd try to reproduce this issue in a unit test environment. Are the C# samples you mentioned built for x64 VM? If not, try doing that and try running the resulting sample binary in your target. Is the issue reproducible?
share|improve this answer
add comment

I have encountered a problem with a 64bit .NET app ("Any CPU") trying to load a 32bit native DLL dependency. I don't have the error message in front of me, so I can't tell you if it is the same problem. The solution for my problem was to change my build to x86-only.

If the bit size of the DLL is changing on each box, maybe there are structure size differences, so your PInvoke signature becomes incorrect. This could easily cause a buffer overrun, and cause stack corruption in the native code.

share|improve this answer
add comment

If you're getting the error in your C# app, this message often indicates the native code did something nasty to memory that the ILM can see - check the code in/called by your DllMain routine - that is called before your call actually goes thru - if it's misbehaving, you'd see this result

share|improve this answer
add comment

@Merlyn Morgan-Graham We faced a similar problem. Where we built the .Net application with "Any CPU" build and tried using with 32 bit C++ Dll. When we run the .Net Application in 64 bit OS. It runs as 64 bit executable and hence and got similar issue. After buidling in X86 Loading, Calls to C++ Dlls worked absolutely fine. One more important thing is if you are using C++ DLL in your .Net code. There would be fair amount of marshalling, so it is important to stick to the build type (i.e. X86, any CPU or X64).

Please check the following link also: http://stackoverflow.com/questions/29284/windows-vista-unable-to-load-dll-x-dll-invalid-access-to-memory-location-dl

share|improve this answer
add comment

The obvious, but probably lame solution would be to build C# side explicitly for 32-bit. Check how do you create out of proc host - programatically or by populating registry keys or ... could be that on other box it gets set up to either make 64-bit hosting process or attempt in-proc invocation, which means loading ... It it's a registry setting don't forget that for mixed 23/64 bit cases there are two branches to dig into.

share|improve this answer
add comment

I ran into a similar issue when I moved to win7. You might need to set your (64 bit) machine to run as a 32bit one by-default, using the below command:

C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe setwow

Ref: http://social.msdn.microsoft.com/Forums/en/phoenix/thread/9a43e9a1-a744-4a1a-bb34-3604254c126b

share|improve this answer
add comment

Your Answer


