Note up front: the diagnosis flow and fix steps here can be handed to an AI assistant to follow directly; the text below serves as the checklist.

Excel “Compile error in hidden module: SolverCode”

Every time Excel starts it throws “Compile error in hidden module: SolverCode”; dismiss it and everything else works, except that Solver won’t open.

I ran an Office online repair; the files really were rewritten, yet the error stayed exactly where it was.

The root of this class of error usually isn’t Office itself but a leftover type library registration under the per-user key HKCU\Software\Classes\TypeLib.

Uninstalling WPS or a similar third-party suite deletes files without clearing the registry, and the bad registration keeps shadowing Excel’s resolution.

This post records the complete troubleshooting session — symptom → root cause → reproducible diagnosis → a fix that touches only HKCU → verification and rollback — as a reference for similar cases.

Whenever an Office app reports a “compile error in hidden module” for some add-in at startup, or a VBA project with forms suddenly fails to compile, this framework applies.

Symptoms and blast radius

Three typical symptoms; together they make the diagnosis near certain:

The error always appears at startup, pointing at a “hidden module” you have never heard of (SolverCode, ATPVBAEN and the like are all VBA project modules inside Office’s own add-ins).

Online repair changes nothing; the repair tool dutifully rewrites the files under Program Files and the error doesn’t budge.

The blast radius is precise. Only the add-in that depends on the broken thing fails (Solver won’t open from the Data tab); the rest of Excel is perfectly normal.

The “hidden module” is nothing mysterious: Solver itself is Office16\Library\SOLVER\SOLVER.XLAM, an add-in macro with a VBA project.

Excel loads it automatically at startup, and a VBA project is compiled as a whole before its first use; compiling requires resolving every COM type library in the project’s reference list.

Any single reference that fails to resolve aborts the whole compile, and what the user sees is that vague “compile error in hidden module”.

So when diagnosing, look for which reference fails to resolve and why; there is no need to chase the “module” itself.

Root cause: type library leftovers in HKCU

COM type library registration on Windows lives in three places: the real machine-level HKLM\Software\Classes\TypeLib, the per-user HKCU\Software\Classes\TypeLib, and the merged virtual view HKCR the system builds from them.

The merge rule gives HKCU priority.

When the same GUID is registered on both sides, the HKCU value shadows HKLM.

The design lets users without admin rights “bring their own” registration; the side effect is that any third-party software writing a type library registration into HKCU, then getting uninstalled with files deleted but registry left behind, keeps that broken registration pressed on top of the good one.

In my case the culprit was WPS: it had written its own RefEdit control type library into HKCU ({00024517-0000-0000-C000-000000000046}, the control behind the “Target cell / Variable cells” collapsible boxes in Solver’s parameter dialog).

Uninstalling WPS deleted the files, but the leftover registration still points at a ...\WPS Office\...\refedit.dll that no longer exists.

When Excel loads SOLVER.XLAM it resolves RefEdit 1.2 through the registry, gets TYPE_E_CANTLOADLIBRARY 0x80029C4A, and compilation stops there.

That also explains why online repair does nothing: it only rewrites files under Program Files and machine-level (HKLM) registration, never cleaning per-user HKCU leftovers.

And in the merged HKCR view HKCU wins, so the bad registration keeps shadowing resolution.

The layer being repaired was not the broken one.

Beyond that there is usually a batch of collateral damage to handle as well: junk type library registrations piled up in HKCU (random GUIDs pointing at %TEMP%\VBE\*.exd caches or paths of uninstalled programs), stale .exd caches left by old components under C:\Windows\Temp\VBE, and on Click-to-Run installs of Office possibly a missing projection of the real HKLM against the C2R source store.

Diagnosis: let the bad registration show itself

Approach: rule out file and add-in registration problems first, then extract the add-in’s VBA project reference list, verify each reference in turn, and corner the fault onto one specific GUID.

flowchart TD
    S0["Startup shows Compile error in hidden module: SolverCode"] --> S1["1. Check add-in registration at startup (OPEN values)"]
    S1 -->|"registration clean"| S2["2. Check the file itself: timestamp and publisher"]
    S2 -->|"file is good"| S3["3. Check the other load paths"]
    S3 -->|"all clean"| S4["4. Delete .exd caches and retest"]
    S4 -->|"still failing"| S5["5. Unpack the .xlam, extract the VBA reference list"]
    S5 --> S6["6. LoadRegTypeLib, verify each reference"]
    S6 -->|"only RefEdit 1.2 returns 0x80029C4A"| S7["7. Compare HKLM / HKCU / C2R source store"]
    S7 -->|"HKCU leftover points at a deleted file"| R["Root cause confirmed: HKCU type library leftover"]

Step 6 is the key to the whole flow, and the cheapest one.

A dozen lines of Python bypass Excel and ask the registry directly:

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 means the registration is broken

Once a suspicious GUID is found, use reg query to see where it is registered and which file it points at, then check whether that path exists:

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

The default value of 1.2\0\win64 in the output is the type library file path.

Fix: touch only HKCU, back up first

Two principles.

First, every change lands in HKCU (per-user), nothing touches HKLM, no administrator needed.

Since the bad registration sits on top in HKCU, fixing or clearing HKCU is enough; HKLM was fine all along.

On a Click-to-Run machine the healthy values can be read straight from the C2R source store, which is effectively Microsoft’s own backup of the correct answer.

Second, export a backup before touching anything, so a problem can be walked back:

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

Then run five steps in order:

1. Rebuild the bad registration: delete the {00024517} key in HKCU that points at the uninstalled program, read the healthy values from the C2R source store and rebuild, rewriting all paths to the real files on this machine (e.g. C:\Program Files\Microsoft Office\root\Office16\REFEDIT.DLL, for both win32 and win64). As a .reg file it looks roughly like:

   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"

   Also confirm HKCU\Software\Classes\CLSID\{00024522} (RefEdit.Ctrl) and its ProgID exist.

   Type library registration governs compilation, CLSID registration governs instantiation; when the latter is missing, compilation passes and the parameter dialog still won’t open — a separate fault of its own.

2. Clean the junk: walk HKCU\Software\Classes\TypeLib and delete every registration whose default value points at a nonexistent file (%TEMP%\VBE\*.exd, paths of uninstalled programs), one by one; don’t guess from names. “Does the path exist” is the only criterion.

3. Fill the gaps: compare against the C2R source store and the real HKLM, and top up missing type libraries with the same “read the healthy value → rewrite the path → write into HKCU” method, so the next add-in doesn’t hit the same problem.

4. Clear caches: delete the old .exd files under C:\Windows\Temp\VBE and in the user Forms directory, so Excel regenerates them from the repaired registration.

5. Verify: recheck every reference with LoadRegTypeLib, then do end-to-end acceptance in Excel.

Verification and rollback

Verification has two layers.

Registry layer: run the reference list through typelib_ok from the previous section; before and after for the core references look roughly like this:

Application layer, end to end: Excel starts with no error; Data → Solver opens the parameter dialog and the RefEdit collapsible box works.

There is one easily missed corroboration worth checking.

Whether %APPDATA%\Microsoft\Forms\RefEdit.exd gets rebuilt normally: before the fix this file could not be produced at all, a side effect of the VBA compile failing.

If it is back, the compile chain is almost certainly through.

Rollback is simple: double-click and import the two backup .reg files exported at the start of the fix section, and the pre-fix state returns.

Note that the failure returns with the rollback, because what got rolled back is exactly the fix.

These backups exist only to return you to a known state when a fix goes wrong; once the fix succeeds they have no other use.

If it recurs later, walk the checklist: first confirm no more “WPS compatibility component / VBA plugin” of unknown provenance got installed — those are the most common writers of bad registrations under HKCU\Software\Classes\TypeLib; then recheck {00024517} with typelib_ok, where a nonzero result means the registration is broken again; then rerun the five steps of the fix section (idempotent, run after backing up); and only if it cannot be cleaned, uninstall and reinstall Office as the last resort.

Closing notes

Looking back at my own case, these are the three things worth remembering:

What the error message says and what is broken are usually not the same thing. “Compile error in hidden module” is broken by one type library reference in the registry.

Online repair only fixes the layer it can see. Program Files and HKLM; per-user HKCU leftovers are permanently outside its range.

The core diagnostic move is to bypass the app and verify the references directly. One LoadRegTypeLib call turns “which GUID is broken” from a guess into a fact.

On machines that have installed and uninstalled WPS or another Office-compatible suite, HKCU almost certainly has leftovers; cleaning early is cleaning cheap.

And for any “after uninstalling one program, another started reporting strange errors”, take a look at HKCU\Software\Classes first — it often saves an afternoon compared to reinstalling.

Thanks for reading! Follow me if you'd like~

Excel SolverCode Fix

Fri Oct 02 2026

1740 words · 10 minutes

NotesWindowsOffice

---

© MuxiaoWF | CC BY-NC-SA 4.0

Share

Share this article

X (Twitter)TelegramRedditFacebookEmailQQ

Close

Close