为什么我收到“检测到 LoaderLock”消息 调试时警告？
我正在为 AutoCAD 2009 开发一个附加组件。项目输出是一个类库。 当我尝试调试和加载类库时，我收到此“检测到 LoaderLock 消息”。 我编写这些附加组件已经有一段时间了，这是我看到的第一条此类消息。
- 我从哪里开始尝试解决这个问题？
- LoaderLock 是什么？为什么它现在困扰着我？
检测到 LoaderLock 消息：尝试在操作系统加载程序锁内托管执行。 不要尝试在 DllMain 或映像初始化函数内运行托管代码，因为这样做可能会导致应用程序挂起。
我去了调试 -> 例外情况-> “托管调试助手”，找到“LoaderLock”并取消选中“Thrown”复选框。
我可以再次调试，但是我做了什么以及为什么我必须这样做？ 这会给我带来其他问题吗？
I'm developing an add-on for AutoCAD 2009. The project output is a class library. When I attempt to debug and load the class library, I get this "LoaderLock was detected message." I've been writing these add-ons for awhile and this is the first message of this type I've seen.
- Where do I start trying to figure this out?
- What is LoaderLock and why is it bothering me now?
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.
I went to Debug -> Exceptions -> "Managed Debugging Assistants", found "LoaderLock" and unchecked the "Thrown" checkbox.
I can debug again but what did I do and why did I have to do it? Will this cause other problems for me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
加载器锁是一个进程范围的锁，系统使用它来同步将 DLL 加载到进程地址空间的访问。 加载 DLL、释放 DLL、查询 DLL 信息等函数都需要获取加载器锁。 通常对开发人员影响最大的是加载程序锁在 DllMain 运行时也被持有 - 这意味着在运行代码时可能会持有您通常不知道的操作系统锁。
加载器锁可以被视为处于锁层次结构中非常低的级别。 DllMain 期间在加载器锁下运行的代码可能是死锁的原因。 例如，CLR 有自己的一组内部锁，可以在加载 DLL 时持有这些锁。 如果从 DllMain 中调用托管代码，则可能会导致线程上的 CLR 在持有加载程序锁的同时获取这些锁之一。 如果另一个线程上的 CLR 已获取该锁（导致 DllMain 中的原始线程阻塞），然后尝试加载将获取加载器锁的 DLL，则您的进程将死锁。
听起来 CLR 正在尝试抢先检测加载器锁下正在运行的托管代码。 当您在调试器中看到此故障的堆栈时，请确定导致托管代码从 DllMain 内运行的原因并将其删除。
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.
根据我使用 AutoCAD 的经验，可以安全地忽略 LoaderLock 警告。 这并不是代码执行错误的迹象，而是由于 AutoCAD 加载和初始化应用程序的方式而引发警告。
In my experience with AutoCAD, the LoaderLock warning can be safely ignored. It's not a sign of your code doing something wrong, but rather the warning is raised because of the way AutoCAD is loading and initializing your application.
这是 Visual Studio 2005 中的错误。请阅读此知识库文章了解更多详细信息。
This a bug in Visual Studio 2005. Read this kb article for more details.