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

[Farengeto]

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.

[Farengeto]

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.

[Farengeto]

@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 < notifications@github.com> έγραψε:

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 notifications@github.com Sent: 12 May 2020 23:44 To: dotnet/runtime runtime@noreply.github.com Cc: Ravishankar Badry Ravishankar.Badry@arup.com; Comment comment@noreply.github.com 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.

[emanuel-v-r]

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

[emanuel-v-r]

@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. 😂😂😂

[emanuel-v-r]

@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.

[Weijee]

I have tested this issue on .NETCore3.1/.NET5 by using ConsoleApp/WebApplication/WebApi, and the result goes like this:	Reference	ConsoleApp	WebApplication	WebApi
Reference C++/CLI Project	OK	OK	OK
Reference C++/CLI Dll	NG	NG	NG

NG: BadImageFormatException occurs I dont know what is the defference between these two reference modes.
Any ideas?

[ryangle]

I have tested this issue on .NETCore3.1/.NET5 by using ConsoleApp/WebApplication/WebApi, and the result goes like this:

Reference ConsoleApp WebApplication WebApi Reference C++/CLI Project OK OK OK Reference C++/CLI Dll NG NG NG NG: BadImageFormatException occurs I dont know what is the defference between these two reference modes. Any ideas?

Check the "Copy C++ Runtime to OutDir" in the C++/Cli project.

[intellild]

Same issue My C# XAML application referencing my empty proxy c++/cli project works fine But when I reference the native c++ DLL in the proxy project, the error occurs

[Gornhoth]

Similar issue with a .NET 5.0 project that references a C++ dll. All dlls are copied into the output directory when compiling, all of them and the project itself are targeting x64. When running the executable: "Unhandled exception. System.BadImageFormatException: Could not load file or assembly '...'. An attempt was made to load a program with an incorrect format." I tried the same in a .NET Framework 4.7.2 project and there it loads all assemblies properly and runs without an issue. Any idea?

[emanuel-v-r]

@Gornhoth this comment https://github.com/dotnet/core/issues/3927#issuecomment-674100138 may be helpful for you, it's an ugly solution but at least it worked, it was for .NET Core 3.1, but I am guessing it will work for .NET 5

[Gornhoth]

@imaramos thank you for the suggestion. I searched a bit more and found https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer which i used to see if there were any compatibility issues between the managed c++ dlls targeting .net framework 4.7.2 (as seen in assembly explorer) and my .net 5.0 project which references them. Turns out there are several incompatibilities in some dlls which prevents me from using them.

[FanjingLiu]

Same thing for me too, .Net5 console app referencing a c++cli dll, portability analyzer is all green.

[HengzheLi]

Same issue when debug .net 5 app from Visualstudio. But when I build the project using MSBuild outside the VS. The app can run smoothly.

It is strange. When I change "Use Debug Libraries" from Yes to No. All works. But this setting always work before I upgrade VS2019 to 16.11. But the source code could not be step into in this way.

[fiercekittenz]

I'm experiencing this now with a x64 net5.0-windows C# application referencing a /clr:netcore (net5.0) library. Any time the code is used from the referenced CLR project, it crashes with this same exception.

[kaba2]

I had a similar problem with BadImageFormatException using a C++/CLI library from C# (although with NET Framework).

The solution was to disable "Prefer 32 bits" from the C# library properties.

[pawan-vinove]

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.

This is not working in my case. Code is running on x86 but not able to run it on docker..