BadImageFormatException building C++ .dll in Server 2012 R2

Thurman, Allen 96

I have my own solution with 2 projects building in Visual Studio 2019. One is a C++ project and produces a C# wrapper .dll (mytest.dll). The other project is a C# test app that makes calls to the wrapper .dll. When running the test app on my Win 10 laptop, I can run without any problem

Testing on my build machine, which is Windows Server 2012 R2, I do this same process but trying to run my test app I get a runtime exception:

System.BadImageFormatException: 'Could not load file or assembly 'mytest.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)'

I'm guessing there's some SDK or something for C++ that I need to install. Hard to tell because I have a million SDKs and redists installed on my laptop. Or maybe a VS2019 setting?

Any ideas on what to check on the Windows Server machine?

Note:

Both machines have Visual Studio 2019 used to build

1 answer

Michael Taylor 48,826 Reputation points

2021-04-01T14:43:25.607+00:00

BadImageFormat doesn't indicate a missing dependency but a binary format issue. You are trying to load an x86 DLL in an x64 process or vice versa. That means that your process for building the DLL is incorrect. If you need to host the generated DLL in an x86 process then you need to ensure you build the DLL as either Any CPU or x86. For x64 processes use Any CPU or x64. For a true .NET DLL then the recommendation is to use Any CPU so it works with either process.
Please sign in to rate this answer.
Thurman, Allen 96 Reputation points

2021-04-01T14:59:54.48+00:00

I'm using the same build process that I use on my Win 10 laptop (x64). I have also tried it building using MsBuild from the command line (where you specifically denote x64). Since it builds and runs fine on my laptop it does NOT seem to be the build process, but maybe the build ENVIRONMENT. Something is different in the Server 2012 environment

Michael Taylor 48,826 Reputation points

2021-04-01T15:07:06.51+00:00

The target platform is specified as a parameter to the MSBuild tool. The build environment doesn't matter for .NET as target platform is a parameter to the tools.

Please clarify the following:

What is the bitness of the process that will be attempting to load the DLL you generated?

What is the command line you are using to build the DLL in your C++ app?

Open the generated DLL in ILDASM or Just Decompile or similar. What bitness does it show?

Thurman, Allen 96 Reputation points

2021-04-01T20:10:00.013+00:00

64 bit

Msbuild /t:Build /p:Configuration=Debug;Platform=x64; (also tried building directly in visual studio --> devenv)

Corflags output:

Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.8.3928.0
Copyright (c) Microsoft Corporation. All rights reserved.

Version : v4.0.30319
CLR Header: 2.5
PE : PE32+
CorFlags : 0x10
ILONLY : 0
32BITREQ : 0
32BITPREF : 0
Signed : 0

Michael Taylor 48,826 Reputation points

2021-04-01T21:22:38.663+00:00

The C# DLL is being compiled as x64 so it is only loadable in an x64 process. You said that you have a C# test app that you are running. I assume you are building the test app as x64 as well (ensuring that it isn't Any CPU with Prefer 32-bit set). You might want to corflags the test app as well. I am particularly interested in the corflags being set to 0x10 which means NativeEntryPoint. That seems, odd.

Assuming your x64 test app loads on the server 2012 machine then that eliminates any issues with dependencies as the .NET Framework would be installed correctly. However I am making an assumption here that your generated DLL doesn't itself have any dependencies outside the framework assemblies that might be causing issues. But at this point the runtime doesn't recognize the DLL as a valid PE binary that can be loaded. I'm assuming that you don't have a corrupt file here but maybe also verify the file wasn't corrupted getting it to the server.
Sign in to comment