windows 从 DllMain 调用 LoadLibrary

Calling LoadLibrary from DllMain

提问by Abyx

MSDN says:

MSDN 说：

It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code.

它不能调用 LoadLibrary 或 LoadLibraryEx 函数（或调用这些函数的函数），因为这可能会在 DLL 加载顺序中创建依赖循环。这可能导致在系统执行其初始化代码之前使用 DLL。

I tried to call LoadLibraryfrom DllMain and nothing happened.

我试图LoadLibrary从 DllMain 调用，但什么也没发生。

The only issue that I see is that loaded DLL will use functions in my DLL before rest of my DllMain executes.

我看到的唯一问题是加载的 DLL 将在我的 DllMain 的其余部分执行之前使用我的 DLL 中的函数。

Why I must not call LoadLibrary in DllMain?

为什么我不能在 DllMain 中调用 LoadLibrary？

EDIT:

编辑：

OK, I realized that I must not call LoadLibrary in DllMain just because I must believeMSDN as other believers do (I saw some wrong things there, but I should forget them too).
And because something may happen in newer versions of Windows (although there nothing was changed for last ten years).

好的，我意识到我不能仅仅因为我必须像其他信徒一样相信MSDN（我在那里看到了一些错误的东西，但我也应该忘记它们）而在 DllMain 中调用 LoadLibrary 。
并且因为在较新版本的 Windows 中可能会发生一些事情（尽管过去十年没有任何变化）。

But can anyone show a code which will reproduce something bad what happens when LoadLibraryis called in DllMain? In any existing Windows OS?
Not just a call of one singleton initialization function inside another, but LoadLibraryin DllMain?

但是任何人都可以展示一个代码来重现在LoadLibraryDllMain 中调用时会发生什么不好的事情吗？在任何现有的 Windows 操作系统中？
不仅仅是在另一个内部调用一个单例初始化函数，而是LoadLibrary在 DllMain 中调用？

回答by Aaron Klotz

Your argument in favor of going ahead with this seems to be, to paraphrase:

你赞成继续这样做的论点似乎是，解释一下：

Microsoft says don't do this, but my single test case seems to work, therefore I fail to see why nobody should be doing this.

微软说不要这样做，但我的单个测试用例似乎有效，因此我不明白为什么没有人应该这样做。

You're operating under a big assumption: you're assuming that the underlying implementation of the Windows loader will never change. What if the loader is changed in "Windows 8" in a way such that your code no longer works properly? Now Microsoftgets blamed for it and they have to include yet another compatibility hack to work around code that they told younotto write in the first place.

您在一个很大的假设下进行操作：您假设 Windows 加载程序的底层实现永远不会改变。如果加载程序在“Windows 8”中以某种方式更改以致您的代码不再正常工作怎么办？现在微软为此受到指责，他们必须包含另一个兼容性黑客来解决他们一开始就告诉你不要编写的代码。

Follow the guidelines. They're not there just to make your life more difficult, they're there to guarantee that your code will work just as well on the Windows of the future as it does now.

遵循准则。它们的存在不仅是为了让您的生活变得更加困难，而且是为了保证您的代码在未来的 Windows 上也能像现在一样正常工作。

回答by Geoff Chappell

There are simple, and even not so simple, circumstances in which calling LoadLibrary from DllMain is perfectly safe. But the designis that DllMain is trusted not to change the list of loaded modules.

从 DllMain 调用 LoadLibrary 在某些简单甚至不那么简单的情况下是完全安全的。但设计是信任 DllMain 不会更改已加载模块的列表。

Though possession of the loader lock does indeed constrain what can be done in DllMain, it is only indirectly relevant to the LoadLibrary rule. The relevant purpose of the loader lock is serialise access to the list of loaded modules. While NTDLL works on this list in one thread, possession of the loader lock ensures that the list won't be changed by NTDLL code that's executing in another thread. However, the loader lock is a critical section. It does nothing to stop the same thread from re-acquiring the loader lock and changing the list.

尽管拥有加载程序锁确实限制了 DllMain 中可以执行的操作，但它仅与 LoadLibrary 规则间接相关。加载器锁的相关目的是序列化对加载模块列表的访问。虽然 NTDLL 在一个线程中处理此列表，但拥有加载器锁可确保列表不会被在另一个线程中执行的 NTDLL 代码更改。但是，加载程序锁是一个关键部分。它不会阻止同一线程重新获取加载程序锁并更改列表。

This would not matter if NTDLL kept entirely to itself while working on the list. However, NTDLL provides for involving other code in this work, as when initialising a newly loaded DLL. Each time NTDLL calls outside itself while working on the list, there is a choice to make for the design. Broadly, there are two options. One is to stabilise the list and release the loader lock, call outside, then acquire the loader lock and resume work on the list as if from scratch because the outside call may have changed it. The other is to keep the loader lock and trust the called code not to do anything that changes the list. And thus does LoadLibrary become off-limits in DllMain.

如果 NTDLL 在处理列表时完全保留它自己，这无关紧要。但是，NTDLL 允许在此工作中涉及其他代码，例如在初始化新加载的 DLL 时。每次 NTDLL 在处理列表时调用外部，都会为设计做出选择。大体上，有两种选择。一种是稳定列表并释放加载器锁，调用外部，然后获取加载器锁并恢复对列表的工作，就像从头开始一样，因为外部调用可能已经改变了它。另一种是保持加载器锁定并相信被调用的代码不会做任何改变列表的事情。因此 LoadLibrary 成为 DllMain 中的禁区。

It's not that the loader lock does anything to stopDllMain from calling LoadLibrary or even that the loader lock itself makes such a call unsafe. It is instead that by retaining the loader lock, NTDLL trustsDllMain not to call LoadLibrary.

并不是说加载器锁会阻止DllMain 调用 LoadLibrary，甚至不是加载器锁本身使这样的调用不安全。相反，通过保留加载程序锁，NTDLL信任DllMain 不会调用 LoadLibrary。

For contrast, consider the DllMain rule about not waiting on synchronisation objects. Here, the loader lock has a direct role in making this unsafe. Waiting on a synchronisation object in DllMain sets up the possibility of deadlock. All that's needed is that another thread already holds the object you're waiting on, and then this other thread calls any function that would wait on the loader lock (e.g., LoadLibrary but also such functions as the seemingly inocuous GetModuleHandle).

相比之下，请考虑关于不等待同步对象的 DllMain 规则。在这里，加载器锁在使这不安全方面具有直接作用。在 DllMain 中等待同步对象可能会导致死锁。所需要的只是另一个线程已经持有您正在等待的对象，然后这个另一个线程调用任何将等待加载器锁的函数（例如，LoadLibrary 以及诸如看似无关紧要的 GetModuleHandle 之类的函数）。

Wanting to stretch or break the DllMain rules may be mischievous or even outright stupid. However, I must point out that Microsoft is at least partly to blame for people asking how strong or meaningful are these rules. After all, some have not always been documented clearly and forcefully, and when last I looked they were still not documented in all the situations where they're surely needed. (The exception I have in mind is that at least until Visual Studio 2005, MFC programmers writing DLLs were told to put their initialisation code in CWinApp::InitInstance but were not told that this code is subject to the DllMain rules.)

想要扩展或打破 DllMain 规则可能是恶作剧甚至是彻头彻尾的愚蠢。然而，我必须指出，微软至少应为人们询问这些规则有多强或有多有意义而负部分责任。毕竟，有些并不总是被清楚而有力地记录下来，当我最后一次查看时，它们仍然没有在所有肯定需要它们的情况下记录下来。（我想到的例外是，至少在 Visual Studio 2005 之前，编写 DLL 的 MFC 程序员被告知将他们的初始化代码放在 CWinApp::InitInstance 中，但没有被告知此代码受 DllMain 规则的约束。）

Moreover, it would be a bit rich for anyone from Microsoft to speak as if the DllMain rules ought be followed without question. Examples exist where Microsoft's own programmers break the rules, and continue to even after breaking the rules is seen to have caused serious real-world trouble.

此外，对于微软的任何人来说，好像应该毫无疑问地遵循 DllMain 规则一样会有点丰富。微软自己的程序员违反规则的例子是存在的，即使在违反规则之后仍然继续被视为造成了严重的现实世界的麻烦。

回答by Marcus Borkenhagen

As stated in http://msdn.microsoft.com/en-us/library/ms682583%28VS.85%29.aspx:

如http://msdn.microsoft.com/en-us/library/ms682583%28VS.85%29.aspx 所述：

Threads in DllMain hold the loader lock so no additional DLLs can be dynamically loaded or initialized.

DllMain 中的线程持有加载器锁，因此无法动态加载或初始化额外的 DLL。

Cheers

干杯

回答by Anatol Belski

I was working on a case that could require using LoadLibrary in DllMain, so while investigating found this discussion. An update on this from my todays experience

我正在处理一个可能需要在 DllMain 中使用 LoadLibrary 的案例，因此在调查时发现了这个讨论。根据我今天的经验对此进行更新

Reading this one can get really scary http://blogs.msdn.com/b/oleglv/archive/2003/10/28/56142.aspx. Not only various locks matter, but also the order in which the libs was passed to the linker. The case is say one bi

阅读这个可能会变得非常可怕http://blogs.msdn.com/b/oleglv/archive/2003/10/28/56142.aspx。不仅各种锁很重要，而且将库传递给链接器的顺序也很重要。案例是说一比

Now, I've tried this with vc9 under win7. Yes, so is it. Depending on the order of how the libs are passed to the linker, using LoadLibrary works or not. However, the same with vc11 under win8 works properly disregarding the link order. Application Verifier doesn't blame about that.

现在，我已经在win7下用vc9试过了。是的，也是。根据库如何传递给链接器的顺序，使用 LoadLibrary 是否有效。但是，在win8下和vc11一样，不管链接顺序都可以正常工作。Application Verifier 不会因此而责怪。

I'm not calling to use it this way right now and everywhere :) But just FYI, if it's the same with win10 and further - this might have more usefulness. Anyway seems that the loader mechanism under win8 undergone some noticeable changes.

我现在和任何地方都没有要求以这种方式使用它:) 但仅供参考，如果它与 win10 以及更远的版本相同 - 这可能会有更多用处。不管怎样，win8 下的加载器机制似乎发生了一些明显的变化。

Thanks.

谢谢。

回答by adi_vastava

It is extremely late but still,

已经很晚了，但仍然，

If on thread 1 (T1) you DllMain loads other libraries, those other lib's DllMain will be called; which in itself is okay but say their DLLMain creates a thread (T2) and waits on an event for T2 to finish.

如果在线程 1 (T1) 上，您的 DllMain 加载了其他库，则将调用其他库的 DllMain；这本身没问题，但说他们的 DLLMain 创建了一个线程（T2）并等待 T2 完成的事件。

Now if T2 loads a library in its processing, loader will not be able to acquire the lock as T1 has already acquired it. As T2 is hung on LoaderLock it will never signal the event T1 is waiting on.

现在，如果 T2 在其处理过程中加载一个库，加载器将无法获取锁，因为 T1 已经获取了它。由于 T2 挂在 LoaderLock 上，它永远不会发出 T1 正在等待的事件信号。

Which will result in a deadlock.

这将导致僵局。

There could be more such scenario, I guess the broad reasoning here is that we can not be sure of what code will run in other libraries, so it is a good idea (turned best practice), to not do it.

可能会有更多这样的场景，我想这里的广泛推理是我们无法确定哪些代码将在其他库中运行，因此不这样做是一个好主意（已成为最佳实践）。