Runtime Error 364: “Object was unloaded,” explained and fixed
Error 364, “Object was unloaded”, means code touched a form or object that used to exist and has been unloaded. A variable still holds the reference, a queued event fires late, or a second procedure assumes a window is still open after the user closed it. The reference is real and the object is gone; VBA raises error 364 the moment the code tries to use it. It is a lifetime bug, the object-oriented cousin of using a file after Close.
For people who just run the program
- Expect it around closing windows. Typing in a window while it is being closed by another action, or a background refresh landing just after a form closes, are the typical moments.
- Note whether it follows a close or a cancel. If the error reliably appears right after dismissing a particular dialog, tell the maintainer which one; that dialog's close path is where the stale reference lives.
- Restart the program if it recurs in the same session. Stale references live in the running process; a fresh start clears them, though the underlying bug stays for the developer to fix.
- Do not lose work over it. Save documents in other windows before restarting; the error is about the program's internal bookkeeping, not about document data.
For people who write the code
- Set references to Nothing at unload. When code unloads a form it owns, clear the variables pointing at it in the same breath, and treat “reference Is Nothing” as the one true loaded check:
Unload frmSearch
Set frmSearch = Nothing
' Later use must now test: If Not frmSearch Is Nothing Then ...
' Without the Set to Nothing, the stale reference raises error 364.
- Guard event handlers against teardown. Events queued before unload can fire after it. A simple “closing” flag checked at the top of handlers, set in QueryUnload, stops late events from touching a dying form.
- Recheck after any modal interaction. Code that shows a dialog and then uses the caller form assumes the caller survived; users close things. Test the reference again after control returns from any Show or DoEvents.
Referencing a form's default instance resurrects it silently. Code that avoids error 364 by touching the default instance may instead be quietly loading a fresh copy of the form and operating on that, which converts a clear error into wrong-window bugs. Know which model each form uses.
If it still happens
If no Unload explains it, the object may have been destroyed by its owner: a control removed when its container form closed, or an object from a library whose session ended. Trace the owner's lifetime, not just the reference; the fix is to keep the owner alive or recreate the object after the owner restarts.
Common questions
How is error 364 different from error 91? Error 91 means the object variable was never set (it is Nothing). Error 364 means it was set, the object existed, and then the object was unloaded while the reference remained.
Can an event really fire after a form unloads? Yes. Timer events and asynchronous notifications queued before the unload can be delivered during teardown, which is why a closing flag in handlers is standard practice.
Related errors