CreateThread与_beginthreadex差异及DisableThreadLibraryCalls影响咨询

嘿，我来帮你拆解这几个问题——毕竟在Win32/Win64 DLL里折腾线程和DLLMain的坑，我可太熟了😉

这俩本质是原生API和CRT封装的区别，核心差异全在C运行时（CRT）的关联上：

• CreateThread是Windows系统原生API，完全独立于CRT。它只负责创建系统级线程，不会管CRT的任何初始化或清理工作。如果你的线程里用到CRT函数（比如malloc、printf、strtok这类），直接用CreateThread会导致CRT线程局部资源泄漏，甚至触发崩溃——因为CRT根本不知道这个线程存在。
• _beginthreadex是CRT为了弥补CreateThread的缺陷封装的函数。它在调用CreateThread创建系统线程之前，会先为该线程分配CRT的线程本地存储（TLS），初始化errno、线程局部变量等CRT环境；线程退出时，还会自动清理这些CRT资源。所以只要你的代码用到了CRT（几乎所有C/C++项目都会用），就必须用_beginthreadex来创建线程，绝对不能直接用CreateThread。

先搞懂DisableThreadLibraryCalls的作用：它告诉Windows系统，当发生DLL加载/卸载、线程附着/分离这些事件时，不要调用当前DLL的DLLMain对应入口点（比如DLL_THREAD_ATTACH、DLL_THREAD_DETACH）。本来是个优化手段，减少不必要的DLLMain调用次数。

但划重点：_beginthreadex创建的线程严重依赖DLL_THREAD_ATTACH通知。CRT在初始化线程环境的时候，需要在DLLMain的DLL_THREAD_ATTACH分支里完成关键的线程本地存储初始化。当你调用了DisableThreadLibraryCalls，Windows就不会给这个DLL发送DLL_THREAD_ATTACH消息了——CRT的线程初始化步骤直接失败，线程自然就没法启动执行，这就是你遇到的问题！

而CreateThread创建的线程因为不依赖CRT，所以DisableThreadLibraryCalls对它完全没影响，只要线程函数里不用CRT，它该跑还是跑。

针对你现在的情况，给你两个明确的解决方向：

1. 直接移除DisableThreadLibraryCalls的调用：这是最稳妥的方案。如果你的DLL用到了CRT（几乎肯定用到了），且用_beginthreadex创建线程，就必须让Windows发送DLL_THREAD_ATTACH给DLLMain，才能保证CRT完成线程初始化。牺牲一点加载性能，换线程正常运行，绝对值得。
2. 如果线程函数完全不依赖CRT，换成CreateThread：如果你的线程函数里只调用Windows原生API（比如SetEvent、WaitForSingleObject这类），完全没用到CRT函数，那可以把_beginthreadex换成CreateThread，这样即使保留DisableThreadLibraryCalls也没问题。不过这种情况在实际项目里很少见，毕竟CRT的工具太常用了。
3. Win64额外注意：Win64的CRT和Win32核心逻辑一致，_beginthreadex依然依赖DLL_THREAD_ATTACH。另外Win64下不用纠结__stdcall/__cdecl的差异，但线程函数的签名要符合要求：unsigned (__stdcall *)(void *)，这一点别搞错。

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