C++/CLI wrapper not working (LoaderLock exception)

Question

I've made very simple wrapper for unmanaged C++ library (to be used with C#). Wrapper has one unmanaged class and one managed class. Managed class has private member that is of unmanaged class and uses it like that.

I've done very simple setup - I've created wrapper for only one function to see if everything is working. But as soon as I create an instance of wrapper, my application get's exception "LoaderLock was detected" with following message:

DLL 'c:\path\CPPWrapper.dll' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

If I turn off breaking for "LoaderLock" exception, I get "FileLoadException was unhandled":

Could not load file or assembly 'CPPWrapper.dll' or one of its dependencies. Exception from HRESULT: 0xE0434352

Any idea what I am doing wrong and how can I fix this problem?

CPPWrapper.h

// CPPWrapper.h

#pragma once

#include "Native.h"

using namespace System;

namespace CPPWrapper {

    public ref class Class1
    {
        public:

        Class1() : mnt(new Native)
        {

        }

        ~Class1(void)
        {
            // call the finalize method
            this->!Class1();
        }

        // Finalize (for garbage collection)
        !Class1(void)
        {
            // Remove unmanaged class
            delete mnt;
            mnt = NULL;
        }

        void Napravi()
        {
            mnt->CreatePK();
        }

    private:
        Native *mnt;
    };

}

I'm having exactly the same issue but I'm not sure about the relation between the LoaderLock and the 0xE0434352. As far as I know 0xE0434352 is related to a COM problem: #define EXCEPTION_COMPLUS 0xe0434352 // 0xe0000000 | 'CCR' — Ignacio Soler Garcia, Aug 22 '12 at 15:57

score 4 · Accepted Answer · answered Sep 26 '12 at 15:59

I found that the correct way to fix this is by adding #pragma unmanaged in the dllmain.c Don't turn off breaking for "LoaderLock" exception.

See Initialization of Mixed Assemblies and scroll down to the DllMain section for details. Basically what is happening is that the project is compiling the DllMain function as managed (MSIL) but it only runs in unmanaged code. This #pragma unmanaged forces the function to be compiled as an unmanaged function.

So my dllmain.c is now:

// dllmain.cpp : Defines the entry point for the DLL application.
#include "stdafx.h"

#pragma unmanaged
BOOL APIENTRY DllMain( HMODULE hModule,
                   DWORD  ul_reason_for_call,
                   LPVOID lpReserved
                 )
{
    switch (ul_reason_for_call)
    {
        case DLL_PROCESS_ATTACH:
        case DLL_THREAD_ATTACH:
        case DLL_THREAD_DETACH:
        case DLL_PROCESS_DETACH:
            break;
    }
    return TRUE;
}

score 0 · Answer 2 · answered Aug 22 '18 at 13:10

Another potential cause for LoaderLock is initialization of global static objects. In my case, I was compiling a boost::xpressive regex globally and it didn't like doing that when my C++/CLI wrapper was initializing DllMain. I'm not sure why, because it shouldn't have been managed code, but moving it to a function static object fixed it.

C++/CLI wrapper not working (LoaderLock exception)

2 Answers2