I received a Matlab Compiled .dll (targeted for a 32 bit (x86) system). I use a 64 bit system with Windows 7 on it. I am using Visual Studio IDE for making my application and import this .dll. Below is the Code.
[DllImport("Generate_Curve.dll", CallingConvention = CallingConvention.Cdecl, EntryPoint = "Generate_Curve", CharSet = CharSet.Ansi)]
I have seen a similar question .net Framework Error (HRESULT 0x8007000B) so I tried to change the Platform Target to x86 or Any CPU coupled with Prefer 32-bit. Still there is an Error thrown An unhandled exception of type 'System.BadImageFormatException with Additional Information as An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B). Can any one point out something that I have missed.
I received the answer from Matlab (Mathworks) that there is a bug in Matlab Compiler. If one compiles from a 64 bit Matlab in Matlab Coder for a target machine or application of 32 bit the .dll generated is highly likely to be corrupted. The solution is to compile a dll for 32bit target machine/application using a 32 bit Matlab (Matlab Coder). This issue is more of a Matlab Coder issue.
Related
Creating an Excel addin using an SDK from a 3rd party. The SDK contains a native code DLL (in both 32 and 64 bit versions). My addin code is in C# and it appears that addins only run if compiled under "AnyCPU" option.
When I attempt to run the app I get "An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)" which usually means a 64/32 mismatch, and the error is from attempting to load the 3rd party native code DLL.
My question is: are my assumptions correct about AnyCPU and is there a way to run native code DLL's from an addin compiled under AnyCPU? Thanks!
before .net 4.5 the AnyCPU depends on your current compile machine.
if your machine is 32bit CPU, AnyCPU will compile your program as 32bit program. if it's 64bit CPU, i t will compile as 64bits.
after .net 4.5, the AnyCPU changed:
If the process runs on a 32-bit Windows system, it runs as a 32-bit
process. IL is compiled to x86 machine code.
If the process runs on
a 64-bit Windows system, it runs as a 32-bit process. IL is compiled
to x86 machine code.
If the process runs on an ARM Windows system,
it runs as a 32-bit process. IL is compiled to ARM machine code.
If you want your program can run both 32bit and 64bit cpu, you should link your native code DLL with 32 bit version, otherwise you need to compile them in separate CPUs
Yes it is possible, you can create some wrappers functions that redirect the call to the native dll depending on the current architecture , example :
[DllImport("bin32\\Native86Dll", EntryPoint = "MyFunc", CharSet = CharSet.Ansi, ExactSpelling = true)]
public static extern int MyFunc_32(string sCommand);
[DllImport("bin64\\Native64Dll", EntryPoint = "MyFunc", CharSet = CharSet.Ansi, ExactSpelling = true)]
public static extern int MyFunc_64(string sCommand);
public static int MyFunc(string sCommand )
{
return System.Environment.Is64BitProcess ? MyFunc_64(sCommand) : MyFunc_32(sCommand);
}
I am attempting to update the lock screen background like this:
string filename = #"C:\app\screenshot.temp.jpg";
string finalLocation = #"C:\Windows\System32\oobe\info\backgrounds\backgroundDefault.jpg";
File.Move(filename, finalLocation);
Unfortunately this throws a System.IO.DirectoryNotFoundException exception:
An unhandled exception of type 'System.IO.DirectoryNotFoundException' occurred in mscorlib.dll
Additional information: Could not find a part of the path.
However when i browse to C:\Windows\System32\oobe\info\backgrounds in Windows Explorer, CMD, or Powershell it does exist. I also have the security to write, rename, and delete files in that location (and the C# process is running in my context). What is going on?
If you've encountered this, I am guessing you're executing the process on a 64 bit version of Windows.
Background:
On Windows 32 bit, there is a single System32 folder called "System32" that stores all 32 bit DLLs. On Windows 64 bit, there are two "System32" folders one still called System32 and another called SysWOW64.
These two folders store the opposite of what their names imply:
System32 stores 64 bit DLLs.
SysWOW64 stores 32 bit DLLs.
SysWOW64 stands for "Windows 32-bit on Windows 64-bit." So it is a folder that exists for backwards compatibility with 32 bit for 32 bit processes.
Why this breaks things?
Microsoft are obsessed with backwards compatibility, so when they added 32 bit emulation on 64 bit Windows, they wanted to make the bitness of the system invisible to the 32 bit processes running, and they introduced a bunch of compatibility shims (fixes).
One of these shims redirects IO requests for %WINDIR%\System32 to %WINDIR%\SysWOW64 for processes running in 32 bit mode only.
So when you request a move from:
C:\Windows\System32\oobe\info\backgrounds\backgroundDefault.jpg
Windows may actually instead request the move from:
C:\Windows\SysWOW64\oobe\info\backgrounds\backgroundDefault.jpg
Which does not exist. Thus explaining the error you're seeing.
The Fix
The easiest fix is to change your program to build as a 64 bit process. You can do this by:
Right Click on the Project -> Properties -> Build [Tab] -> Platform target -> x64
Now when you run, requests against %WINDIR%\System32 should actually hit %WINDIR%\System32 for real.
Alternatively if you need to run your process in 32 bit mode (e.g. due to library compatibility) you can ask Windows to disable the shim like this:
[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool Wow64DisableWow64FsRedirection(ref IntPtr ptr);
private static void Main(string[] args)
{
IntPtr ptr = new IntPtr();
bool isWow64FsRedirectionDisabled = Wow64DisableWow64FsRedirection(ref ptr);
}
In either case requests should be handled more literally by the operating system, and you can update the lock screen background (or any other operation in System32).
How can I use 32 dll for AnyCpu(x64). Error :
Retrieving the COM class factory for component with CLSID
{E187099F-8C5C-4723-8866-D8DBB6353ADE} failed due to the following
error: 80040153 Invalid value for registry (Exception from HRESULT:
0x80040153 (REGDB_E_INVALIDVALUE))
Is there a solution for this?
Quick answer: No. You cannot use 32bit dlls in an 64bit application.
A workaround would be to create a 32bit application, that uses the 32bit dll and then communicates with your 64bit application via IPC or something similar.
app was complied on windows7, .net4.0
i put the dll: TECIT.TFORMer.dll in the app file
test-pc,i386:
server-pc,amd64:
on test-pc,i debug the app, and got the resut, log:
but on server-pc, throw exception, log:
why test-pc app :DllImport attempting to load: 'libTFORMer6.so'
but server-pc app never show the log?
thanks.
If your mono is 64 bit, you can not load a 32 bit library into it.
While the OS usually supports running 32 bit code, it applies to the whole process.
So you should either make a 64 bit library or run 32 bit mono.
Disclaimer: your question wasn't quite clear whether you are trying to use the same library on both systems.
I'm trying to interop with the ImageMagick library in Mono on a Mac. I installed the ImageMagick library with MacPorts and have verified that the file libMagickWand.dylib exists in the directory /opt/local/lib. I've also created a soft link to that file in the directory /usr/local/lib.
Here's my DllImport statement:
[DllImport("libMagickWand", EntryPoint = "MagickWandGenesis")]
static extern void WandGenesis();
Here's my App.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<dllmap dll="libMagickWand" target="/opt/local/lib/libMagickWand.dylib" />
</configuration>
And, at the call to WandGenesis();, I get a DllNotFoundException, with the message 'libMagickWand'.
I've read this page and I think I'm following all the rules. Is there anything else I can try?
Update:
I ran the .exe with MONO_LOG_LEVEL=debug. Here is the pertinent information:
Mono: DllImport error loading library 'dlopen(/opt/local/lib/libMagickWand.5.dylib, 9):
no suitable image found.
Did find: /opt/local/lib/libMagickWand.5.dylib: mach-o, but wrong architecture'.
wrong architecture: I'm running Snow Leopard in 32-bit mode and always have. I installed ImageMagick with MacPorts, and I installed Mono with the Mac package from mono-project.com. What would have been compiled with a different architecture?
Update:
I think I found my problem:
MacBook-Pro:lib ken$ lipo -info libMagickWand.5.dylib
Non-fat file: libMagickWand.5.dylib is architecture: x86_64
Update:
...but I'm still having issues. I can't seem to figure out how to compile ImageMagick with i386 architecture. When I try to do so using flags, it complains about other libraries that were compiled as 64-bit.
Update:
Mono on Mac OS X is 32 bit (at least usually, you can confirm that with mono --version) and you are trying to link with 64bit binary which is not possible. You have to provide 32-bit binary (or use 64-bit Mono).
Do you have the error even when only the library's file name is in the target and the library is placed appropriately (or the DYLD_LIBRARY_PATH set)? In such case please provide the output of mono executed with MONO_LOG_LEVEL=debug.