我们有一个多线程应用程序。 其中一个工作线程调用 GetModuleFilename 用于日志记录目的，我们已经看到了一个死锁，其中工作线程在调用永久阻塞的 GetModuleFilename 之前持有一个锁。
我们可以并且已经从这个锁中删除了 GetModuleFilename 调用，但仍然对死锁的确切发生方式非常感兴趣。
在线阅读：http://blogs.msdn.com/b/oldnewthing/archive/2004/01/28/63880.aspx
似乎 GetModule文件名将获取加载器锁，这似乎是死锁的一个很好的候选者。
但通常加载器锁内的线程不会执行我们自己的任何代码，除了根据上面的链接在 dllmain 中。
可能会在加载器锁和另一个正在创建或销毁的工作线程上调用dll_thread_attach或分离，但我看不出有任何方法可以尝试获取我们正在使用的锁。
也有可能主线程尝试获取 GetModuleFilename 线程持有的锁，而第三个线程持有加载器锁并在主线程上执行发送消息或类似阻塞的事情？ 在这里，我也没有发现任何发生这种情况的情况。
我怀疑的其他线程之一是使用 COM 对象的线程。 线程调用在开始时共同初始化，因此应该在单线程单元中。 在这里与加载器锁交互的可能性吗？
无论如何，我们无法确定这种死锁发生的确切方式。 因此，我希望获得一些想法，或者有关加载器锁的更多信息，以及是否有任何其他情况会在加载器锁中执行代码，这可能会阻塞。
谢谢。
只是一些随机的想法：
-
如果有C++（不仅仅是 C）代码，则在系统持有负载锁时，也可能执行 DLL 上静态分配对象的构造函数。你不在任何地方使用你的锁在这样的对象的构造函数/析构函数中吗？
也许尽管您的锁定， 该错误仍然存在，并且使用锁定实际上可能只是通过例如更改某些线程中的某些操作时间来"取消隐藏"比赛。
DllMain()和线程可能很棘手。见 http://blogs.msdn.com/b/oldnewthing/archive/2007/09/04/4731478.aspx
好吧，事实证明，我描述的问题只是我们使用的库中不同问题的症状。 该库显然在两个不同的线程中使用了一些wininet API，其中一个在dllmain和加载器锁内。 这两个线程死锁，随后锁定了我们的线程，称为GetModule文件名。
这和我现在所知道的差不多，但是一旦我们从库的供应商那里得到更多细节，我就会更新它。