/MD模式下动态CRT未在DllMain调用时初始化的场景咨询

针对你的三个问题，结合MSDN文档和实际开发经验，我来逐一解答： #

问题1：使用/MD且未自定义入口点、仅静态依赖加载DLL时，是否存在其他动态CRT未完全初始化的场景？ #

在这种标准场景下，几乎不会出现动态CRT未完全初始化的情况。原因在于：当你使用/MD编译且未自定义入口点时，你的DLL会链接CRT提供的默认入口函数（比如_DllMainCRTStartup），这个函数会先完成CRT的核心初始化工作——包括初始化CRT堆、设置全局状态、调用全局/静态对象的构造函数等——之后才会调用你自己编写的DllMain。

而静态依赖加载时，系统会按照DLL的依赖关系自动加载并初始化依赖项，动态CRT DLL（如msvcrt.dll、vcruntime140.dll等）会被优先加载并完成自身初始化，之后才会处理你的业务DLL。所以在你自己的DllMain执行时，CRT已经处于完全可用状态了。

极端情况下如果出现问题，大概率是你的DLL被其他DLL在其DllMain中通过LoadLibrary动态加载（而非静态依赖），但这已经不属于你描述的“仅静态依赖加载”的范畴了。

问题2：CRT未初始化时所有CRT函数均不安全，为何文档单独强调内存管理函数？ #

文档单独点名内存管理函数（malloc/free、new/delete等），主要有两个核心原因：

• 依赖的核心结构未初始化：内存管理函数直接依赖CRT内部的堆管理结构，这些结构是CRT初始化阶段最关键的创建项之一。如果CRT未初始化，调用这些函数会直接访问未分配或未初始化的内存区域，几乎必然导致进程崩溃或严重的内存损坏，没有任何“侥幸运行”的可能。
• 使用频率高且风险隐蔽：内存管理函数是DLL开发中最常用的CRT函数之一，开发者很容易在DllMain中不经意间调用（比如创建临时对象、分配缓冲区）。相比之下，其他CRT函数（如字符串处理函数）可能在某些极端场景下因依赖的全局变量未初始化但未触发崩溃，但内存管理函数的问题是即时且致命的，因此文档重点强调以规避最高风险。

问题3：自定义入口点时需自行初始化CRT，为何该场景被纳入DllMain禁忌列表？ #

当你通过/ENTRYPOINT指定自定义入口点时，你绕过了CRT提供的默认入口逻辑，这会带来两个关键风险：

1. 初始化顺序错误：CRT的初始化逻辑（如堆创建、全局对象构造、IO系统初始化）非常复杂，手动实现很容易遗漏关键步骤，或者在CRT初始化完成前就调用了CRT函数（包括在DllMain中），直接触发未初始化问题。
2. DllMain的执行环境限制：DllMain本身处于进程初始化/终止、线程创建/销毁的临界环境中，系统对这个函数的操作有严格限制（比如不能加载/卸载DLL、不能创建线程、不能调用某些同步API）。而CRT的初始化过程可能会隐含这些被禁止的操作，即使你手动调用CRT初始化函数，也可能导致死锁或进程崩溃。

因此，即使你计划手动初始化CRT，自定义入口点的场景下，DllMain依然是高风险区域，被文档纳入禁忌列表。

关于补充问题：含CRT函数的全局对象构造代码是否需要修复？ #

如果你的代码是在默认入口点+静态依赖加载的场景下运行，那么这些代码是安全的，不需要修复。因为全局/静态对象的构造函数是在CRT初始化阶段被调用的（由默认入口函数触发），此时CRT已经完成了核心初始化，调用CRT函数是完全合法的。

只有当你使用了自定义入口点，或者全局对象的构造被意外提前到CRT初始化之前时，才需要检查并修复——比如调整初始化顺序，确保CRT完全初始化后再执行这些构造逻辑。

内容的提问来源于stack exchange，提问作者Martin Ba