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


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

#pragma once

#include "Native.h"

using namespace System;

namespace CPPWrapper {

    public ref class Class1

        Class1() : mnt(new Native)


            // call the finalize method

        // Finalize (for garbage collection)
            // Remove unmanaged class
            delete mnt;
            mnt = NULL;

        void Napravi()

        Native *mnt;

asked on Stack Overflow Jul 9, 2012 by xx77aBs

2 Answers


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
                   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:
    return TRUE;
answered on Stack Overflow Sep 26, 2012 by smurphy

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.

answered on Stack Overflow Aug 22, 2018 by Matt Chambers

User contributions licensed under CC BY-SA 3.0