COM本地EXE服务器未知接口实现问题求助

核心问题复盘 #

• 项目基于VS2022，包含COMBasics（COM客户端）、COMServer（LOCAL_SERVER模式COM服务器）、SampleInterfaces（共享接口静态库）
• 编译需为客户端和服务器配置SampleInterfaces的头文件目录
• 现象：LOCAL_SERVER模式下客户端控制台两次输出“Interface not supported”，INPROC_SERVER模式完全正常
• 已完成操作：按StackOverflow相关方案，通过动态创建TypeInfo、CreateStdDispatch实现IDispatch，并在Computer::QueryInterface中委托该实现，但调试发现COM从未发起IID_IDispatch的查询请求

排查与解决方向 #

1. 确认代理/存根（Proxy/Stub）的实现与注册 #

跨进程LOCAL_SERVER调用依赖代理/存根完成接口数据封送，INPROC_SERVER模式无需此环节，这是两类模式的核心差异：

• 检查SampleInterfaces中的接口IDL是否标记了[dual]或[oleautomation]属性，确保能生成支持自动化的类型库（.tlb）
• 若使用ATL框架，确认是否存在对应的Proxy/Stub项目，已编译并通过regsvr32完成注册；手动实现的话，需用midl编译IDL生成代理存根代码，编译为DLL后注册
• 用OLEView工具查看服务器注册表项，确认目标接口的HKCR\Interfaces\{接口IID}下ProxyStubClsid32值是否正确指向代理/存根DLL的CLSID

2. 校验接口注册表信息完整性 #

LOCAL_SERVER模式下COM依赖注册表获取接口封送信息，注册错误会直接导致跨进程接口请求失败：

• 检查服务器注册后，接口对应的注册表项是否存在ProxyStubClsid32字段，且值有效
• 确保类型库已注册：使用regtlibv12.exe注册生成的.tlb文件，保证客户端能正确读取接口类型信息

3. 排查QueryInterface实现逻辑 #

即使已实现IDispatch，跨进程场景下COM可能先请求其他关键接口，需确保基础实现无问题：

• 确认Computer::QueryInterface中IUnknown的引用计数处理正确，所有接口查询都遵循COM规范
• 若未配置代理/存根，COM会主动请求IMarshal接口以实现自定义封送，此时若对象未实现IMarshal，会直接触发“Interface not supported”错误，需补充该接口实现或修复代理/存根配置
• 可在QueryInterface中手动添加IID_IDispatch的分支逻辑，验证返回的IDispatch实例是否正常，排除实现本身的问题

4. 验证类型库与TypeInfo的正确性 #

动态创建TypeInfo的过程若存在问题，会导致IDispatch无法被COM识别：

• 用OLEView打开.tlb文件，确认接口的IDispatch继承关系、方法DISPID定义均符合规范
• 检查CreateStdDispatch调用时传入的TypeInfo指针是否有效，避免空指针或无效类型信息导致的隐性错误

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