MFC程序中DLL与EXE调用COM对象的差异问题排查

1. 消息循环的所有权与完整性差异 #

• MFC EXE是完整的MFC应用，启动时会自动创建CWinApp对象、完成MFC和必要的COM初始化，同时启动持续运行的主线程消息循环。SDK依赖的COM对象（尤其是单线程套间STA模型的）必须依托消息循环来处理跨线程调用请求，没有消息泵的话，COM调用会阻塞等待消息传递。
• 控制台项目即便启用了MFC，它的主线程默认是同步执行逻辑的，没有持续的消息循环。当MFC DLL被调用时，SDK里的某个函数可能在等待COM对象的响应消息，但控制台线程没在处理消息队列，自然就陷入停滞。而窗口能正常显示是因为窗口创建只需要一次性的消息处理，不需要持续的消息泵。

2. COM套间模型的初始化差异 #

• MFC EXE的WinMain入口会自动把主线程设置为单线程套间（STA），这是大多数COM对象要求的运行环境，STA套间必须搭配消息循环才能处理跨线程的COM调用。
• 控制台项目的入口是_tmain，即便启用MFC，也不会自动初始化STA套间并启动消息循环。如果SDK里的COM对象是STA模型，调用时就会因为套间环境不完整、没有消息泵处理调用请求而停滞。

3. MFC模块状态的上下文差异 #

• MFC EXE有独立的CWinApp实例，MFC的模块状态（比如资源、窗口类、COM初始化上下文）是全局稳定的，SDK调用时不需要额外切换上下文。
• MFC DLL分为规则DLL和扩展DLL，如果是规则DLL，它的MFC模块状态需要手动用AFX_MANAGE_STATE宏切换到DLL的上下文。如果调用SDK前没做这个操作，可能导致SDK依赖的MFC相关COM初始化环境不正确，间接引发COM调用阻塞。不过你提到界面正常，这个概率相对低，但可以排查。

4. 窗口句柄的消息关联差异 #

• MFC EXE的窗口句柄完全归属自身的主线程消息循环，SDK如果通过窗口消息和COM对象通信，消息能被及时处理。
• MFC DLL创建的窗口句柄属于控制台宿主的线程，但该线程没有持续处理消息队列，SDK中依赖窗口消息传递的COM通信就会因为消息没人处理而停滞，这也是为什么界面能显示但SDK函数卡住的原因——窗口显示只需要初始的创建消息，而后续的COM相关消息没被处理。

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