Using own .dll in 64 bit version system - exception: ""BadImageFormatException was unhandled""
-
I am trying to use any DLL in Windows 7 64 bit version. It give me exception "BadImageFormatException was unhandled". The same .dll works fine with Windows XP. The .dll was written in ASM and built using AnyCPU platform. Here is the call in project:
[DllImport("library.dll")] static extern bool MyFunction(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
Anyone has come across it, is there a way to resolve it? Best regards.
-
I am trying to use any DLL in Windows 7 64 bit version. It give me exception "BadImageFormatException was unhandled". The same .dll works fine with Windows XP. The .dll was written in ASM and built using AnyCPU platform. Here is the call in project:
[DllImport("library.dll")] static extern bool MyFunction(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
Anyone has come across it, is there a way to resolve it? Best regards.
Here are some facts relating to 32/64 bit code: 1. When you build a native-code DLL, you must decide whether you want it to use the 32-bit or the 64-bit architecture, which are both supported by most modern Intel/AMD processors. 2. When you build a managed code DLL or EXE, you can choose between 32-bit, 64-bit, or automatic ("AnyCPU"). With 32-bit or 64-bit, it is the EXE itself that enforces the execution mode; with "AnyCPU" the EXE will run in 32-bit execution on 32-bit Windows, and in 64-bit execution on 64-bit Windows. 3. And you can't mix 32-bit and 64-bit code in a single process, Windows simply doesn't allow a mode switch in mid execution, so the DLLs must match the EXE's mode (AnyCPU DLLs are always fine, the other managed ones and all unmanaged ones must match). Assembly code is native code obviously, and 64-bit and 32-bit assembly source files look quite different, as the programming model is not the same at all. So I guess your "ASM DLL" really is a 32-bit beast, notwithstanding the fact that you created it on a 64-bit Win7 system. So you could use your 32-bit native DLL, and use it on any 32-bit operating system (with a managed EXE built for x86 or for AnyCPU); or use it on a 64-bit OS with a managed EXE built for x86 (but not for "AnyCPU" as that would start in 64-bit mode and then fail to reference the DLL code). In practice, you could simply rebuild the app (the EXE part should suffice) for x86, see the project properties. There also is a hack using CORFLAGS, which basically would alter the properties of an existing EXE file (not recommended when you have the source code anyhow). :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
modified on Saturday, April 30, 2011 5:16 PM
-
Here are some facts relating to 32/64 bit code: 1. When you build a native-code DLL, you must decide whether you want it to use the 32-bit or the 64-bit architecture, which are both supported by most modern Intel/AMD processors. 2. When you build a managed code DLL or EXE, you can choose between 32-bit, 64-bit, or automatic ("AnyCPU"). With 32-bit or 64-bit, it is the EXE itself that enforces the execution mode; with "AnyCPU" the EXE will run in 32-bit execution on 32-bit Windows, and in 64-bit execution on 64-bit Windows. 3. And you can't mix 32-bit and 64-bit code in a single process, Windows simply doesn't allow a mode switch in mid execution, so the DLLs must match the EXE's mode (AnyCPU DLLs are always fine, the other managed ones and all unmanaged ones must match). Assembly code is native code obviously, and 64-bit and 32-bit assembly source files look quite different, as the programming model is not the same at all. So I guess your "ASM DLL" really is a 32-bit beast, notwithstanding the fact that you created it on a 64-bit Win7 system. So you could use your 32-bit native DLL, and use it on any 32-bit operating system (with a managed EXE built for x86 or for AnyCPU); or use it on a 64-bit OS with a managed EXE built for x86 (but not for "AnyCPU" as that would start in 64-bit mode and then fail to reference the DLL code). In practice, you could simply rebuild the app (the EXE part should suffice) for x86, see the project properties. There also is a hack using CORFLAGS, which basically would alter the properties of an existing EXE file (not recommended when you have the source code anyhow). :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
modified on Saturday, April 30, 2011 5:16 PM
I tried to build my project as "AnyCPU", x86 and 64 bit, results are always the same: "BadImageFormatException was unhandled". According to the guideline, I used CORFLAGS. After call: CorFlags.exe library.dll I have:
Error CF008 : The specified file does not have a valid managed header.
-
I am trying to use any DLL in Windows 7 64 bit version. It give me exception "BadImageFormatException was unhandled". The same .dll works fine with Windows XP. The .dll was written in ASM and built using AnyCPU platform. Here is the call in project:
[DllImport("library.dll")] static extern bool MyFunction(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
Anyone has come across it, is there a way to resolve it? Best regards.
-
The compiler is expecting a managed library: did you add the library.dll to your project references? You should not do that if the library is native (non managed), the DllImport line should suffice.
-
The error message sometimes can be misleading, in fact it can also be raised if the loaded dll cannot find another library that it depends on. How is the ASM library compiled?
-
I think in Visual Studio. I don't know details, it's my friend's library, I didn't create it.
Where did you put the library? it should be in a folder that is listed in the PATH environment variable. As it probably is a 32-bit dll, it should NOT be put in C:\Windows\System32 (which is used only by 64-bit apps), Windows is confusing here, C:\Windows\SysWOW64 (which is used only by 32-bit apps) would be good though. Same applies to all dependencies of your dll file, if any. :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
Where did you put the library? it should be in a folder that is listed in the PATH environment variable. As it probably is a 32-bit dll, it should NOT be put in C:\Windows\System32 (which is used only by 64-bit apps), Windows is confusing here, C:\Windows\SysWOW64 (which is used only by 32-bit apps) would be good though. Same applies to all dependencies of your dll file, if any. :)
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.