在链接/MD 并且不提供
自定义/ENTRYPOINT，其中动态 CRT 不应该完全
初始化了吗？
首先是一些符号：
-
X 具有静态导入（取决于）Y 和 Z ：
X[ Y, Z]
-
X 入口点：
X_DllMain
-
X_DllMain 致电 LoadLibrary(Y) : X<Y>
当我们使用 /MD - 我们在单独的 DLL(s) 中使用 crt。在此上下文中初始化意味着 crt DLL(s) 的入口点已被调用。所以问题可以更笼统和清晰：
来自X[Y] => Y_DllMain 在X_DllMain 之前调用？
一般情况下没有。因为可以是循环依赖，当Y[X]或者Y[Z[X]]时。
最知名的例子 user32[gdi32] 和 gdi32[user32] 或在 win10 中取决于 gdi32[gdi32full[user32]] 。所以必须先调用user32_DllMain 或gdi32_DllMain 吗？但是很明显，任何 crt DLL(s) 都不依赖于我们的自定义 DLL。所以让我们排除循环依赖情况。
当加载器加载模块 X - 它加载所有它的依赖模块（和它的依赖 - 这是一个递归过程），如果它已经不在内存中，那么加载器构建调用图，并开始调用模块入口点。很明显，如果A[B]，加载程序总是在A_DllMain 之前尝试调用B_DllMain（调用顺序未定义时的循环依赖除外）。但是哪些模块将在调用图中？所有 X 依赖模块 ?当然不。当我们开始加载 X 时，其中一些模块可能已经在内存中（已加载）。所以它的入口点已经用DLL_PROCESS_ATTACH 调用了，现在不能第二次调用。这个策略在xp、vista、win7中使用：
当我们加载X时：
- 在内存中加载或定位所有依赖模块
- 仅调用新加载（在X之后）模块的入口点。
- 如果
A[B] - 在A_DllMain 之前调用B_DllMain
示例：已加载 X[Y[W[Z]], Z]
//++begin load X
Z_DllMain
W_DllMain
Y_DllMain
X_DllMain
// --end load X
但是这个场景没有考虑下一个案例——一些模块可能已经在内存中，但是它的入口点还没有被调用。这怎么会发生？
这可能发生在某些模块入口点调用LoadLibrary。
示例 - 加载 X[Y<W[ Z]>, Z]
//++begin load X
Y_DllMain
//++begin load W
W_DllMain
//--end load W
Z_DllMain
X_DllMain
// --end load X
所以W_DllMain 将在Z_DllMain 之前被调用，尽管W[Z]。正是因为这不推荐从 DLL 入口点调用 LoadLibrary。
但来自动态链接库最佳实践
这可能导致死锁或崩溃。
关于deadlock not true的话——当然任何deadlock基本上都不可能。在哪里 ？如何 ？我们已经在 DLL 入口点中持有加载器锁，并且可以递归地获取该锁。崩溃真的可以（win8之前）。
或另一个错误：
致电ExitThread。在 DLL 分离期间退出线程可能会导致
加载器锁被再次获取，导致死锁或崩溃。
-
可以导致再次获取加载程序锁 - 不是可以，而是总是
- 导致死锁 - false - 我们已经持有这个锁
- 崩溃 - 不会有任何崩溃，否则会出现 false
但实际上会是 - 没有空闲加载程序锁的线程退出。它变得永远忙碌。结果是任何新线程的创建或退出，任何新的 DLL 加载或卸载，或者只是 ExitProcess 调用 - 挂起，当尝试获取加载程序锁时。所以这里确实会出现僵局，但不会在 Call ExitThread 期间发生 - 后者。
当然还有有趣的注意事项 - Windows 本身从 DllMain 调用 LoadLibrary - user32.dll 总是从它的条目中为 imm32.dll 调用 LoadLibrary点（在win10上仍然正确）
但是从 win8（或 win8.1）开始，加载器在处理依赖模块方面变得更加智能。现在 2 已更改
2. 调用new 加载（X 之后）模块的入口点，或者如果模块尚未初始化。
所以在现代 Windows (8+) 中加载 X[Y<W[Z]>, Z]
//++begin load X
Y_DllMain
//++begin load W
Z_DllMain
W_DllMain
//--end load W
X_DllMain
// -- end load X
Z 初始化将移至 W 加载调用图。结果现在一切都正确了。
为了测试这一点，我们可以构建下一个解决方案：test.exe[ kernel32, D1< D2[kernel32, msvcrt] >, msvcrt ]
-
D2 仅从 kernel32 和 msvcrt 导入并导出
SomeFunc
-
D1 仅从 kernel32 导入并从其入口点调用
LoadLibraryW(L"D2")，然后调用D2.SomeFunc
-
test.exe 从 kernel32、D1 和 msvcrt 导入
（完全按照这个顺序！这非常重要 - D1 必须在导入时 before msvcrt，为此需要设置 D1 在链接器命令行中 msvcrt 之前）
结果 D1 入口点将在 msvcrt 之前调用。这是正常的 - D1 不依赖于 msvcrt
但是当 D1 从入口点加载 D2 时，就变得有趣了
D2.dll 的代码（/NODEFAULTLIB kernel32.lib msvcrt.lib）
#include <Windows.h>
extern "C"
{
__declspec(dllimport) int __cdecl sprintf(PSTR buf, PCSTR format, ...);
}
BOOLEAN WINAPI MyEp( HMODULE , DWORD ul_reason_for_call, PVOID )
{
if (ul_reason_for_call == DLL_PROCESS_ATTACH)
{
OutputDebugStringA("D2.DllMain\n");
}
return TRUE;
}
INT_PTR WINAPI SomeFunc()
{
__pragma(message(__FUNCDNAME__))
char buf[32];
// this is only for link to msvcrt.dll
sprintf(buf, "D2.SomeFunc\n");
OutputDebugStringA(buf);
return 0;
}
#ifdef _WIN64
#define FuncName "?SomeFunc@@YA_JXZ"
#else
#define FuncName "?SomeFunc@@YGHXZ"
#endif
__pragma(comment(linker, "/export:" FuncName ",@1,NONAME,PRIVATE"))
D1.dll（/NODEFAULTLIB kernel32.lib）的代码
#include <Windows.h>
#pragma warning(disable : 4706)
BOOLEAN WINAPI MyEp( HMODULE hmod, DWORD ul_reason_for_call, PVOID )
{
if (ul_reason_for_call == DLL_PROCESS_ATTACH)
{
OutputDebugStringA("D1.DllMain\n");
if (hmod = LoadLibraryW(L"D2"))
{
if (FARPROC fp = GetProcAddress(hmod, (PCSTR)1))
{
fp();
}
}
}
return TRUE;
}
INT_PTR WINAPI SomeFunc()
{
__pragma(message(__FUNCDNAME__))
OutputDebugStringA("D1.SomeFunc\n");
return 0;
}
#ifdef _WIN64
#define FuncName "?SomeFunc@@YA_JXZ"
#else
#define FuncName "?SomeFunc@@YGHXZ"
#endif
__pragma(comment(linker, "/export:" FuncName ",@1,NONAME"))
exe的代码（/NODEFAULTLIB kernel32.lib D1.lib msvcrt.lib）
#include <Windows.h>
extern "C"
{
__declspec(dllimport) int __cdecl sprintf(PSTR buf, PCSTR format, ...);
}
__declspec(dllimport) INT_PTR WINAPI SomeFunc();
void ep()
{
char buf[32];
// this is only for link to msvcrt.dll
sprintf(buf, "exe entry\n");
OutputDebugStringA(buf);
ExitProcess((UINT)SomeFunc());
}
xp 的输出：
LDR: D1.dll loaded - Calling init routine
D1.DllMain
Load: D2.dll
LDR: D2.dll loaded - Calling init routine
D2.DllMain
D2.SomeFunc
LDR: msvcrt.dll loaded - Calling init routine
exe entry
D1.SomeFunc
对于win7：
LdrpRunInitializeRoutines - INFO: Calling init routine for DLL "D1.dll"
D1.DllMain
Load: D2.dll
LdrpRunInitializeRoutines - INFO: Calling init routine for DLL "D2.DLL"
D2.DllMain
D2.SomeFunc
LdrpRunInitializeRoutines - "msvcrt.dll"
exe entry
D1.SomeFunc
在这两种情况下，调用流程是相同的 - D2.DllMain 调用 before msvcrt 入口点，尽管 D2[msvcrt]
但在 win8.1 和 win10 上 - 调用流程是另一个：
LdrpInitializeNode - INFO: Calling init routine for DLL "D1.dll"
D1.DllMain
LdrpInitializeNode - INFO: Calling init routine for DLL "msvcrt.dll"
LdrpInitializeNode - INFO: Calling init routine for DLL "D2.DLL"
D2.DllMain
D2.SomeFunc
exe entry
D1.SomeFunc
在 msvcrt 初始化之后调用的 D2 入口点。
那么结论是什么？
如果当模块X[Y] 被加载并且内存中没有未初始化的Y - Y_DllMain 将被调用之前 X_DllMain。或者换句话说 - 如果没有人从 DLL 入口点调用 LoadLibrary(X) （或 LoadLibrary(Z[X]) ）。因此，如果您的 DLL 将以“正常”方式加载（不是通过从 DllMain 调用 LoadLibrary 或在某些 dll 加载事件中从驱动程序注入） - 您可以确定 crt 入口点已被调用（crt 已初始化）
更多 - 如果你在 win8.1+ 上运行 - 并且 X[Y] 已加载 - Y_DllMain 将始终被称为 before X_DllMain。
现在关于您的 dll 中的自定义 /ENTRYPOINT。
即使您在单独的 DLL 中使用 crt - 一些小的 crt 代码将静态链接到您的模块 DllMainCRTStartup - 按名称调用您的函数 DllMain（这不是入口点）。因此，如果动态 crt - 我们确实有 2 个 crt 部分 - 主要部分位于单独的 DLL 中，它将在 在 调用您的 DLL 入口点之前被初始化（如果不是我描述的特殊情况，并且win7,vista,xp）。和小的静态部分（模块内的代码）。何时调用此静态部分已完全取决于您。这部分DllMainCRTStartup 进行一些内部初始化，在代码中初始化全局对象（initterm）并调用DllMain，在它返回（在 dll 分离时）调用全局变量的析构函数..
如果您在 DLL 中设置自定义入口点 - 此时 crt 在单独的 DLL 中已经初始化，但您的静态 crt 没有（as 和全局对象）。从这个自定义入口点，您将需要调用 DllMainCRTStartup