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