CoCreateInstance 返回 E_NOINTERFACE 的根本原因是接口类型不匹配，而非组件未注册；常见于 C# 中错误使用类对象代替接口、[ComImport] 缺少正确 Guid 或 InterfaceType、或嵌入互操作类型导致版本不兼容。
为什么 CoCreateInstance 总返回 E_NOINTERFACE？
根本原因不是组件没注册，而是你没用对接口。C# 调用 COM 组件时，CoCreateInstance 本身极少直接调用（那是 C++/Win32 的活），你真正该盯住的是 Activator.CreateInstance 或 Marshal.GetActiveObject 的参数是否匹配组件暴露的接口类型。
常见错误现象：System.Runtime.InteropServices.COMException: 检索 COM 类工厂中 CLSID 为 {…} 的组件时失败，原因是出现以下错误: 80040154 —— 这其实是注册表没找着，但报错却像权限或接口问题；而 E_NOINTERFACE (0x80004002) 多半是你传了类对象（Class）却想当接口（Interface）用，或者用了 [ComImport] 但没正确标注 Guid 和 InterfaceType。
- 确保你的
[ComImport]接口声明里有准确的Guid，且和组件 IDL 或 typelib 中定义的一致 - 不要用
new SomeComClass()直接实例化 —— C# 会尝试走 .NET 的构造逻辑，绕过 COM 激活机制 - 若组件支持多线程模型（如 ThreadingModel=Both），但你在单线程上下文（如 WinForms 主线程）里调用它，也容易触发接口不可用
引用类型库后生成的 interop 程序集为什么总抛 InvalidCastException？
这是最常被忽略的隐性坑：.NET 自动生成的 interop 程序集默认启用“嵌入互操作类型”（Embed Interop Types = true），一旦你升级了 COM 组件（比如 Office 补丁更新了 Excel 的 typelib），旧 interop 类型就和新 COM 对象不兼容，运行时强制转换就会崩。
使用场景：调用 Excel、Word、SolidWorks、LabVIEW 等桌面级 COM 应用时尤其高频。
- 在项目引用属性里把对应 interop 程序集的
Embed Interop Types设为 false - 改用显式接口类型而非
dynamic——dynamic看似省事，但会绕过编译期类型检查，把问题拖到运行时才暴露 - 若必须用
dynamic，请加try/catch(COMException)，别指望InvalidCastException能告诉你具体哪个方法挂了
如何安全释放 IDispatch 或其他 COM 对象？
C# 不会自动帮你调 Release，哪怕用了 using —— 因为 COM 对象生命周期不由 GC 控制，而是靠引用计数。不手动释放，轻则内存缓慢上涨，重则 Office 进程卡死不退出。
性能影响：一个未释放的 Excel Application 实例会常驻后台，吃掉 50–100MB 内存，且后续所有新建实例都可能复用这个“僵尸进程”。
- 优先用
Marshal.ReleaseComObject(obj)，而不是Marshal.FinalReleaseComObject—— 后者暴力清零，可能导致其他地方还在用的对象突然失效 - 释放顺序要倒着来：先释放子对象（如
Workbook、Worksheet），再释放父对象（Application） - 释放后立即把变量设为
null，避免误二次释放（ReleaseComObject对 null 会抛异常）
32/64 位不匹配导致 BadImageFormatException 怎么快速定位？
这不是代码写错了，是环境配错了。COM 组件本质是原生 DLL，其位数必须和宿主进程严格一致。你用 AnyCPU 编译的 C# 程序，在 64 位系统上默认跑 64 位模式，但绝大多数传统 COM 组件（尤其是 Office 插件、旧工业软件）只有 32 位版本。
错误信息典型表现：System.BadImageFormatException: 试图加载格式不正确的程序。 (异常来自 HRESULT:0x8007000B)
- 查清楚目标 COM 组件是 32 还是 64 位 —— 用
dumpbin /headers xxx.dll | findstr "machine"最准 - Visual Studio 项目属性 → Build → Platform Target 改成
x86（强制 32 位）或x64（仅当你确认组件是纯 64 位时） - 不要信“AnyCPU + Prefer 32-bit”能兜底 —— Prefer 32-bit 在 Windows Server Core 或某些容器环境下可能被忽略
真正的麻烦往往不在第一次调用，而在你本地调试通过、部署到客户机就崩 —— 因为客户机装的是 64 位 Office，而你测试用的是 32 位，这种环境差异常常藏得深，得从进程架构开始一层层验。
