上周帮同事收拾一个遗留系统的尾巴，对方甩过来一张截图：regsvr32 弹窗写着"模块 xxx.ocx 已加载，但对 DllRegisterServer 的调用失败，错误代码 0x80004005"。看着挺唬人，其实这类问题的排查路径非常固定。ocx 注册这件事，表面上是敲一条 regsvr32 命令，底下牵扯的是 COM 的注册表契约、32 位与 64 位注册表视图的物理隔离、依赖链完整性，以及安装包在什么时机、以什么身份去替你完成注册。这篇文章就把这几层拆开讲清楚：OCX 注册到底改了什么、手工注册怎么保证一次过、vs 安装包怎么配置才能自动安装并注册 ocx、注册失败时怎么顺着错误码一路找到根因，最后再补一个 regsvr32 走不通时的兜底方案。适合做 Windows 桌面开发、工控上位机、老旧 MFC/ATL 项目维护，以及需要做打包部署的同学参考。
顺带先拆一个搜索混淆：很多人在找"vs 安装包自动安装 ocx"的时候，其实脑子里想的是 VS Code。这两件事完全没关系。VS Code 是 Electron 应用，跑在 Chromium 沙箱里，它根本加载不了 OCX 这种进程内 COM 服务器；能加载 OCX 的宿主是 MFC 程序、IE 内核控件容器、Office VBA 里的 CreateObject、或者你自己写的 AtlAxWin 宿主窗口。下面说的"vs 安装包"，指的是 Visual Studio 的 Installer Projects / WiX / Inno Setup 这一条打包链路。
1. DllRegisterServer 背后：OCX 注册到底改了系统里的什么东西
1.1 OCX 与普通 DLL 的分水岭在哪
OCX 的全称是 OLE Control Extension，本质是一个实现了 COM 接口的进程内服务器 DLL。要让 regsvr32 认识它，必须导出四个标准函数：DllRegisterServer、DllUnregisterServer、DllGetClassObject、DllCanUnloadNow。regsvr32 自己其实什么"注册逻辑"都没有，它做的事情极其简单：LoadLibrary把文件加载进内存，GetProcAddress找到DllRegisterServer这个导出，然后调用它；反注册就是换成找DllUnregisterServer。
真正往注册表里写键值的，是你的 OCX 自己，或者链接进来的 ATL/MFC 框架代码。这一点解释了两个特别常见的困惑。第一个，为什么拿 regsvr32 去注册一个普通业务 DLL，会报"找不到入口点 DllRegisterServer"？因为它压根没实现这四个导出。第二个，为什么同一个 OCX 在这台机器上能注册成功，换台机器就失败？因为注册逻辑是编译进控件里的，它依赖的版本号、路径、资源 DLL 全是写死的，环境一变形，注册流程就可能在某一步崩掉。
我的经验是，遇到注册失败，先别急着怀疑系统，先问一句：这个控件是自研的还是第三方买的？自研的可以直接翻源码看DllRegisterServer里干了什么，第三方的基本只能靠工具倒推。
1.2 一次成功注册，注册表里到底多了哪些键
以最常见的 ATL 控件为例，注册成功后大致会落下这么几组键，我把它们的用途整理成一张表，排查残留的时候对着删会很有用：
| 注册表位置 | 典型内容 | 作用 |
|---|---|---|
HKCR\CLSID\{GUID} | 默认值 = ProgID，如MyLib.MyCtrl.1 | 把类 ID 和人类可读的名字关联起来 |
...\CLSID\{GUID}\InprocServer32 | 默认值 = OCX 完整路径，ThreadingModel=Apartment | COM 靠这个键找到物理文件并确定套间模型 |
...\CLSID\{GUID}\ProgID | MyLib.MyCtrl.1 | CreateObject("MyLib.MyCtrl.1")走的就是这条路 |
...\CLSID\{GUID}\TypeLib | 类型库 GUID | 供自动化宿主读取接口签名 |
...\CLSID\{GUID}\Version | 1.0 | 版本标识 |
HKCR\MyLib.MyCtrl\CLSID | {GUID} | ProgID 到 CLSID 的反向映射 |
HKCR\MyLib.MyCtrl.1\CLSID | {GUID} | 带版本号的 ProgID |
HKCR\TypeLib\{TLB GUID}\1.0\0\win32 | OCX 路径 | 类型库的物理位置 |
HKCR\Interface\{IID}\ProxyStubClsid32 | 通常是{00020420-...} | 跨套间/跨进程调用时的封送代理 |
ThreadingModel这一项值得单独说一句。OCX 基本都是Apartment，因为 ActiveX 控件的窗口消息循环天然和 STA 绑定。如果你手上有控件被声明成Free或者Both，放在多线程宿主里跑之前一定要做压力测试，我见过两次因为套间模型和宿主不匹配导致随机崩溃的案例，查了一周才发现是打包时被人手工改过注册表。
1.3 32 位和 64 位：两套注册表视图的物理隔离
这是所有 OCX 注册问题的头号根因，没有之一。
64 位 Windows 上，注册表HKLM\SOFTWARE\Classes实际上被劈成两半：64 位视图就是它本身，32 位视图落在HKLM\SOFTWARE\WOW6432Node\Classes。而HKCR是一个"合成视图"，一个进程读HKCR时看到的是哪一半，取决于这个进程自己是 32 位还是 64 位。
于是就有了两个必须记住的事实：
C:\Windows\System32\regsvr32.exe是64 位版本。C:\Windows\SysWOW64\regsvr32.exe是32 位版本。
SysWOW64里的 WOW 是 "Windows 32-bit on Windows 64-bit" 的缩写，所以它装的是 32 位程序；而System32虽然名字里带 32，装的却是 64 位程序。这个命名坑几乎每个做 Windows 部署的人都栽过一次。
推论就很清楚了：一个 32 位的宿主程序（比如 32 位 Office、32 位的老上位机软件）只能加载 32 位 OCX，只有在 32 位注册表视图里能查到 CLSID 才能创建成功。你拿 64 位 regsvr32 去注册 32 位 OCX，加载阶段就会失败，报出来的往往是"加载失败"或者"找不到入口点"这类容易误导人的文案——别纠结文案，直接查位数。反过来，64 位进程根本不可能加载 32 位 DLL，这是 Windows 加载器的硬性约束。
2. regsvr32 手工注册：参数、依赖与验证的完整链路
2.1 先确定你要注册进哪个视图
动手之前先做判断，顺序如下：打开任务管理器，在"详细信息"里找到将来要加载这个控件的宿主进程，看"平台"列是 32 位还是 64 位；如果宿主还没部署，就看你的编译目标。确定了宿主位数，注册命令的位数也就定了。
注册完之后怎么验证？这里有一个连环坑。在 64 位系统上，如果你用的是 32 位 PowerShell，它读HKLM:\SOFTWARE\Classes会被自动重定向到WOW6432Node，你以为查的是 64 位视图，其实查到的是 32 位视图，结论会完全反过来。所以最稳的做法是显式写全路径：
$guid = '{12345678-1234-1234-1234-1234567890AB}' # 64 位视图（用 64 位 PowerShell 执行） Test-Path "HKLM:\SOFTWARE\Classes\CLSID\$guid\InprocServer32" # 32 位视图，显式走 WOW6432Node，绕开重定向 Test-Path "HKLM:\SOFTWARE\WOW6432Node\Classes\CLSID\$guid\InprocServer32"两条命令都返回True，说明控件在两种位数环境下都能被找到；只返回一条，说明你漏了一半。如果确实需要同时支持 32 位和 64 位宿主，通常要准备两套编译产物，并且给它们分配不同的 ProgID，避免同一台机器上两套注册互相覆盖。
2.2 依赖链没补齐，注册一定失败
DllRegisterServer内部一般会做几件事：读取自身版本资源、加载语言资源 DLL、调用 MFC/ATL/CRT 的运行时代码、写注册表。这里面任何一环缺东西，注册就会中断。
先看运行库对应关系，这是最常见的缺失项：
| 编译工具版本 | 主要依赖 | 备注 |
|---|---|---|
| VC6 | msvcrt.dll | 系统自带，几乎不会缺 |
| VS2005 / 2008 | msvcr80.dll/msvcr90.dll | 需要对应版本的 Redistributable |
| VS2010 / 2012 / 2013 | msvcr100/110/120.dll | 各自独立，不能互相替代 |
| VS2015 - 2022 | vcruntime140.dll、msvcp140.dll | 这几个版本共用同一套 140 系列运行库 |
| 使用 MFC 的控件 | mfc140u.dll、mfc140chs.dll | 注意本地化 MFC 资源 DLL 也要一起装 |
| 使用 ATL 的控件 | atl140.dll | 部分模板会引入 |
这里有个很多人忽略的点：regsvr32 不会去搜索 OCX 自己所在的目录。Windows 加载器的默认搜索顺序是"宿主 EXE 所在目录 → 系统目录 → Windows 目录 → 当前工作目录 → PATH"，注意第一条是宿主 EXE 的目录，不是被加载 DLL 的目录。而 regsvr32.exe 待在System32里，所以它加载你的 OCX 之后，OCX 再去找它同目录下的兄弟 DLL，是找不到的。
解决方案有三个，按推荐程度排：
- 把依赖 DLL 和 OCX 一起放到一个目录，然后写一个几十行的包装 EXE，用
LoadLibraryExW加LOAD_WITH_ALTERED_SEARCH_PATH加载：
// regwrap.cpp —— 编译成对应位数的控制台程序，放在 OCX 同目录 #include <windows.h> #include <cstdio> int wmain(int argc, wchar_t** argv) { if (argc < 2) { wprintf(L"usage: regwrap <ocx> [u]\n"); return 1; } // 关键：LOAD_WITH_ALTERED_SEARCH_PATH 让加载器优先搜索被加载文件的目录 HMODULE h = LoadLibraryExW(argv[1], nullptr, LOAD_WITH_ALTERED_SEARCH_PATH); if (!h) { wprintf(L"LoadLibraryEx failed: %lu\n", GetLastError()); return 2; } const char* proc = (argc >= 3) ? "DllUnregisterServer" : "DllRegisterServer"; typedef HRESULT (WINAPI *PFN)(); PFN fn = (PFN)GetProcAddress(h, proc); if (!fn) { wprintf(L"entry point %hs not found\n", proc); return 3; } HRESULT hr = fn(); wprintf(L"result = 0x%08X\n", (unsigned)hr); FreeLibrary(h); return SUCCEEDED(hr) ? 0 : 4; }这个写法的好处是错误码能原样打出来，比 regsvr32 的弹窗信息量大得多，而且能精确控制加载目录。
把依赖 DLL 放进
System32/SysWOW64，或者放进一个已经在 PATH 里的目录。能用，但会污染系统目录，多个版本的运行库混在一起时容易出乱子，我一般只在应急时用。改用免注册 COM，这一条后面单独展开。
2.3 regsvr32 的参数，哪些真有用
网上抄来抄去的参数不少，实际值得记住的就这几个：
| 参数 | 实际用途 | 注意事项 |
|---|---|---|
| 无参数 | 注册并弹窗提示 | 只能看到成败，看不到错误详情 |
/s | 静默模式，不弹窗 | 安装包里必用；失败时没有任何提示，必须自己取返回码 |
/u | 反注册，调用DllUnregisterServer | 卸载流程里必须配对调用 |
/i | 调用DllInstall而非DllRegisterServer | 少数控件用它做每用户注册 |
/i:参数 | 给DllInstall传字符串参数 | 具体语义由控件自己定义，看厂商文档 |
/n | 不调用DllRegisterServer | 只和/i配合使用 |
/c | 把结果输出到控制台 | 较新版本的 Windows 才支持，老系统上会直接报错 |
有一点必须清楚：regsvr32 弹出来的错误码，是DllRegisterServer的返回值，不是 regsvr32 自己产生的。这意味着同一个0x80004005在不同控件上原因可能完全不同——它就是一个"控件内部出错了"的笼统信号，具体是什么错，得看控件作者在代码里怎么处理异常。
还有一个细节：路径里有空格时必须加引号，regsvr32 /s "C:\Program Files\App\ctrl.ocx"。另外从网络共享路径直接注册，容易被系统安全策略拦掉，稳妥做法是先拷到本地再注册。
2.4 注册完必须做一次真实验证，别信弹窗
弹窗说"注册成功"只代表DllRegisterServer返回了 S_OK，不代表这个控件真能被创建出来。我见过注册表键都写对了，但InprocServer32的路径指向一个不存在的文件，创建实例时报0x80040154 类未注册。
验证分两步。第一步查注册表，用上面那段 PowerShell。第二步真正创建一次实例：
# 用与宿主同一位数的 PowerShell 执行 $obj = New-Object -ComObject "MyLib.MyCtrl.1" $obj | Get-Member -MemberType Method [Runtime.InteropServices.Marshal]::ReleaseComObject($obj) | Out-Null如果宿主是 32 位，这里就必须用C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe。用 64 位 PowerShell 去创建 32 位 COM 组件，报的一定是"无法将 COM 对象转换为..."或者"检索 COM 类工厂失败"，很容易被误判成注册失败，其实是位数不对。VBScript 同理，cscript.exe是 64 位，C:\Windows\SysWOW64\cscript.exe是 32 位，两个都跑一遍就能定位清楚。
3. 让安装包替用户完成注册：vs 打包与几个常见工具的做法
3.1 VS Installer Projects 里 Register 属性怎么选
Visual Studio 自带的 Setup Project（需要单独安装 "Microsoft Visual Studio Installer Projects" 扩展，工程文件是.vdproj）是最省事的方案。在 File System 视图里选中那个 OCX 文件，属性窗口会多出一个Register属性，它有四个取值，含义差别很大：
| 取值 | 含义 | 适用场景 |
|---|---|---|
vsdrfDoNotRegister | 什么都不做 | 纯数据文件、依赖 DLL |
vsdrfCOM | 打包时静态解析类型库，安装时写注册表项 | 接口稳定的简单 COM 组件 |
vsdrfCOMRelativePath | 同上，但写相对路径 | 安装目录会变动的场景 |
vsdrfCOMSelfReg | 安装时调用控件自身的自注册入口 | OCX 应该选这个 |
对 OCX 来说，vsdrfCOMSelfReg是唯一靠谱的选择，因为 OCX 的注册信息里往往有静态解析拿不到的东西，比如运行时才确定的版本号、额外的接口映射。选它之后，MSI 会在安装序列里通过标准的SelfRegModules动作去调用每个标记了自注册的文件的注册入口。
但这里有两个坑必须提前知道。第一，MSI 的自注册动作在安装序列里位置很靠后，如果自注册依赖的某个文件还没落盘，就会失败；解决办法是把 OCX 和它的依赖 DLL 放在同一个 Component 里，靠 MSI 的组件内文件顺序来保证。第二，自注册失败时 MSI 默认会回滚整个安装，用户看到的是"安装失败"而不是"注册失败"，日志在%TEMP%下，要用msiexec /i xxx.msi /l*v install.log才能看到细节。
另外，VS Setup Project 对 64 位的支持一直比较弱。工程属性里有TargetPlatform，要注册到 64 位视图必须设成x64，同时把 OCX 编译成 64 位版本。如果需要在同一台机器上同时支持 32 位和 64 位宿主，我一般干脆做两个 MSI，比在一个包里揉两套位数要省心得多。
3.2 WiX：用 Heat 采集，或者干脆手写注册表项
WiX 是现在做 MSI 的主流选择，注册 OCX 有两条路。
第一条是自动采集。用heat.exe扫文件，它会把类型库里的 COM 信息解析出来，生成<Class>、<ProgId>、<TypeLib>这些元素：
heat.exe file MyControl.ocx -cg OcxComponents -gg -g1 -sfrag -srd ^ -dr INSTALLFOLDER -var var.SourceDir -out OcxHeat.wxs生成出来的片段塞进主工程，安装时由 MSI 直接写注册表，全程不调用DllRegisterServer，速度快、可控。代价是它只能表达静态类型库里有的东西，如果控件在自注册时还写了别的键（比如注册某个 Shell 扩展、注册文件关联），Heat 采集不到。
第二条路是自定义动作，显式调用 regsvr32：
<CustomAction Id="RegisterOcx" FileKey="OcxFile" ExeCommand="/s /c" Execute="deferred" Impersonate="no" Return="check" /> <InstallExecuteSequence> <Custom Action="RegisterOcx" After="InstallFiles">NOT REMOVE</Custom> <Custom Action="UnregisterOcx" Before="RemoveFiles">REMOVE</Custom> </InstallExecuteSequence>Execute="deferred"加上Impersonate="no"是关键组合：延迟执行的自定义动作才能在提权上下文里跑，否则普通用户账户下写 HKLM 会直接吃0x80070005。Return="check"表示注册失败就中断安装并回滚，别设成ignore——我吃过这个亏，设成 ignore 之后安装包显示成功，用户打开软件才发现控件用不了，排查成本翻好几倍。
3.3 Inno Setup 与 NSIS 的静默注册写法
Inno Setup 有一个内建的regserver标志，加上它就不用管注册命令了：
[Files] Source: "MyControl.ocx"; DestDir: "{app}"; Flags: ignoreversion regserver安装时它调用DllRegisterServer，卸载时调用DllUnregisterServer。但它有个致命的限制：注册写入的注册表视图取决于安装程序自身的位数，而 Inno 生成的安装程序默认是 32 位，所以你很难用它把 64 位控件注册到 64 位视图。这种场景我建议放弃regserver，改成显式调用：
[Run] Filename: "{sys}\regsvr32.exe"; \ Parameters: "/s ""{app}\MyControl.ocx"""; \ StatusMsg: "正在注册控件..."; \ Flags: runhidden waituntilterminated Filename: "{syswow64}\regsvr32.exe"; \ Parameters: "/s ""{app}\MyControl32.ocx"""; \ StatusMsg: "正在注册 32 位控件..."; \ Flags: runhidden waituntilterminated用{sys}和{syswow64}两个常量显式指定，不要依赖向导的默认重定向。实际写的时候记得在目标机器上验证一下这两个常量解析出来的路径，不同 Inno 版本对{syswow64}的支持情况略有差异，我就踩过一次{sys}解析到 SysWOW64 的坑。
NSIS 社区用得多的是ExecWait：
SetRegView 64 ; 如果要写 64 位注册表视图 ExecWait '"$SYSDIR\regsvr32.exe" /s "$INSTDIR\MyControl.ocx"' $0 ${If} $0 != 0 MessageBox MB_ICONSTOP "控件注册失败，错误码 $0。请以管理员身份重新运行安装程序。" Abort ${EndIf}务必判断返回码。regsvr32 静默模式下失败也是静默的，退出码非 0 就是失败。NSIS 里$SYSDIR对 32 位安装程序来说指向的是 SysWOW64，需要 64 位 regsvr32 时直接写$WINDIR\System32\regsvr32.exe更稳。另外别忘了卸载时在un.onInit或卸载段里加一次/u反注册，否则用户重装到别的路径时，注册表里会留下一个指向旧路径的僵尸记录。
3.4 64 位目标最容易翻车的三种组合
| 宿主位数 | OCX 位数 | 正确的注册方式 | 常见错误 |
|---|---|---|---|
| 32 位 | 32 位 | SysWOW64\regsvr32，写入 WOW6432Node | 用 System32 的 regsvr32，注册到了 64 位视图 |
| 64 位 | 64 位 | System32\regsvr32，写入 64 位视图 | 安装包 TargetPlatform 没设 x64 |
| 32 位 + 64 位混合 | 两套 | 分别注册，ProgID 分开命名 | 同一个 ProgID 被两个位数的文件抢注，后者覆盖前者 |
第三种情况最容易出问题：同一台机器上，32 位视图和 64 位视图各有一份 ProgID 到 CLSID 的映射，两个 CLSID 必须不同。如果编译时 CLSID 是固定的（很多老项目里 CLSID 是硬编码的 GUID），那么 32 位和 64 位的两份产物就会互相覆盖，最终表现是"某个位数的程序用不了控件，另一个能用"。遇到这种症状，先去查两个视图下的InprocServer32路径是不是一致。
4. 注册失败排查：从错误码一路摸到根因的完整链路
4.1 先把错误码翻译成人话
regsvr32 报的错误码大多是标准 HRESULT，常见的几个我整理了一下：
| 错误码 | 字面含义 | 实际通常指向 |
|---|---|---|
0x80070005 | 拒绝访问 | 权限不足、杀软拦截、文件只读、DEP |
0x8007007E | 找不到指定的模块 | 依赖 DLL 缺失，或位数不匹配 |
0x8007007F | 找不到指定的程序 | 导出函数缺失，控件没实现注册入口 |
0x80004005 | 未指定的错误 | DllRegisterServer内部逻辑抛错，常被代码吞掉细节 |
0x8002801C | 访问 OLE 注册表错误 | 注册表写入被拒，或注册表权限被改坏 |
0x80029C4A | 加载类型库/DLL 失败 | 类型库资源损坏，或依赖的资源 DLL 缺失 |
0x80040154 | 类未注册 | 注册表里查不到这个 CLSID，或路径指向不存在的文件 |
0x80004005是最气人的一个，因为它什么都没说。遇到它，第一件事是确认控件有没有 Debug 版本的DllRegisterServer，能换 Debug 版就换，很多控件在 Debug 下会把具体失败步骤打进 OutputDebugString，用 DbgView 就能看到。
4.2 用现代工具看依赖，别再用 Dependency Walker
depends.exe（Dependency Walker）是 1998 年的工具，在 Windows 10/11 上打开一个稍微现代一点的 DLL，会刷出一大片红字，里面绝大多数是因为 API Set 解析不出来的误报，还有一堆 Delay-Load 的假告警。拿它当第一判断依据，很容易被带偏。
现在更靠谱的是 Dependencies（lucasg 那个开源版本），它能正确处理 API Set，界面也清爽。但说实话，排查注册失败，我更推荐直接用 Process Monitor，因为它一次能看到"依赖加载"和"注册表写入"两条线。
4.3 Process Monitor 抓注册过程：三个过滤器搞定
操作步骤我写一遍，这套流程我用了不下五十次：
- 打开 Procmon，先
Ctrl+X清空当前列表，再Ctrl+L打开过滤器。 - 加第一条：
Process Nameisregsvr32.exe。如果用的是自己写的包装程序，就换成包装程序的进程名。 - 加第二条：
OperationisLoad Image，这条看依赖加载。 - 加第三条：
OperationisRegSetValue，再补一条RegCreateKey，这两条看注册表写入。 Ctrl+E开始捕获，然后在另一个窗口执行注册命令，执行完立刻回来Ctrl+E停止。- 在结果里按
Result列排序，重点看NAME NOT FOUND和ACCESS DENIED。
结果怎么看，我列个对照：
Load Image事件里出现NAME NOT FOUND的 DLL，就是缺失的依赖。注意过滤掉那些"探测性加载"，一个 DLL 通常会先在一个目录下找失败，再去另一个目录找成功，只要有一条SUCCESS就不算缺。RegSetValue事件的Path列里出现WOW6432Node，说明注册写进了 32 位视图；没出现就是 64 位视图。这一条能直接终结"到底注册到哪去了"的争论。RegSetValue结果全是SUCCESS但控件还是用不了，说明问题在注册内容而不是注册动作本身，去比对InprocServer32的路径值对不对。- 出现
ACCESS DENIED，直接看是哪个键、哪个进程身份，基本锁定权限问题。
4.4 权限、杀软、DEP 与文件来源标记
Windows 的 UAC 注册表虚拟化只对"老式、没有 manifest"的 32 位程序生效。regsvr32.exe 是系统自带程序，带 manifest，所以它写 HKLM 被拒时会直接返回ACCESS DENIED，不会帮你悄悄重定向到用户配置单元。这就是为什么"右键以管理员身份运行"能解决相当一部分注册失败——不是玄学，就是因为写 HKLM 需要管理员权限。
杀软和 EDR 是另一类干扰源，症状很典型：同一个安装包，在这台机器上成功，在那台机器上失败；或者反复安装，有时候成功有时候失败，完全没有规律。这类问题用 Procmon 抓到ACCESS DENIED，但键的权限明明是够的，基本就能确认是安全软件拦截。临时关掉安全软件验证一下，能确认就找 IT 加白名单。
还有几个容易被忽略的小点：从网络下载的 OCX 会带 Zone.Identifier 标记，某些策略下加载会受限，用Unblock-File解掉；老控件里如果有自修改代码或者用了老式加壳，DEP 会直接让它崩，表现为0x80070005，这种只能联系厂商更新，不建议为了它去改系统的 DEP 全局设置；安装路径里尽量不要带中文和特殊字符，我遇到过路径里有全角字符导致注册表写入值被截断的情况，虽然罕见但确实存在。
4.5 注册表残留造成的"假成功"，以及怎么清干净
比注册失败更烦的是"注册成功但用不了"，根因通常是残留覆盖。
比较典型的场景：软件从D:\App升级安装到C:\Program Files\App，安装程序只做了覆盖安装，没有先反注册旧路径。结果是注册表里InprocServer32指向旧路径，而旧路径可能已经被删了。这时候regsvr32新路径会显示成功，但创建实例时 COM 找到的是那条旧记录——具体哪条生效取决于写入顺序和键值覆盖，表现就很随机。
排查和清理我一般这么走：
:: 先看这个 CLSID 在两个视图下分别指向哪里 reg query "HKLM\SOFTWARE\Classes\CLSID\{12345678-1234-1234-1234-1234567890AB}" /s reg query "HKLM\SOFTWARE\WOW6432Node\Classes\CLSID\{12345678-1234-1234-1234-1234567890AB}" /s :: 看 ProgID 的反向映射 reg query "HKCR\MyLib.MyCtrl.1" /s确认是残留之后，正确的顺序是：先用旧路径的 OCX 做一次/u反注册（如果文件还在），再用reg delete手工清掉残留的整个 CLSID 子树。删之前一定先导出备份：reg export "HKLM\SOFTWARE\Classes\CLSID\{...}" backup.reg /y。注册表这地方，删错了可能导致整个 COM 子系统某些组件异常，我见过有人误删了系统组建的 CLSID，最后只能重装系统。
清残留还有个更省事的工具思路：用 NirSoft 的 RegDllView 扫一遍系统里所有已注册的 DLL/OCX，它会把每个条目的路径、注册状态列出来，指向不存在文件的条目一眼就能看出来，比手工reg query快得多。
4.6 一套可以照着走的排查顺序
把上面所有内容收束成一个顺序，遇到问题按这个走，基本不会绕圈：
- 看错误码。
0x80070005走权限线，0x8007007E走依赖线，0x80004005走控件内部逻辑线。 - 确认位数。宿主多少位，OCX 多少位，用的哪个 regsvr32，注册进了哪个视图。这四件事没对齐，后面全白搭。
- 确认入口点。用
dumpbin /exports MyControl.ocx看有没有DllRegisterServer。没有的话，说明这个文件根本不是可注册的 COM 组件，可能是个普通业务 DLL 被误当成 OCX 打包了。 - 上 Procmon。抓依赖加载和注册表写入，
NAME NOT FOUND和ACCESS DENIED是两条最直接的线索。 - 提权重试。如果错误码是访问类，用管理员身份再跑一次，能过就说明是权限设计问题，回到安装包里修自定义动作的执行身份。
- 清残留重来。前面都排除了，就把这个 CLSID 相关的注册表项全清掉，重新注册一次。
- 换宿主验证。用同一位数的 PowerShell 或 VBScript 创建一次实例，确认是真能用，而不是只在注册表里好看。
5. 当 regsvr32 彻底走不通：免注册 COM 这条路
5.1 免注册 COM 的工作原理
免注册 COM（Registration-Free COM）的思路是：不往注册表里写任何东西，改用应用程序清单（manifest）在加载时构建一个激活上下文，COM 在这个上下文里查 CLSID，找到就直接加载本地文件。
具体要两个清单。宿主 EXE 的清单里加一段依赖声明：
<dependency> <dependentAssembly> <assemblyIdentity type="win32" name="MyLib.MyCtrl" version="1.0.0.0" processorArchitecture="x86" /> </dependentAssembly> </dependency>控件自己的程序集清单（作为资源嵌进 OCX 里，资源类型RT_MANIFEST，ID 为 2）里声明 COM 类：
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity type="win32" name="MyLib.MyCtrl" version="1.0.0.0" processorArchitecture="x86" /> <file name="MyControl.ocx"> <comClass clsid="{12345678-1234-1234-1234-1234567890AB}" threadingModel="Apartment" progid="MyLib.MyCtrl.1" tlbid="{87654321-4321-4321-4321-BA0987654321}" /> </file> </assembly>两处的assemblyIdentity的name、version、processorArchitecture必须逐字一致，差一个字符就整条链路失效，而且失败时不会给任何提示，只是照样报"类未注册"。这个细节坑过我一次，查了两小时才发现是版本号写成了1.0.0而不是1.0.0.0。
5.2 免注册 COM 的边界在哪
这条路的适用性其实比想象中窄，我列几个必须知道的限制：
- OCX 必须和宿主 EXE 在同一个目录，或者在 EXE 的子目录里，
<file>的name是相对路径。 - 宿主 EXE 的清单要改。也就是说，所有会用这个控件的 EXE 都得改一遍清单，第三方程序你改不了。
- 从 VBScript、Office VBA、PowerShell 里
CreateObject创建的实例，走的是宿主进程（wscript.exe、excel.exe、powershell.exe）的清单，你的清单不起作用。这是最致命的限制，绝大部分"给用户提供一个脚本自动化入口"的需求，免注册 COM 直接判死刑。 - 控件如果依赖
DllRegisterServer写下的额外注册项（文件关联、Shell 扩展、事件日志源等），免注册 COM 完全帮不上忙，那些键还是得写。 - 免注册 COM 不检查哈希，理论上存在 DLL 替换风险，不过本地部署场景下一般不是问题。
5.3 什么时候该果断换路
我的判断标准很简单：如果这个控件的使用者是你自己可控的 EXE，而且没有管理员权限、不能写系统注册表，那就上免注册 COM；如果使用者是不可控的第三方程序，或者需要脚本自动化调用，那就老老实实解决注册问题，别在免注册上浪费生命。
还有一种中间方案是"登录时自动注册"——把注册命令写进计划任务或者开机脚本，用管理员权限跑一遍。这个方案在受控的企业内网环境里其实挺常见，好处是绕开了安装包权限的复杂性，坏处是首屏启动时如果注册还没跑完，用户会先看到一个"控件未注册"的报错。真要用的话，加个重试逻辑和状态文件，别让用户看到失败界面。
我在实际项目里踩过最冤的一次坑，是一个控件的 CLSID 在两个不同版本之间没变，但接口方法签名变了。新旧两版装在同一台机器上，安装顺序决定了最后生效的是哪一版，表现得像"随机崩溃"。后来给每个大版本分配了独立的 CLSID 和 ProgID，才算彻底解决。所以如果你手上也有这种多版本并存的控件，从设计阶段就把 CLSID 的版本策略定下来，比事后补丁便宜得多。
