我已经阅读了一些CreateProcess
不能从DllMain
函数调用的来源。
创建过程:
不要从 DllMain 函数调用 CreateProcess。这会导致应用程序停止响应。
您永远不应在 DllMain 中执行以下任务: 调用 CreateProcess。创建一个进程可以加载另一个 DLL。
问题
这是为什么?它指出它会导致应用程序停止响应,但这只是一个症状。真正的原因是什么?
我问的原因是我尝试从一个DllMain
函数创建一个进程,它看起来工作得很好。
我已经阅读了一些CreateProcess
不能从DllMain
函数调用的来源。
创建过程:
不要从 DllMain 函数调用 CreateProcess。这会导致应用程序停止响应。
您永远不应在 DllMain 中执行以下任务: 调用 CreateProcess。创建一个进程可以加载另一个 DLL。
这是为什么?它指出它会导致应用程序停止响应,但这只是一个症状。真正的原因是什么?
我问的原因是我尝试从一个DllMain
函数创建一个进程,它看起来工作得很好。
DllMain
在持有加载程序锁时执行。正如您引用的文档所解释的那样,CreateProcess
可能会导致加载 DLL。这可能导致加载程序锁死锁。发生死锁是因为加载程序锁已被持有。
文档很清楚。不要CreateProcess
从DllMain
. 完成工作的标准方法DllMain
是创建一个线程来完成工作。尽管您不能在该线程上等待,因为这会导致完全相同的死锁。
MSDN说:
因此,入口点函数可以调用 Kernel32.dll 中不加载其他 DLL 的函数。[...] 不幸的是,Kernel32.dll 中没有安全函数的完整列表。
然后它扩展了声明,解释更复杂的 API(包括 CreateProcess)可能涉及 usafe API 调用:
调用需要除 Kernel32.dll 之外的 DLL 的函数可能会导致难以诊断的问题。例如,调用 User、Shell 和 COM 函数可能会导致访问冲突错误,因为某些函数会加载其他系统组件。相反,在终止期间调用诸如此类的函数可能会导致访问冲突错误,因为相应的组件可能已经被卸载或未初始化。
这就是最佳实践建议不要调用 CreateProcess 的原因。CreateProcess 是否会加载其他 DLL 是您无法控制的。在你的控制是避免不安全的 API 调用和稍后创建进程。