You installed a Windows update — maybe a cumulative patch, maybe a full OS upgrade to Windows 11 — and now the Excel workbook your team has relied on for years throws errors the moment you click a button. The macro is disabled, a compile error pops up, or you get a cryptic "Automation error" with no useful details.
This is extremely common. Windows updates frequently change security policies, remove legacy components, and shift Office from 32-bit to 64-bit — all of which can break Excel macros that were working fine the day before. The good news: every one of these problems has a specific cause and a specific fix.
This guide covers the five most common reasons an Excel macro breaks after a Windows update, how to diagnose which one you're hitting, and how to fix each one.
Before diving into causes, here's a quick reference for the errors you're most likely seeing:
| Symptom | Most Likely Cause |
|---|---|
| "Macros have been disabled" | Macro security policy change |
| "Compile error: Can't find project or library" | Missing or broken VBA reference |
| "Compile error: Type mismatch" on Declare statements | 32-bit to 64-bit Office transition |
| "Automation error" or "Error 429: ActiveX component can't create object" | Deprecated ActiveX control or Windows API change |
| Yellow "Security Warning" bar that won't go away | Mark of the Web blocking |
| "Compile error: The code in this project must be updated for use on 64-bit systems" | Missing PtrSafe keyword |
Microsoft has been steadily tightening macro security. Starting in 2022, Office began blocking VBA macros by default in files downloaded from the internet. Subsequent Windows and Office updates have expanded this policy. If your workbook was emailed to someone, downloaded from SharePoint, or copied from a network share that Windows doesn't trust, macros may be silently blocked with no option to enable them.
Open the file. If you see a yellow or red banner at the top saying "Macros have been disabled" or "SECURITY RISK: Microsoft has blocked macros from running," this is your problem. Right-click the file in File Explorer, choose Properties, and look for a line at the bottom that says "This file came from another computer and might be blocked." That's the Mark of the Web (MOTW) flag.
For a single file:
For a folder of trusted workbooks:
C:\BusinessTools\)To unblock multiple files at once via PowerShell:
Get-ChildItem -Path "C:\BusinessTools\*.xlsm" -Recurse |
Unblock-FileDo not lower the Trust Center macro security setting to "Enable all macros" — that disables protection for every file, not just yours. Trusted Locations is the correct, targeted approach.
VBA projects reference external libraries — things like the Microsoft Scripting Runtime, Microsoft ActiveX Data Objects, or the Office Object Library. When Windows or Office updates, the specific version of these libraries on your machine can change. If a VBA project references version 2.5 of ADODB but version 6.1 is now installed, the old reference breaks and every line of code that uses it fails to compile.
A missing reference causes a cascade: every function, object, or constant from that library becomes unresolvable. You'll see "Compile error: Can't find project or library" even on lines that look perfectly fine.
Common reference updates after a Windows/Office update:
| Old Reference | Replacement |
|---|---|
| Microsoft ActiveX Data Objects 2.5 | Microsoft ActiveX Data Objects 6.1 Library |
| Microsoft Scripting Runtime (older) | Microsoft Scripting Runtime (current — same name, newer DLL) |
| Microsoft Office 14.0 Object Library | Microsoft Office 16.0 Object Library |
| Microsoft DAO 3.6 Object Library | Microsoft Office 16.0 Access Database Engine Object Library |
Pro tip: If you want your VBA code to be resilient to reference version changes, use late binding instead of early binding. Replace typed declarations with CreateObject calls:
' Early binding (breaks when reference version changes):
Dim fso As Scripting.FileSystemObject
Set fso = New Scripting.FileSystemObject
' Late binding (works regardless of library version):
Dim fso As Object
Set fso = CreateObject("Scripting.FileSystemObject")Late binding doesn't require the reference at all, so version mismatches become irrelevant. The tradeoff is that you lose IntelliSense in the VBA editor.
For years, Microsoft defaulted to installing the 32-bit version of Office even on 64-bit Windows. Starting with Office 2019 and Microsoft 365, the default changed to 64-bit Office. A Windows update that triggers an Office reinstall or upgrade can silently switch you from 32-bit to 64-bit — and that breaks any VBA code that calls Windows APIs.
The 64-bit VBA environment requires every Declare statement to include the PtrSafe keyword, and pointer-sized parameters must use LongPtr instead of Long.
When you open the workbook, you'll see: "Compile error: The code in this project must be updated for use on 64-bit systems." Or you'll get a "Type mismatch" error on a Declare line.
To check your Office bitness: open Excel, go to File > Account > About Excel. The first line will say "32-bit" or "64-bit."
Every API declaration needs PtrSafe, and every parameter that represents a pointer or handle needs LongPtr:
' Before (32-bit only):
Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long
' After (works on both 32-bit and 64-bit):
#If VBA7 Then
Declare PtrSafe Function FindWindow Lib "user32" Alias "FindWindowA" _
(ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
#Else
Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long
#End IfThe #If VBA7 conditional compilation block ensures the code works in both 32-bit and 64-bit Office. VBA7 is true for Office 2010 and later regardless of bitness, but the PtrSafe keyword is only required in 64-bit environments.
Key type replacements:
Long → LongPtr for window handles (hWnd), pointers, and memory addressesLong stays Long for regular numeric values (error codes, flags, counts)PtrSafe after every Declare keywordOlder Excel workbooks sometimes embed ActiveX controls directly on worksheets or UserForms. Several of these controls have been removed from Windows over the years:
| Deprecated Control | File | Status |
|---|---|---|
| Calendar Control 12.0 | mscal.ocx | Removed |
| Spreadsheet Control | owc11.dll | Removed (Office Web Components) |
| Microsoft Web Browser (older) | shdocvw.dll | Replaced by WebView2 |
| Microsoft Common Dialog | comdlg32.ocx | May be missing on clean installs |
If your workbook uses any of these, you'll see "Error 429: ActiveX component can't create object" or the workbook will open with blank spaces where controls used to be.
Calendar Control: Replace with the built-in Date Picker control or a simple UserForm with a MonthView. Alternatively, use a text input with date validation:
' Replace Calendar Control with InputBox + validation:
Dim selectedDate As String
selectedDate = InputBox("Enter date (MM/DD/YYYY):")
If IsDate(selectedDate) Then
Range("A1").Value = CDate(selectedDate)
Else
MsgBox "Invalid date format."
End IfSpreadsheet Control / Office Web Components: These have no drop-in replacement. The data they displayed should be moved to native Excel ranges, and any interactive features rebuilt with standard Excel functionality or UserForms.
Common Dialog: Replace with the built-in Application.FileDialog object:
' Replace Common Dialog with Application.FileDialog:
Dim fd As FileDialog
Set fd = Application.FileDialog(msoFileDialogFilePicker)
fd.Title = "Select a file"
fd.Filters.Add "Excel Files", "*.xlsx; *.xlsm"
If fd.Show = -1 Then
MsgBox "Selected: " & fd.SelectedItems(1)
End IfSome Excel macros call Windows APIs directly — things like ShellExecute to open files, SHGetFolderPath to find the Documents folder, or various file system functions. Windows updates can change the behavior of these APIs, deprecate them, or tighten security around them.
ShellExecute may fail silently if the target path contains spaces or special characters and the calling process doesn't have appropriate permissionsSHGetFolderPath returns different paths when user profiles are redirected to OneDrive (common after Windows 10/11 updates)C:\Program Files or system directories are blocked by UAC virtualization changesWhere possible, replace Windows API calls with VBA-native equivalents:
' Instead of ShellExecute API call:
Shell "explorer.exe """ & filePath & """", vbNormalFocus
' Or even better, use VBA's built-in:
ThisWorkbook.FollowHyperlink filePath
' Instead of SHGetFolderPath for Documents:
Dim docsPath As String
docsPath = Environ("USERPROFILE") & "\Documents"
' Or for OneDrive-aware paths:
docsPath = Environ("OneDrive") & "\Documents"For file operations, use the Scripting.FileSystemObject (late-bound) instead of raw API calls — it handles path normalization and permissions more gracefully than direct Win32 calls.
If your workbooks are still in the old .xls (Excel 97-2003) format, a Windows update is the right time to modernize. The .xls format has hard limits that the modern formats eliminate:
| Limit | .xls | .xlsx / .xlsm |
|---|---|---|
| Max rows | 65,536 | 1,048,576 |
| Max columns | 256 | 16,384 |
| Max file size (practical) | ~40 MB | ~200 MB+ |
| VBA macro support | Yes (embedded) | .xlsx = no, .xlsm = yes |
| Modern Excel features | No (Power Query, etc.) | Yes |
The conversion matters for macros specifically because the .xls format stores VBA in an older binary format that is increasingly unsupported by security tools and modern Office updates. Moving to .xlsm gives you the modern Open XML container while keeping full VBA support.
To convert manually: Open the .xls file, go to File > Save As, choose "Excel Macro-Enabled Workbook (.xlsm)," and save. Then test every macro, button, and UserForm in the new file.
The catch is that conversion alone doesn't fix the VBA issues described above. You still need to address broken references, add PtrSafe declarations, and replace deprecated controls.
LegacyLift converts .xls files to .xlsx/.xlsm and scans every VBA module for broken references, missing PtrSafe declarations, deprecated ActiveX controls, and outdated API calls. You get a detailed compatibility report and auto-fix scripts for the most common issues. Most files are processed in minutes.
When an Excel macro stops working after a Windows update, the cause is almost always one of five things: tightened macro security policies blocking execution, broken VBA library references from version changes, a silent switch from 32-bit to 64-bit Office requiring PtrSafe declarations, deprecated ActiveX controls that no longer exist on the system, or Windows API behavior changes affecting shell and file system calls.
Each has a specific diagnosis and a specific fix. For a single workbook with a few macros, the manual fixes above will get you running again. For a library of workbooks with years of accumulated VBA code, LegacyLift's self-service tool automates the scanning and fixing process. And if you'd rather hand the whole thing off, our done-for-you service handles everything with a free consultation upfront.