Home/ Questions/Q 120013
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T03:44:38+00:00

I have recently integrated the .NET NLog logging component into one of our applications

  • 0

I have recently integrated the .NET NLog logging component into one of our applications which developed purely in unmanaged code (C++ and VB6 components compiled in Visual Studio 6). We have a bunch of C++ application talking to NLog via a COM interface.

Everything is working fine at the moment but I do notice that the following message pops up (in the output window if debugging the C++ component in VS6; as a prompt in the IDE if debugging NLog via VS 2005) during program termination:

LoaderLock was detected Message: 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.

The DllMain is as follows:

extern 'C' BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID /*lpReserved*/) {     if (dwReason == DLL_PROCESS_ATTACH)     {         _Module.Init(ObjectMap, hInstance);         DisableThreadLibraryCalls(hInstance);     }     else if (dwReason == DLL_PROCESS_DETACH)         _Module.Term();     return TRUE;    // ok }

My guess is that _Module.Term(); now includes the releasing of some .NET references (I am keeping a reference to a NLog object in one of my C++ classes to avoid having to instantiate and release each time) which is causing this warning to pop up.

My question: is this safe to ignore? If it isn’t, what is a good workaround? (the best I can think of is to instantiate a reference to that NLog object and release it every time I want to write to the log file…not the most elegant of solutions)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. It is most definitely not safe to ignore this message. If you hit this message, you’ve almost certainly created a real loader lock policy violation. This is a very serious error and can cause unpredictable behavior in a program (including deadlock).

    The best way to avoid this is to not access any other .Net Objects/Functions directly or indirectly inside of DLL main. For your case, it’s probably best to use a different cache policy. Perhaps create a ref counted object to hold the .Net reference. That way the object will be released before DllMain is called for unload (the dll can’t be unloaded until all of your objects are destroyed).

    • 0