Runtime: BadImageFormatException when loading C++/CLI DLLs in Core 3.1

[TravisRidge]

Operating System Version: Azure virtual machine with a Windows 10 Pro, Version 1809 base
.NET Core Version: 3.1
Visual Studio Version: 16.4.3 and 16.4.4

Whenever I attempt to access a C++/CLI project (targeted for .NET Core 3.1) from a C# project, the execution will immediately crash when attempting to load the assembly.

I have managed to reproduce this error in multiple independent solutions, on multiple computers, so it does not appear to be tied to a code- or computer-specific issue on my end.

If the project is executed in Visual Studio with the debugger, the debugger itself appears crash upon reaching the method which calls the C++/CLI DLL. No information will be provided in Debug other than these lines:

The program '[13640] NET Core CLI Test.exe: Program Trace' has exited with code 0 (0x0).
The program '[13640] NET Core CLI Test.exe' has exited with code -529697949 (0xe06d7363) 'Microsoft C++ Exception'.

As a curious note, the debugger also skips over the calling method if I attempt to step into it, reporting it as "non-user code".

If executed without a debugger, more information is provided when the crash occurs:

Unhandled exception. System.BadImageFormatException: Could not load file or assembly 'Mock CLI Project, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. An attempt was made to load a program with an incorrect format.
File name: 'Mock CLI Project, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
at NET_Core_CLI_Test.Program.CallingMethod(Int32 a, Int32 b)
at NET_Core_CLI_Test.Program.Main(String[] args) in C:\Users\travis.ridge\source\repos\NET Core CLI Test\NET Core CLI Test\Program.cs:line 11

In both situations, an error will be added to the Windows event log, displaying the same basic information each time.

Faulting application name: NET Core CLI Test.exe, version: 1.0.0.0, time stamp: 0x5dedc13b
Faulting module name: KERNELBASE.dll, version: 10.0.17763.914, time stamp: 0xfb6790ac
Exception code: 0xe0434352
Fault offset: 0x0000000000039159
Faulting process id: 0x31e0
Faulting application start time: 0x01d5d8549d80476e
Faulting application path: C:\Users\travis.ridge\source\repos\NET Core CLI Test\NET Core CLI Test\bin\x64\Debug\netcoreapp3.1\NET Core CLI Test.exe
Faulting module path: C:\windows\System32\KERNELBASE.dll
Report Id: 575a2b9a-1f69-4d48-8d07-ac8dfe6917d4
Faulting package full name:
Faulting package-relative application ID:

Below I've included the code example from a minimal solution in Visual Studio with which I am able to consistently reproduce this issue.

Example C# script. The program crashes when CallingMethod() is invoked.

using CLI;

namespace NET_Core_CLI_Test
{
    class Program
    {
        static void Main(string[] args)
        {
            int a = 2;
            int b = 2;
            int sum = CallingMethod(a, b); //Crash occurs when executing this line
        }

        static int CallingMethod(int a, int b)
        {
            //Execution never reaches here
            MockWrapper wrapper = new MockWrapper();
            return wrapper.Add(a, b);
        }
    }
}

The ModelWrapper.cpp class:

#pragma once
#include "pch.h"
#include "MockWrapper.h"

#include <exception>

using namespace System;
using namespace System::Runtime::InteropServices;

namespace CLI {
    MockWrapper::MockWrapper() {

    }

    int MockWrapper::Add(int a, int b) {
        return a + b;
    }
}

I can provide further information upon request.

[scalablecory]

@jeffschwMSFT

[scalablecory]

Are you trying to load a 64-bit DLL inside a 32-bit process, or vice-versa?

[vcsjones]

Perhaps related to #521.

[TravisRidge]

Are you trying to load a 64-bit DLL inside a 32-bit process, or vice-versa?

In my solutions all projects were being built in the 64-bit configuration.

I've rechecked the test solution just to be sure: the C# project was set for x64 platform target, and the reference to the C++ project points to the x64 build. However the error persists.

[jeffschwMSFT]

@jkoritzinsky

[jkoritzinsky]

@TravisRidge do you have the ijwhost.dll deployed next to your C++/CLI assembly and are all of your native dependencies resolved/resolvable? Sometimes people miss that file when copying their outputs around.

Our diagnostics for mixed-mode assembly loading need a bit of work since they throw a BadImageFormatException for basically every failure.

[TravisRidge]

@TravisRidge do you have the ijwhost.dll deployed next to your C++/CLI assembly and are all of your native dependencies resolved/resolvable? Sometimes people miss that file when copying their outputs around.

Our diagnostics for mixed-mode assembly loading need a bit of work since they throw a BadImageFormatException for basically every failure.

@jkoritzinsky The "Ijwhost.dll" was added automatically in the folder next to the assembly in both the builds for the C++ and C# projects. (Curiously the dll had used an uppercase "i", but I tried changing it to lowercase on a hunch with no difference in error message.)

As for the others, I'm not sure how I can verify that. I've adjusted my test project's code to remove those unnecessary includes, so at this point the only explicit external references are those in the automatically generated code (namely the "framework.h" and its reference to "windows.h").

[nefen]

I face exactly the same issue with @TravisRidge.
Native dll=>C++/CLI Wrapper=>aspnet core 3.1 Razor Pages Project.
Compiles. Run breaks with BadImageFormat. Debugging breaks too.
I checked all involved dll's with dumpbin and all were built against x64.
Any New?

[msedi]

The same happens from our side, is there any news?

[RaviBadry]

Any updates on this error

[jkoritzinsky]

Can you validate that all of your native dependencies of the C++/CLI assembly are available on the target machine? Including the VC++ redistributable?

[nefen]

Program crashes in the development machine too. All dendencies are present.

I created a wrapper for a substantial cpp solution. I commented out
everything from the cpp unmanaged entry function. I just cslled it ans
executed the return statement. It worked. So, all dll's have been loaded.

Στις Τρί, 12 Μαΐ 2020, 21:14 ο χρήστης Jeremy Koritzinsky <
[email protected]> έγραψε:

Can you validate that all of your native dependencies of the C++/CLI
assembly are available on the target machine? Including the VC++
redistributable?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/runtime/issues/31743#issuecomment-627507921,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF23M7NFSKTATTG7D4C6I7TRRGGXXANCNFSM4KP5XB6A
.

[jkoritzinsky]

Where is the BadImageFormatException thrown from?
Is it possible that you have an architecture mismatch or that you're missing ijwhost.dll?

[RaviBadry]

Yes, All the Native MFC native dlls are build and available on the target machine.

From: Jeremy Koritzinsky [e-mail]
Sent: 12 May 2020 23:44
To: dotnet/runtime [e-mail]
Cc: Ravishankar Badry [e-mail]; Comment [e-mail]
Subject: [External] Re: [dotnet/runtime] BadImageFormatException when loading C++/CLI DLLs in Core 3.1 (#31743)

Can you validate that all of your native dependencies of the C++/CLI assembly are available on the target machine? Including the VC++ redistributable?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1hGoynaN5NcpEKL80rp-O-qXvy9-bSydFO2oCtbgmvdGiujcqCTj7I9pGVUpg7IXRkQL_68cVcfXkRBH1osjL9jtYSeaT8XkUngxesEP63h3Viyi1X1BWn0z0VlEo6wfPqkUQKVYxx6zmsP_C4o28J-8DeGKIY3LhKjK4cLoC-C4wunNVmlDNIbjd1QdJD5t8QX9m24yyryfowKEMKcIIfc3RouG02hdA9puopdokhdQTBZfWY42TtoXPr8SZA6zJ27ysSeUBUyEqlJI9bsX8umOrG2RMGWxzxmPdG3yZakbGYRy392JfvD_sPZXmT9kNUrBOGjPjxpu3fEdvmR2N-g/https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F31743%23issuecomment-627507921, or unsubscribehttps://secure-web.cisco.com/1ADYcsVr274Sol99upC9B_9f9yruSYLJIxIq0pORKSN_wEqJ2zYBA4nB7vQhvc3cLumc2jrNOUCWzYI_E_F_HxYF6XIa-942PnjK_7UcKDc5IkBWCR1dxTL0ouNLfzFgGOk031H6CZsJdpQLQIHIow-54MnDBJ61f3AonxjbpZgK3BYhGF0p5_cr5YJTy-xaMPHT9Vu7I_472a_Cm0wLYY9MjiEx3VRjs06zHhfbYD4lKqy64isdXEHzHbc0NcurMPLeWNcja6T_Uom-Bl9DcFFvowPWIf7-mkJbRVJFA62LheFoQUcGmQmpkyglNpRwI48bXMTp7Qi-rbQIRMNpnTw/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAOMNBBL6HMIUHMKJVBT4JSDRRGGXXANCNFSM4KP5XB6A.

---

Electronic mail messages entering and leaving Arup business systems are scanned for viruses and acceptability of content.

[jkoritzinsky]

I'm honestly not sure what's going on then. Can you turn on loader snaps and put it under the debugger so we can see where in the loading process we get an error?

[RaviBadry]

I understand the reason in my case. I have a). MFC dlls, b) Wrapper dll , c) C++/CLI .net core dll and d) .net core NUnit test project.

Nunit test project is creating an additional folder Netcoreapp3.1. This project (Nunit test) referencing C++/CLI .net core dll and hence C++/CLI ,Net core dll is copying to the folder Netcoreapp3.1 but not the wrapper dlls.

Therefore, the wrapper dll and other subsequent dlls are not found when executing the Nunit test.

Hope this information is useful for others.

[tylerpayne]

Running into this problem as well.

I SWIG'd a C++ project to generate C# wrappers. Linked my wrappers and the native x86 DLLs with x86 cl.exe. OBJDUMPing the resulting DLL confirms all my expected exports are there. Unfortunately, the moment my x86 C# project tries to PInvoke I get BadImageFormatException: An attempt was made to load a program with an incorrect format. (0x8007000B).

I've also attempted to access the DLL via Assembly.LoadFile but get the slightly different exception System.BadImageFormatException: 'Bad IL format.'

Windows 10
.NET Core 3.1
Visual Studio Community 2019

[IsaacSchemm]

When I had a similar problem with a C# WinForms app (.NET Core 3.1) referencing a C++/CLI .NET Core assembly, it turned out that my Visual Studio configurations were set to always build the C# project as Any CPU, regardless of the active solution platform. I added x86 and x64 platforms to my C# project and set the solution platforms to use them, and it seems OK now.

[Da-Teach]

I ran into a similar issue today and it turns out the server didn't have the redist installed.

After installing it from this link:
https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

It worked for me. Nice error though, bad image format on a clean windows 2019 install which in turn was a redist not installed. A better error message would have saved me a ton of work.

[imaramos]

I am having the same issue running on docker with the image mcr.microsoft.com/dotnet/core/aspnet:3.1.6-nanoserver-2004, I have the ijwhost.dll installed in the folder, I am making sure that everything is built using x64, even tried to install vc_redist.x64.exe but still getting System.BadImageFormatException.

[yunfandev]

@imaramos

https://github.com/dotnet/core/issues/3927#issuecomment-638580305

[imaramos]

@imaramos

dotnet/core#3927 (comment)

I see, thanks for the help. So it is specific to nanoserver? Should I use windows/servercore instead and install aspnetcore runtime manually? Unfortunately the image is much bigger :(.

[yunfandev]

@imaramos

I have tried to compile dotnet core c++/cli program to self-contained exe, and it can only run on mcr.microsoft.com/dotnet/framework/sdk, windows/servercore image will not work.

mcr.microsoft.com/dotnet/framework/sdk is over 7GB after decompression. 😂😂😂

[imaramos]

@imaramos

I have tried dotnet core c++/cli program can only run on mcr.microsoft.com/dotnet/framework/sdk, windows/servercore image will not work.

mcr.microsoft.com/dotnet/framework/sdk is over 7GB after decompression. 😂😂😂

Wow, that is awful, and in my case is useless because I am using dotnet core 3.1, not the full framework.
If c++/cli is not going to be supported in linux, at least it should be a light and easy to build image.