Fixing the 'Must be Updated for Use on 64-bit Systems' VBA Error

intermediate📊 Microsoft Excel2026-07-18| Microsoft Excel 2010, 2013, 2016, 2019, and Microsoft 365 (64-bit versions) on Windows.

Error Message

Compile error: The code in this project must be updated for use on 64-bit systems. Please review and update Declare statements and then
#vba#excel#64-bit#compile-error#api-declaration

The Problem

You’ve likely encountered this error after upgrading your hardware or migrating to Microsoft 365. It happens because 64-bit Office handles memory addresses differently than older 32-bit versions. While 32-bit systems use 4-byte pointers, 64-bit systems use 8-byte pointers.

Your legacy VBA code contains Declare statements designed to call functions from Windows DLLs. Because these older statements aren't built for 64-bit memory addressing, the VBA compiler blocks them to prevent memory corruption or a total Excel crash. The reality is that your code is trying to fit an 8-byte address into a 4-byte bucket.

The Debugging Process

When the error triggers, the VBA Editor usually highlights a specific line starting with Declare. This line is trying to talk to a Windows API, such as user32.dll or kernel32.dll.

To fix this, the 64-bit compiler looks for two specific modifications:

  • The PtrSafe Keyword: This tells VBA, "I have reviewed this code, and it is safe to run in a 64-bit environment."
  • The LongPtr Data Type: This is a dynamic type. It automatically scales to 4 bytes on 32-bit Office and 8 bytes on 64-bit Office.

The Solution: Updating Your Code

1. The Quick Fix (64-bit Only)

If your team exclusively uses 64-bit Office, you can update the syntax directly. Just insert PtrSafe after the Declare keyword.

Legacy 32-bit code:

Declare Function GetTickCount Lib "kernel32" () As Long

Updated 64-bit code:

Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long

2. The Robust Fix (Cross-Platform Compatibility)

In most offices, some users might still be on older installations. You can use conditional compilation to make your macro work for everyone. This uses the #If VBA7 constant, which was introduced with Office 2010 to handle these exact architectural shifts.

#If VBA7 Then
    ' This section runs on Office 2010 and newer (32-bit and 64-bit)
    Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
    Declare PtrSafe Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
#Else
    ' This section runs on Office 2007 and older
    Declare Function GetTickCount Lib "kernel32" () As Long
    Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
#End If

3. Identifying Pointers and Handles

Adding PtrSafe is only half the battle. You must also swap Long for LongPtr for any variable that holds a memory address or a "handle." If you miss these, Excel might crash the moment the function is called.

Look for these common parameters in your API calls:

  • hWnd: Window handles.
  • hDC: Device context handles.
  • lpv or lp: Any variable prefixed with "lp" (Long Pointer).
  • lParam and wParam: Message parameters.

Here is how a complex timer function looks when updated:

#If VBA7 Then
    Declare PtrSafe Function SetTimer Lib "user32" (ByVal hwnd As LongPtr, ByVal nIDEvent As LongPtr, ByVal uElapse As Long, ByVal lpTimerFunc As LongPtr) As LongPtr
#Else
    Declare Function SetTimer Lib "user32" (ByVal hwnd As Long, ByVal nIDEvent As Long, ByVal uElapse As Long, ByVal lpTimerFunc As Long) As Long
#End If

Verification Steps

After updating your code, don't just hope it works. Follow these steps to verify the fix:

  • Open the VBA Editor and go to Debug > Compile VBAProject. If it compiles without a popup, your syntax is valid.
  • Test the macro. If you see a "Type Mismatch" error, you likely converted a standard number (like a counter) to LongPtr when it should have stayed a Long.
  • If possible, open the file on a legacy 32-bit machine. This ensures your #If VBA7 logic doesn't break for other users.

Key Takeaways

  • Long vs. LongPtr: A Long is always 32-bit. A LongPtr is "smart"—it grows to 64-bit when needed. Use LongPtr for anything involving memory addresses.
  • VBA7 vs. Win64: Use #If VBA7 to check for modern Office versions. Use #If Win64 only if you need to write code specifically for the 64-bit environment.
  • Check the Docs: When in doubt, search for the function on Microsoft's Win32 API documentation. If a parameter is listed as a HANDLE or PTR, use LongPtr.

Related Error Notes