BUG REPORT MS ACCESS: F5 Key in VBA Editor Behaves Like F8 – Code Runs Line by Line After Breakpoint

Issue Summary:

In the VBA Editor (VBE) of Microsoft Access (Microsoft 365, 32-bit), I'm experiencing a critical issue during debugging:

When I enter break mode (e.g., hit a breakpoint) and press F5 (or click “Continue”), the code does not resume execution normally — instead, it continues line by line, exactly as if I were pressing F8. This completely breaks normal debugging flow.

Things I Tried (none fixed the issue):

• Compact and Repair database.
• Ran Access with the /decompile switch.
• Created new, clean databases.
• Reinstalled Office 365 completely.
• Ran both Quick Repair and Online Repair.
• Used Office Deployment Tool to downgrade to older versions.
• Cleared .exd, vbaProject.bin, and temp VBA cache files.
• Verified it's not a keyboard or hardware issue.
• Disabled OneDrive sync (though my Documents folder is still redirected).
• Checked VBE-related DLLs (VBE7.DLL), and user registry entries.
• Same result on other PCs in my workplace.

✅ What Did Work (But Not a Practical Solution):

I created a new Windows user account, re-ran Access there, and F5 worked normally again, even using the same Access application where the issue originally occurred.

This confirmed that the bug is profile-specific, likely tied to a corrupted configuration or setting in the original Windows user environment.

❌ Why That’s a Problem:

Creating a new Windows profile is not viable in a production/development environment:

• I use licensed OCX controls (Viscom) tied to my current user profile — reactivation would require additional purchases.
• Other tools  are already configured.
• Recreating the full environment is costly and time-consuming.

🧠 How I Discovered This:

When I purchased a new laptop and did a clean install of Windows and Office, the issue did not occur at all, even when running the same Access database file. That’s when I realized it was tied to something in the Windows user profile.

With help from ChatGPT, I identified that the issue is likely due to corrupt user-level configuration of the VBA editor, which is not easily reset or exposed to users.

🔎 Possible Causes:

• Corrupt configuration in %APPDATA%, registry, or synced files.
• VBA/VBE state incorrectly cached.
• Debugger logic affected by user-specific flags or crash residue.

📢 Request to Microsoft:

Please consider providing:

• A tool or command to reset all VBE/VBA user settings (without creating a new user account).
• Documentation on which files or registry keys may affect debugging behavior.
• An investigation into why F5 acts like F8 and what triggers this silent corruption.

Thanks four your help