The loader lock is a process-wide lock used by the system to synchronize access to loading DLL's into a process address space. Functions that load DLL's, free DLL's, query DLL info, etc., all acquire the loader lock. What typically impacts developers the most is that the loader lock is held while DllMain is running as well - this means that an OS lock that you aren't normally aware of can be held while running your code.
The loader lock can be viewed as being at a very low level in the lock-hierarchy. Code running under the loader lock during DllMain can be the cause of deadlocks. For instance, the CLR has its own set of internal locks which it could hold while loading DLL's. If you call managed code from within your DllMain, you could cause the CLR on your thread to acquire one of these locks while holding the loader lock. If the CLR on another thread had acquired that lock (causing the origin thread in DllMain to block) and then tried to load a DLL which would acquire the loader lock, your process would deadlock.
It sounds like the CLR is trying to preemptively detect running managed code under the loader lock. When you see the stack from this failure in the debugger, identify what is causing your managed code to be running from within a DllMain and remove it.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…