You upgraded to Windows 11. Now your Excel macros are broken, your VBA code throws compile errors, and workbooks that ran flawlessly for years suddenly do nothing when you click the button. You are not alone — this is one of the most common issues IT teams and power users face after a Windows 11 migration.
The problem is that a Windows 11 upgrade changes multiple things at once: your Office installation may have silently switched from 32-bit to 64-bit, your Trust Center settings may have been reset, library references your VBA code depends on may have vanished, and new security policies may be actively blocking macros and ActiveX controls. Any one of these will break your macros. Most people hit two or three simultaneously.
This guide covers every cause and gives you the exact fix for each one. Work through the diagnostic checklist below, and your macros will be running again.
Before diving into individual fixes, run through this checklist to identify which issues apply to you. Check each item in order — earlier items are more common causes.
Now let's fix each one.
This is the number-one reason VBA breaks after a Windows 11 upgrade. When you install Microsoft 365 or Office 2021 on a fresh Windows 11 system, the installer defaults to 64-bit Office. If your previous Windows 10 machine ran 32-bit Office (which was the default for years), every VBA module with Win32 API Declare statements will fail immediately.
If it says 64-bit and your code was written for 32-bit, you have found the root cause of most of your errors.
You have two options:
Option A: Fix your VBA code for 64-bit compatibility (recommended). This means adding the PtrSafe keyword to every Declare statement and replacing Long with LongPtr for pointer and handle arguments. We cover this in detail in the next section, and our dedicated guide walks through every common API declaration: VBA PtrSafe Fix for Windows 11.
Option B: Reinstall 32-bit Office. You can uninstall your current Office and download the 32-bit version from your Microsoft 365 admin portal (choose "Other install options" > select 32-bit). This avoids code changes but is a temporary solution — Microsoft is moving toward 64-bit as the default across the board.
If you are running 64-bit Office, every Declare Function and Declare Sub statement in your VBA code must include the PtrSafe keyword. Without it, the VBA compiler refuses to even open the module — you get a compile error before any code runs.
"Compile error: The code in this project must be updated for use on 64-bit systems. Review and update Declare statements and then mark them with the PtrSafe attribute."
Declare Function GetTickCount Lib "kernel32" () As Long
Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long
#If VBA7 Then
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
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
The #If VBA7 conditional compilation block ensures your code works on both old and new Office versions. Use LongPtr in place of Long for any argument that represents a pointer, handle, or memory address (like hWnd).
For a full list of common Win32 API declarations and their corrected 64-bit versions, see our detailed guide: VBA PtrSafe Fix for Windows 11.
If you are also seeing "Compile error: Hidden module" when opening the workbook, that usually points to the same PtrSafe issue in a module that Excel cannot display. See Compile Error in Hidden Module — Excel Fix for that specific scenario.
VBA projects reference external libraries (COM/ActiveX DLLs and type libraries) for database access, file operations, and other functionality. When you upgrade to Windows 11 with a new Office installation, some of these libraries change location, change version, or disappear entirely.
| Missing Reference | Replace With |
|---|---|
| Microsoft DAO 3.6 Object Library | Microsoft Office 16.0 Access Database Engine Object Library |
| Microsoft ActiveX Data Objects 2.x | Microsoft ActiveX Data Objects 6.1 Library |
| Microsoft Office 14.0 / 15.0 Object Library | Microsoft Office 16.0 Object Library |
| Microsoft Scripting Runtime (scrrun.dll) | Usually still available — uncheck and re-check to re-register |
| Microsoft Common Dialog Control 6.0 | Not available in 64-bit — replace with Application.FileDialog |
The DAO 3.6 issue is especially common in workbooks that connect to Access databases. For a complete walkthrough of that specific fix, including the code changes required, see Missing DAO Reference Fix for VBA in Excel and Access.
LegacyLeaps scans your Excel files and identifies every compatibility issue automatically — free. PtrSafe errors, broken references, ActiveX problems, format issues — all in one report.
Try the Free ScanWindows 11 upgrades frequently reset Excel's Trust Center to more restrictive defaults. If your macros ran without prompts before and now they silently do nothing, this is probably why.
A better long-term approach for internal workbooks is to add your file directories to Trusted Locations:
Files in Trusted Locations run macros automatically without any prompt or security warning.
If the macro settings are grayed out, your organization's IT department has enforced a Group Policy that controls macro behavior. You will need to contact your IT admin to either adjust the policy or add your files to an approved location. The relevant GPO setting is: User Configuration > Administrative Templates > Microsoft Excel > Trust Center > VBA Macro Notification Settings.
Protected View is a read-only sandbox that prevents macros from running. After a Windows 11 upgrade, files can get flagged as "from the internet" or "from an unsafe location" even if they were always local files. This happens because Windows tracks a hidden NTFS attribute called the Mark of the Web (MOTW), and file copies during the upgrade process can trigger it.
# Unblock all Excel files in a directory
Get-ChildItem -Path "C:\MyWorkbooks" -Recurse -Include *.xls,*.xlsx,*.xlsm |
Unblock-File
If you trust all files on your local machine:
Be cautious with this approach — it reduces security for all files, not just your trusted ones. Trusted Locations (see above) is a safer alternative.
If your workbook uses ActiveX controls — command buttons, combo boxes, list boxes, toggle buttons, or other controls from the Control Toolbox — they may stop working entirely after a Windows 11 upgrade. This happens for two reasons:
If the error is caused by a missing or incompatible OCX/DLL, you need to find a 64-bit version of that component or replace the control with a native VBA alternative. For a full guide to diagnosing and resolving this error, see ActiveX Component Can't Create Object — Fix Guide.
Common replacements for deprecated ActiveX controls:
| Broken ActiveX Control | Native VBA Replacement |
|---|---|
| Common Dialog (comdlg32.ocx) | Application.FileDialog or Application.GetOpenFilename |
| Microsoft Web Browser | Open URL with Shell or use a UserForm with WebBrowser control |
| Microsoft Calendar Control | MonthView control or a custom UserForm date picker |
| Third-party grid controls | ListObject (structured table) or MSForms ListView |
This is more subtle but catches people off guard. If your macro-enabled workbooks are still in the old .xls format (Excel 97-2003), they may behave differently on Windows 11 with modern Office. The .xls format runs in compatibility mode, which can mask certain errors on 32-bit Office but expose them on 64-bit Office.
Additionally, if someone saved a macro-enabled .xls file as .xlsx (without macros) during the upgrade process, all VBA code was silently stripped. The file opens fine, but the macros are simply gone.
.xlsx files cannot contain macros. If your file is .xlsx and you expected macros, they were removed during a save operation..xls, consider converting it to .xlsm to ensure macro-safe handling going forward.For a deeper explanation of what changed between these formats and why it matters, see XLS vs XLSX — What Changed and Why It Matters.
Here is the recommended order of operations to fix everything at once:
PtrSafe keyword and update data types if running 64-bit Office..xls format.The manual process above works fine for one or two workbooks. But if you are an IT team managing a Windows 11 rollout across an organization, you might have dozens, hundreds, or thousands of macro-enabled workbooks that need to be checked and fixed.
Manually opening each file, checking references, searching for Declare statements, and testing ActiveX controls is not feasible at scale. This is exactly the problem LegacyLeaps was built to solve.
LegacyLeaps scans your entire file inventory and produces a detailed compatibility report for every file, identifying:
Declare statement missing PtrSafeFuture Windows updates and Office version changes will continue to introduce compatibility challenges. Here is how to protect your VBA investments going forward:
#If VBA7 Then ... #Else ... #End IfCreateObject("ADODB.Connection") instead of referencing a specific ADODB version)Download LegacyLeaps and scan your Excel files for free. See every VBA compatibility issue in one report — before your users start filing tickets.
Use promo code FIRSTFILE for a free conversion on your first file.
Download Free ScannerPractical fixes for legacy Excel and Access problems. No spam.