VBA Error 48 and 53: Missing References Break Macros After an Office Update

Fix it now

Microsoft publishes 48 as “Error in loading code resource or DLL” and 53 as “File not found”. Neither is about the file you opened: a library the project references has moved, changed architecture or gone. VBA compiles a project as a unit, so one broken reference stops every macro in it.

1. Open the Visual Basic editor with Alt+F11, then Tools > References.
2. Look at the top of the list for entries prefixed MISSING. Write down each name and the path shown against it before you change anything, then untick them.
3. Run Debug > Compile VBAProject. The project has to compile cleanly before any macro will run.
4. If compiling now reports an undefined name that used to work, the reference you unticked supplied it. Tick the current version of the same library, or rewrite that call to use late binding.
5. If Declare statements are involved, confirm each carries PtrSafe and that arguments holding a handle or a pointer are declared LongPtr rather than Long.
6. Close every Office application, then clear the cached control files with a .exd extension from the Forms cache in your profile and from the Office temporary folders, and reopen.

Do not untick a reference you cannot identify. Recovering a lost reference from a stripped project means working out which library supplied each undefined name, one at a time.

If the project compiles and the macros run, you are done. The next section explains what a reference actually is and why one broken one takes everything with it.

Why it happens

A VBA project does not embed the libraries it uses. It stores a pointer to each one: a class identifier, a version, and the path where that library was registered when the project was written. At load time VBA resolves each pointer through the registry. If the entry has gone, or the recorded version no longer exists, the reference resolves to nothing and the editor lists it as MISSING.

The consequence is out of all proportion to the cause, because VBA compiles a project as a single unit. One unresolved reference stops the whole thing, so macros with no connection to the missing library fail, buttons stop responding, and the user reports that every macro broke at once. The published messages describe the layers: 48 is a code resource or DLL that could not be loaded, 53 is a file that was not found, 432 is a file or class name that could not be resolved during an automation operation, and 35 is the compiler reaching a Sub, Function or Property that is not defined because the library that supplied it is gone.

Two more are worth recognising. 49 is “Bad code resource or DLL calling convention”, which is what a Declare statement produces when the declaration does not match the function it is calling. 0x8007007E is Windows error 126, ERROR_MOD_NOT_FOUND, “The specified module could not be found” – and it can mean the library itself is missing or a dependency it in turn needs is. Chasing the named file when the real gap is one level below it is a classic waste of an afternoon.

Full reference

Telling the failures apart

Writing a Declare that works on both architectures

#If VBA7 Then
    #If Win64 Then
        Private Declare PtrSafe Function GetTickCount64 Lib "kernel32" () As LongLong
    #Else
        Private Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
    #End If
#Else
    Private Declare Function GetTickCount Lib "kernel32" () As Long
#End If

VBA7 tests whether the code is running in the newer editor; Win64 tests whether the Office running it is 64-bit. They are two different questions and both are needed, because a 64-bit Office always has VBA7 but a VBA7 editor is not always 64-bit. Microsoft states that an unmodified Declare on 64-bit Office produces an error saying the statement does not include the PtrSafe qualifier, which is the compile-time symptom to expect.

LongPtr, and why it is not just a rename

• LongPtr resolves to Long on 32-bit Office and to LongLong on 64-bit Office. Use it for pointers and handles.
• PtrSafe asserts the declaration has been reviewed for 64-bit. It does not convert anything.
• A handle left as Long on 64-bit is truncated, which corrupts memory rather than raising an error. That is why the failures look like crashes.
• Return values need the same treatment as arguments, and are the ones most often forgotten.

Reference hygiene that stops this recurring

1. Develop on the lowest Office build in use, so references never record a version your users do not have.
2. Prefer native controls to third-party ones wherever a native equivalent exists.
3. Use late binding for anything version-sensitive, and keep the project compiling under early binding while you develop.
4. Compile with Debug > Compile before every release, not just when something breaks.
5. Test on a machine built from your standard image before an update goes out widely.

Registering or unregistering a control writes to the registry and affects every application on the machine, not only Office. Export the relevant branch or take a restore point first, and never unregister a component other software may be using.

Every code this article covers

Confirm the fix worked

1. Run Debug > Compile VBAProject and confirm it completes without stopping.
2. Reopen Tools > References and confirm no entry is marked MISSING.
3. Close Office entirely, reopen the file and run the macro from a cold start rather than from the editor.
4. Open every form in the project, because form failures show up separately from module failures.
5. Test on a second machine built from your standard image, not on the developer’s workstation.

Questions people ask about this