Compile Error in Hidden Module — How to Fix It in Excel

You opened your Excel workbook this morning and got hit with: "Compile error in hidden module: [ModuleName]"

Nothing works. Your macros are dead. The workbook that ran fine yesterday is now broken. You didn't change anything — so what happened?

This guide explains exactly what this error means, why it appeared, and how to fix it. No fluff. Let's get your file working again.

What "Compile Error in Hidden Module" Actually Means

Your Excel workbook contains VBA code stored in a hidden module. Hidden modules are protected — you can't see or edit them without unprotecting the VBA project first. They're common in add-ins (.xlam), template files, and workbooks built by developers who locked their code.

The error fires because VBA code inside that hidden module cannot compile in your current version of Office. Something the code depends on has changed or disappeared. The VBA runtime catches this at load time and blocks the entire project.

The module name in the error message (like "Module1", "AutoExecNew", "DistMon") tells you where the problem lives. That's your starting point.

Why This Is Happening Now

This error almost always appears after one of these events:

1. 64-bit Office Is Now the Default

Windows 11 installs 64-bit Office by default. If your workbook was built for 32-bit Office, every Declare statement missing the PtrSafe keyword will fail to compile. The VBA runtime won't even try to run the code — it blocks at compile time.

2. Missing PtrSafe on Win32 API Declarations

Legacy VBA code that calls Windows APIs uses Declare Function statements. In 64-bit Office, every one of these needs the PtrSafe keyword. Without it, compile error. No exceptions.

' This breaks on 64-bit Office:
Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
    (ByVal lpClassName As String, ByVal lpWindowName As String) As Long

' This works:
Declare PtrSafe Function FindWindow Lib "user32" Alias "FindWindowA" _
    (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr

3. Deprecated APIs Removed by Windows Updates

Microsoft has been removing deprecated Windows APIs and COM libraries. Code that called these functions compiled fine on Windows 10 but fails on Windows 11 after cumulative updates strip the libraries out.

4. ActiveX Controls Gone

Some ActiveX controls that shipped with older Office versions are no longer included. If VBA code references a control that doesn't exist on your system, the reference breaks and the module can't compile.

5. Office 365 Auto-Updates

Office 365 updates itself silently. A Tuesday update can remove a library or change a type library version. Your workbook didn't change — Office did.

Step-by-Step Fix

Step 1: Open the VBA Editor

Press Alt+F11 to open the Visual Basic Editor. If you get the compile error dialog again, click OK to dismiss it.

Step 2: Check for Missing References

This is the most common cause and the easiest fix.

1. Go to Tools > References
2. Look for any item marked "MISSING:" at the top of the list
3. Uncheck the missing reference
4. If you know the replacement library, check it instead
5. Click OK

Common culprits:

• MISSING: Microsoft ActiveX Data Objects 2.x Library — replace with the latest version (usually 6.1)
• MISSING: Microsoft Office 15.0 Object Library — check the version that matches your current Office
• MISSING: Microsoft Forms 2.0 Object Library — this one appears when FM20.dll is missing or corrupted

After unchecking or replacing the broken reference, try Debug > Compile VBAProject. If it compiles clean, you're done.

Step 3: Find Declare Statements Missing PtrSafe

If the compile still fails, the problem is in the code itself. Use Ctrl+F and search for Declare Function and Declare Sub across the entire project.

Every declaration must have PtrSafe between Declare and Function/Sub:

' Wrong (64-bit Office will reject this):
Declare Function GetTickCount Lib "kernel32" () As Long

' Right:
Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long

Step 4: Change Long to LongPtr for Pointer Arguments

Adding PtrSafe gets you past the compile error, but you're not done. Any parameter that holds a window handle, memory pointer, or instance handle must change from Long to LongPtr.

' Before:
Declare PtrSafe Function SendMessage Lib "user32" Alias "SendMessageA" _
    (ByVal hWnd As Long, ByVal wMsg As Long, _
     ByVal wParam As Long, lParam As Any) As Long

' After (correct for 64-bit):
Declare PtrSafe Function SendMessage Lib "user32" Alias "SendMessageA" _
    (ByVal hWnd As LongPtr, ByVal wMsg As Long, _
     ByVal wParam As LongPtr, lParam As Any) As LongPtr

The rule is simple: handles and pointers get LongPtr. Counts, flags, and constants stay Long.

Don't forget variables that store these values:

' Also fix the variables:
Dim hWnd As LongPtr    ' was: Dim hWnd As Long
hWnd = FindWindow("XLMAIN", vbNullString)

Step 5: Replace Deprecated API Calls

Some APIs no longer exist in Windows 11. Common ones that break:

• SetWindowLong — replace with SetWindowLongPtr
• GetWindowLong — replace with GetWindowLongPtr
• References to MSCOMCTL.OCX (Common Controls) — often missing after Office updates
• References to MSCOMCT2.OCX (Date Picker, etc.) — removed from modern Office

After making changes, run Debug > Compile VBAProject again. Repeat until it compiles clean.

Common Triggers at a Glance

What Changed	What Breaks	Fix
Windows 11 update	Removed ActiveX controls, deprecated DLLs	Replace missing references, update API calls
Office upgrade (32-bit to 64-bit)	All Declare statements without PtrSafe	Add PtrSafe, convert Long to LongPtr
Office 365 auto-update	Type library version changes	Update reference to current version
New PC with Windows 11	All of the above simultaneously	Full VBA compatibility pass

The Manual Fix vs. the Automated Fix

If your workbook has 2-3 declarations in one module, you can fix this in ten minutes. Follow the steps above and you're done.

But that's rarely the real-world scenario. Here's what legacy Excel files actually look like:

• 20+ modules with Declare statements scattered everywhere
• Hidden and protected modules you need to unlock first
• Dozens of variables storing handles that all need Long-to-LongPtr conversion
• Third-party add-in code pasted in years ago that nobody understands
• Multiple workbooks — not one file, but an entire library of broken .xlsm files

Going line by line is tedious and error-prone. Miss one handle variable and you get silent data corruption that surfaces weeks later as a random crash.

LegacyLeaps automates this entire process. Upload your file, get a detailed report of every issue found, and download a fixed version with all PtrSafe keywords added, all pointer types corrected, and all deprecated references resolved.

FAQ

What does "Compile error in hidden module" mean in Excel?

It means VBA code stored in a protected (hidden) module inside your workbook or add-in cannot compile in your current version of Office. The code references something that no longer exists — a missing library, an outdated API call, or a Declare statement incompatible with 64-bit Office.

Why did this error appear after a Windows update?

Windows updates frequently change Office components, remove deprecated ActiveX controls, or switch Office from 32-bit to 64-bit. Any of these changes can break VBA code that compiled fine before the update, especially code in hidden modules that references external libraries or Win32 APIs.

How do I find which module has the compile error?

Open the VBA Editor with Alt+F11, then go to Debug > Compile VBAProject. Excel will highlight the exact module and line causing the error. If the module is hidden, you may need to unprotect the VBA project first (Tools > VBAProject Properties > Protection tab).

Can I fix this error without knowing VBA?

For simple cases like missing references, yes — you can uncheck the broken reference in Tools > References without writing any code. For deeper issues like PtrSafe declarations or deprecated API calls, you either need VBA knowledge or an automated tool like LegacyLeaps that scans and fixes the code for you.

Will this error go away if I reinstall Office?

Usually not. The error is caused by incompatible VBA code inside your file, not by a corrupt Office installation. Reinstalling Office won't change the code in your workbook. The fix must happen inside the VBA project itself — either by updating references, adding PtrSafe keywords, or replacing deprecated API calls.

← Back to all posts