VB6调用64位COM DLL反向调32位类库报Class not registered错误

你期望的「32位VB6主程序→64位COM DLL→32位VB6类库生成结果对象→回传32位主程序」链路，无法通过直接给32位VB6类库配置反向DLL Surrogate实现，报错本质不是注册配置缺失，是COM跨架构封送和VB6运行时的原生硬限制，和配置的正确性无关。

核心报错根因 #

• 你之前实现的32位VB6调用64位COM能正常运行，是因为系统将64位COM加载到独立的64位dllhost.exe代理进程，两个进程通过COM原生RPC封送完成跨架构通信，这个调用方向是系统原生支持的。
• 反向调用时出现Class not registered的三个核心原因：
  • VB6编译的32位COM类全部依赖32位版本的VB6运行时，且绝大多数没有自定义代理/存根，仅依赖32位版本的IDispatch通用封送逻辑；64位进程尝试激活32位VB6类时，系统找不到匹配64位环境的封送组件，会直接抛出类未注册错误，和类是否真的注册无关。
  • 就算手动补全注册表配置强行拉起32位Surrogate进程，跨架构回传的VB6对象本质是跨进程代理，在64位DLL侧对对象做属性赋值、方法调用都会产生RPC通信开销，复杂嵌套对象的封送极容易出现类型不匹配、内存访问违规的稳定性问题。
  • 多数人配置反向Surrogate失败的直接原因是搞错了注册表视图：32位COM的注册信息默认存在HKCR\Wow6432Node路径下（32位注册表视图），64位进程只会读取HKCR根路径下的原生64位注册表项，仅在32位视图下加Surrogate配置对64位进程完全无效。

可行落地方案 #

按改造成本从低到高排序：

• 方案1：调整对象构建边界，绕开反向跨架构实例化（首选方案，适配成本最低）
  不要让64位COM DLL直接实例化32位VB6结果类，把对象创建逻辑挪回32位VB6侧：64位DLL只负责调用下游服务、计算生成原始结果数据，通过基础类型、定长结构体、序列化字符串或者自定义的纯数据COM接口把原始结果返回给VB6主程序，由VB6主程序自行实例化本地的结果类、填充字段后使用。

  实操提示：如果结果字段较多，可以直接在64位COM侧定义和VB6结果类字段完全对齐的纯数据接口，不要复用VB6类库的原有类型定义，完全规避跨架构类型匹配问题，该方案没有额外的跨进程开销，稳定性最高。

• 方案2：增加32位轻量代理COM层（适配必须在64位侧触发对象构建的场景）
  单独开发一个逻辑极简的32位COM组件，正确配置64位注册表视图下的DllSurrogate项，保证64位进程可以正常激活该组件。这个代理组件的唯一作用是：接收64位DLL传入的原始结果数据，在32位进程内实例化原有VB6结果类、填充完所有字段后，再将完整的对象接口回传给64位DLL，最终返回给32位VB6主程序。
  注意该方案下跨进程传递的是COM代理，不要在64位侧对返回的VB6对象做细粒度的属性、方法调用，必须在32位代理进程内完成所有对象构建操作，减少跨进程RPC调用次数，避免封送错误。
• 方案3：抽离共享接口定义（长期维护方案）
  将原归属VB6类库的复杂结果对象的接口定义，通过IDL单独抽离，分别编译32位、64位版本的代理/存根DLL注册到系统，实现接口与实现分离：32位侧、64位侧都可以基于同一套接口实现对象逻辑，跨架构传递时系统可以通过标准封送器自动完成序列化/反序列化，从根本上解决跨架构类型匹配问题。

避坑提示 #

• 不要尝试修改注册项让32位VB6类在64位进程内直接加载，VB6运行时只有32位版本，永远不可能在64位进程地址空间内运行，所有跨位数COM调用必须走独立代理进程。
• 调试类未注册问题时，要分别用32位、64位版本的OLE View工具检查对应架构下的类注册项：只有对应架构下能查看到的CLSID，才能被该架构的进程正常激活。

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