System.BadImageFormatException

[Scott_M_]

My team has developed a .dll using Intel Parallel Studio XE for use in a larger application developed in Visual Studio 2012 (vb.net).  When attempting to run the program on TWO machines, both distinct from the development machine, upon making a call to the .dll we receive the error provided in the Subject.  Thinking that google would be my friend, I searched for the error, finding that most people who have experienced this issue have found that setting the application to target an x86 processor rather than "Any" or x64 resolved the issue.  This is not the case for our team.  Using corflags.exe reveals the application to be x86 targeted, and using dumpbin /headers shows that the (unmanaged) .dll is also x86 targeted.  Furthermore, it shows that both libifcoremd.dll and libmmd.dll, both dependencies of our "Dll1.dll" (name subject to change) are also x86 targeted.  Since everything in the chain appears to be x86 targeted, I am at a complete loss as to how I might solve this.  For reference, I have tested this with a test app which has a single button that calls the .dll, and nothing more.  No joy.

Suggestions?  Questions?

[SergeyKostrov]

You didn't provide information about target operating system on those TWO computers. The error message System.BadImageFormatException means that something is wrong with a PE Image ( Do Not be confused with Image Processing ). Try to use MS Depends to verify executables and DLLs.

[Scott_M_]

Sorry about that.  All computers involved are running Windows 7 Enterprise Edition.  I've used MS Depends already to find that our .dll has libifcoremd.dll and libmmd.dll as dependencies.  What should I be verifying with it besides that?

This "program" currently consists of an executable that loads a windows form with a button, which calls the .dll.  The error message associated with the exception is "An attempt was made to load a program with an incorrect format."  I'm struggling to see how it's related to the Windows Preinstallation Environment.

[SergeyKostrov]

>>...I've used MS Depends already to find that our .dll has libifcoremd.dll and libmmd.dll as dependencies... Your DLLs should have correct values consistent with version number ( see MSDN ) for Windows 7 Enterprise Edition operating system. Also, in MS Depends take a look at the following attributes: CPU Image Ver OS Ver Subsystem Ver

[Scott_M_]

Dll1.dll (our .dll file)
CPU:  x86
Image Ver:  0.0
OS Ver:  6.0
Subsystem Ver:  6.0

libmmd.dll (Intel .dll)
CPU:  x64
Image Ver:  0.0
OS Ver:  5.2
Subsystem Ver:  5.2

libifcoremd.dll (Intel .dll)
CPU:  x64
Image Ver:  13.1
OS Ver:  5.2
Subsystem Ver:  5.2

Interesting.  I built it as a Win32 .dll; why would it include dependencies to x64-based .dll's?  Since they're unmanaged, I can't edit them with corflags.exe; how can I resolve that?

Edit:  I found and installed some redistributable libraries and am now getting an error related to the fact that I'm passing essentially no real data to the .dll.  I'm going to attempt it in the actual application as soon as possible.  It might be nice if the documentation for the development tool had included information about including redistributables.

[SergeyKostrov]

>>Dll1.dll (our .dll file) >>CPU: x86 >>Image Ver: 0.0 >>OS Ver: 6.0 >>Subsystem Ver: 6.0 I think your DLL should have 5.2. Here are two examples: [ Example 1 ] ... #ifndef _WIN32_WINNT // Allow use of features specific to Windows XP or later #define _WIN32_WINNT 0x0501 // Change this to the appropriate value to target other versions of Windows #endif ... Note: Windows XP operating systems are targeted. [ Example 2 ] ... #ifndef _WIN32_WINNT // Allow use of features specific to Windows 2003 Server or later #define _WIN32_WINNT 0x0502 // Change this to the appropriate value to target other versions of Windows #endif ... Note: Windows 2003 Server operating systems are targeted.

[SergeyKostrov]

>>...I can't edit them with corflags.exe; how can I resolve that? MS EditBin.exe utility allows to change attributes of PE Image. Try to use it and change Subsystem Ver from 6.0 to 5.2.

[SergeyKostrov]

Another way to workaround the problem is to create a .NET executable with exactly the same version numbers as in your DLL. If you try to execute that executable on the target platform you should see a "...Not a valid Win32 application..." error message. Then, you will need to change versions to correct values for the target platform and your test executable should start working. The same modifications need to be use for the DLL.

[SergeyKostrov]

>>...If you try to execute that executable on the target platform you should see a "...Not a valid Win32 application..." >>error message... I also recommend you to look at Microsoft recommendations on MSDN for the error and there are lots of technical details there.

[Scott_M_]

Sergey Kostrov wrote:

...
#ifndef
... 

Since I'm coding in vb.net (as mentioned in my op), C commands won't help me.  Furthermore, installing the redistributables solved the System.BadImageFormatException.  Now I'm stuck with an error in Dependency Walker:

"Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module."

The only module in error is IESHIMS.DLL, which is delay-loaded, and thus shouldn't cause any problems...

When I run the test program (with just the button to call the .dll), it gives the error message in Error.png attached to this message.  When I run the actual application we're developing it tells me that it cannot find a module and gives Dll1.dll as the file in error, which from what I understand means it could be any dependency of Dll1.dll.

[SergeyKostrov]

>>...Fortrtl: severe ( 43 )... Do you have any Fortran modules?

[Scott_M_]

The .dll is written in Fortran and compiled with Intel Visual Fortran Composer XE 2013.

[Scott_M_]

For posterity, the problem has been solved for the x86 version of this software.  The solution was as follows:

1. Install redistributables on target machine (bundle with installer package as merge modules for deployment)
2. Use Dependency Walker to find missing .dll's (IEShims.dll, gpsvc.dll, sysntfy.dll in our case), then find them somewhere (google worked for our team)
3. Bundle .dll used in application with all necessary supporting libraries and either update PATH variable of Environment Variables in Windows or simply place them all together in the same directory during package installation
4. Enjoy the proper operation of your software

Thanks for the brainstorming sessions Sergey, I appreciate your quick attention.

[SergeyKostrov]

>>...For posterity, the problem has been solved for the x86 version of this software... Hi Scott, Thanks for the follow up and I'm glad to know that the problem is solved.

[Bernard]

Usually in case of unresolved import/exports the best option is to use loader snaps provided by windbg as dependency walker sometimes is not responsive.