写在开头：本篇的排障流程与修复步骤可以直接交给 AI 助手照做，下文可作为核对清单。

Excel「隐藏的模块中的编译错误: SolverCode」

每次启动 Excel 都弹出 「隐藏的模块中的编译错误: SolverCode」，点掉之后其他功能照常，唯独规划求解打不开。

我跑了一遍 Office 联机修复，文件确实被重写了，报错却原地不动。

这类错误的病根往往不在 Office 本体，而在用户级注册表 HKCU\Software\Classes\TypeLib 里残留的类型库注册。

卸载 WPS 一类的第三方套件只删文件不清注册，坏注册一直遮蔽 Excel 的解析。

这篇记录的是这次排障的完整过程——现象 → 根因 → 可复现的定位流程 → 只动 HKCU 的修复 → 验证与回滚——可以作为同类问题的操作参考。

凡是 Office 应用启动时报某个加载项「隐藏的模块中的编译错误」，或带窗体的 VBA 工程突然编译失败，都可以套这个框架排查。

现象与影响面

典型症状有三条，凑齐基本可以断定是同一类问题：

报错固定出现在启动阶段，指向一个从没听说过的「隐藏模块」（SolverCode、ATPVBAEN 之类，其实都是 Office 自带加载项里的 VBA 工程模块）。

联机修复无效，修复程序老实重写了 Program Files 下的文件，报错分文不改。

影响面精准。只有依赖出问题的那个加载项失灵（规划求解在数据选项卡里点不开），Excel 其他功能一切正常。

「隐藏的模块」不是什么神秘东西：规划求解本体是 Office16\Library\SOLVER\SOLVER.XLAM，一个带 VBA 工程的加载宏。

Excel 启动时自动加载它，VBA 工程在首次使用前要整体编译一次，编译需要解析工程引用清单里的每一个 COM 类型库。

任何一个引用解析失败，整个工程编译中断，用户看到的就是那句语焉不详的「隐藏的模块中的编译错误」。

所以排障时要找的是哪个引用解析不了、为什么解析不了，不用围着「模块」本身打转。

根因：HKCU 里的类型库残留

Windows 的 COM 类型库注册存在三处：真实的机器级 HKLM\Software\Classes\TypeLib、用户级 HKCU\Software\Classes\TypeLib，以及系统把它们合并出来的虚拟视图 HKCR。

合并规则是 HKCU 优先。

同一 GUID 两边都注册时，HKCU 的值遮蔽 HKLM。

这个设计本来是给无管理员权限的用户「自带」注册用的，副作用是：任何往 HKCU 写过类型库注册的第三方软件，卸载时如果只删文件不清注册，坏注册就会一直压在好注册上面。

我这次惹祸的就是 WPS：它在 HKCU 写入了它自己的 RefEdit 控件类型库（{00024517-0000-0000-C000-000000000046}，规划求解参数对话框里「目标单元格/可变单元格」折叠框用的控件）。

卸载 WPS 删掉了文件，注册残留仍指向已不存在的 ...\WPS Office\...\refedit.dll。

Excel 加载 SOLVER.XLAM 时按注册解析 RefEdit 1.2，失败码 TYPE_E_CANTLOADLIBRARY 0x80029C4A，工程编译就此中断。

联机修复为什么无效也就好解释了：它只重写 Program Files 下的文件和机器级（HKLM）注册，不清理 HKCU 用户级残留。

而 HKCR 合并视图里 HKCU 优先，坏注册一直遮蔽解析。

修的不是坏的那一层。

除此之外通常还有一批次生损伤要一并处理：HKCU 里堆积的垃圾类型库注册（随机 GUID，指向 %TEMP%\VBE\*.exd 缓存或已卸载程序的路径）、C:\Windows\Temp\VBE 下旧组件留下的 .exd 缓存，Click-to-Run 安装的 Office 还可能存在真实 HKLM 相对 C2R 源仓的投影缺失。

定位流程：让坏注册自己现形

思路：先排除文件与加载项登记问题，再解出加载项的 VBA 工程引用清单，逐个验证引用能否解析，把病灶逼到具体某一个 GUID 上。

flowchart TD
    S0["启动报「隐藏的模块中的编译错误: SolverCode」"] --> S1["1. 查自启动加载项登记（OPEN 系列）"]
    S1 -->|"登记干净"| S2["2. 查文件本体：时间戳与出品方"]
    S2 -->|"文件是好的"| S3["3. 排查其余加载路径"]
    S3 -->|"全部干净"| S4["4. 删 .exd 缓存后重测"]
    S4 -->|"仍报错"| S5["5. 解开 .xlam，解出 VBA 引用清单"]
    S5 --> S6["6. LoadRegTypeLib 逐个验证引用"]
    S6 -->|"仅 RefEdit 1.2 返回 0x80029C4A"| S7["7. HKLM / HKCU / C2R 源仓三处对照"]
    S7 -->|"HKCU 残留指向已删文件"| R["根因确认：HKCU 类型库残留"]

步骤	操作	结果 / 判定
1	查自启动加载项登记：`HKCU\Software\Microsoft\Office\16.0\Excel\Options` 的 `OPEN` 系列值	只指向 Office 自带的 `ANALYS32.XLL`、`SOLVER.XLAM` → 登记干净，问题不在加载项列表
2	查文件本体：`root\Office16\Library\SOLVER\SOLVER.XLAM` 的时间戳与 `docProps/app.xml` 出品方	联机修复当日已重写、Microsoft 出品 → 文件是好的
3	排查其余加载路径：用户 `AddIns`、`XLSTART`（用户与 `ProgramData` 两处）、HKLM 级 `OPEN`、旧版本 Office 键（11.0–15.0）	全部干净 → 排除登记问题
4	删用户 `%APPDATA%\Microsoft\Forms\*.exd` 缓存后重测	仍报错 → 缓存只是表象，排除
5	解开 `.xlam`（实为 ZIP），读 `xl/vbaProject.bin`（OLE 复合文档），按 MS-OVBA 解出 `dir` 流	得到引用清单：stdole、MSForms、RefEdit 控件、MSO；各对话框窗体挂接 RefEdit
6	用 `LoadRegTypeLib` 逐个验证引用（不经 Excel，直接调 oleaut32）	其余全过，RefEdit 1.2 返回 0x80029C4A ← 病灶锁定
7	三处对照：真实 HKLM、HKCU、C2R 源仓 `HKLM\...\ClickToRun\REGISTRY\MACHINE\Software\Classes`	真实 HKLM 无该 GUID；HKCU 有但指向已删文件；C2R 源仓有健康值 → 根因确认

第 6 步是整个流程的关键，也是最便宜的一步。

十几行 Python 就能绕开 Excel 直接问注册表要答案：

1
import ctypes
2
from ctypes import byref
3
from uuid import UUID
4

5
def typelib_ok(guid: str, major: int, minor: int) -> bool:
6
    iid = (ctypes.c_ubyte * 16).from_buffer_copy(UUID(guid).bytes_le)
7
    lib = ctypes.c_void_p()
8
    hr = ctypes.windll.oleaut32.LoadRegTypeLib(iid, major, minor, 0, byref(lib))
9
    return hr == 0
10

11
REFEDIT = "{00024517-0000-0000-C000-000000000046}"
12
print(typelib_ok(REFEDIT, 1, 2))   # False 即注册损坏

定位到可疑 GUID 后，用 reg query 看它到底注册在哪、指向哪个文件，核对路径是否存在：

1
reg query "HKCU\Software\Classes\TypeLib\{00024517-0000-0000-C000-000000000046}" /s

输出里 1.2\0\win64 的默认值就是类型库文件路径。

修复：只动 HKCU，先备份

修复原则有两条。

其一，全部改动落在 HKCU（用户级），不碰 HKLM，无需管理员。

既然坏注册压在 HKCU，把 HKCU 修好或清掉即可，HKLM 本来就是好的。

Click-to-Run 安装的机器上，健康值可以直接从 C2R 源仓读，它相当于微软备份的「标准答案」。

其二，动手前先导出备份，出问题能原路退回：

1
reg export "HKCU\Software\Classes\TypeLib" "%USERPROFILE%\TypeLib_backup.reg" /y
2
reg export "HKCU\Software\Classes\CLSID"   "%USERPROFILE%\CLSID_backup.reg" /y

然后按顺序执行五步：

重建坏注册：删除 HKCU 里指向已卸载程序的 {00024517} 键，从 C2R 源仓读出健康值重建，路径统一改写为本机真实文件（如 C:\Program Files\Microsoft Office\root\Office16\REFEDIT.DLL，win32/win64 都写）。写成 .reg 大致是：
```
1
Windows Registry Editor Version 5.00
2

3
[HKEY_CURRENT_USER\Software\Classes\TypeLib\{00024517-0000-0000-C000-000000000046}\1.2]
4
@="Ref Edit Control"
5

6
[HKEY_CURRENT_USER\Software\Classes\TypeLib\{00024517-0000-0000-C000-000000000046}\1.2\0\win32]
7
@="C:\\Program Files\\Microsoft Office\\root\\Office16\\REFEDIT.DLL"
8

9
[HKEY_CURRENT_USER\Software\Classes\TypeLib\{00024517-0000-0000-C000-000000000046}\1.2\0\win64]
10
@="C:\\Program Files\\Microsoft Office\\root\\Office16\\REFEDIT.DLL"
```
同时确认 HKCU\Software\Classes\CLSID\{00024522}（RefEdit.Ctrl）与其 ProgID 存在。
类型库注册管编译，CLSID 注册管实例化，后者缺失时编译能过、参数对话框照样打不开，是另一个独立病灶。
清理垃圾：遍历 HKCU\Software\Classes\TypeLib，凡默认值指向不存在文件（%TEMP%\VBE\*.exd、已卸载程序路径）的注册逐个删除，不要按名字猜。用「路径是否存在」做唯一判据。
补齐缺失：对照 C2R 源仓与真实 HKLM，缺的类型库用同一套「读健康值 → 改写路径 → 写回 HKCU」的办法补齐，避免下一个加载项踩到同类问题。
清缓存：删掉 C:\Windows\Temp\VBE 与用户 Forms 目录下的旧 .exd 文件，让 Excel 用修复后的注册重新生成。
验证：LoadRegTypeLib 复查全部引用通过后，再进 Excel 做端到端验收。

验证与回滚

验证分两层。

注册层：用上一节的 typelib_ok 把引用清单逐个过一遍，核心引用的修复前后对比大致如下：

引用	GUID	修复前	修复后
Ref Edit Control 1.2	{00024517}	0x80029C4A 失败	0x00000000 ✓
Microsoft Forms 2.0	{0D452EE1}	0x00000000 ✓	0x00000000 ✓
OLE Automation 2.0	{00020430}	0x00000000 ✓	0x00000000 ✓
Microsoft Office (MSO)	{2DF8D04C}	0x00000000 ✓	0x00000000 ✓
Microsoft Excel 16.0	{00020813}	0x00000000 ✓	0x00000000 ✓

应用层做端到端：启动 Excel 无报错；「数据 → 规划求解」能打开参数对话框、RefEdit 折叠框可用。

有个容易忽略的旁证值得检查。

%APPDATA%\Microsoft\Forms\RefEdit.exd 是否被正常重建：修复前这个文件生成不出来，正是 VBA 编译失败的副产品。

它回来了，基本可以确认编译链路已通。

回滚很简单：双击导入修复一节开头导出的两个备份 .reg 即可回到修复前状态。

注意回滚后故障会随之复现，因为回滚的正是修复内容。

这组备份只在修复动作失误时用来退回已知状态，修复完成后没有别的用途。

若日后复发，按清单走：先确认没有再装来路不明的「WPS 兼容组件/VBA 插件」，它们最常往 HKCU\Software\Classes\TypeLib 写坏注册；再用 typelib_ok 复查 {00024517}，非 0 即注册又被破坏；然后重跑一遍修复一节的五步流程（幂等，备份后执行）；实在清不干净，最后才是卸载重装 Office。