Why does MS Access crash on startup or right after opening?

Startup crashes most commonly trace to: a stale .laccdb lock file from a previous crash that the next open attempt cannot clear, an AutoExec macro or startup code hitting a 64-bit API fault (VBA Declare statement without PtrSafe keyword), macro security policy blocking code load when the file is not in a Trusted Location, or a reference to a 32-bit ActiveX control in a 64-bit Office environment. Clear the ghost process and lock file first. Then test from a Trusted Location folder. If it still crashes, /decompile on a copy and audit all Declare statements for PtrSafe.

Why does Access crash when I have two versions installed?

When both a standalone Access version (e.g., Access 2019) and a Microsoft 365 Click-to-Run version are installed on the same machine, they share COM registrations that conflict at runtime. The result is resource utilization crashes, COM object failures, and crashes that are impossible to reproduce on a clean machine. Open Programs and Features, identify both installations, and remove the standalone version — keep only the Microsoft 365 or the most current standalone version.

Is my Access database corrupted if it keeps crashing?

Not necessarily. Crashes that only happen on one network path but not on a local copy usually indicate a network/locking problem, not file corruption. Crashes that happen on every PC, including a clean machine with a copy of the file, are more likely to indicate corruption or a version mismatch. A genuine corruption indicator is 'unrecognized database format' appearing consistently across machines and Access versions. If the database opens on a local drive but crashes on the network share, the environment is the problem — not the file.

Can antivirus cause MS Access to crash?

Yes. Real-time antivirus scanning of the .accdb file and especially the .laccdb lock file introduces latency and occasional write lock failures under load. This produces crashes that look random because they depend on the timing of the AV scanner's scan cycle relative to Access's write operations. Work with IT to add scoped exclusions for the folder containing the database files — not a blanket antivirus disable. The exclusion needs to cover both the .accdb and .laccdb extensions.

What does the /decompile switch do for a crashing Access database?

/Decompile launches Access with a switch that discards all compiled VBA p-code and forces a full recompile from source text on the next compile command. This resolves crashes caused by p-code corruption — where the compiled binary diverged from the source module text, causing the VBA runtime to fault on execution. Run it on a disposable copy of the front end only, never on the production file. After /decompile opens the file, go to VBA Editor → Debug → Compile, fix any reference errors, save, and compact the copy.

How do I use Event Viewer to diagnose an Access crash?

Open Event Viewer (Win+R → eventvwr). Navigate to Windows Logs → Application. Filter by Event Source = 'Application Error' or search for MSACCESS.EXE. Look at entries within 60 seconds of the crash time. Key fields: Faulting module name (tells you which DLL caused the crash — mso.dll suggests Office component, dao360.dll suggests DAO resource issue, ntdll.dll suggests memory corruption), Exception code (0xC0000005 = access violation, 0xC000041D = fatal user callback exception), and Faulting module version (helps identify whether an Office update introduced the crash).

Does splitting the Access front-end and back-end stop crashes?

Usually yes, significantly. A proper FE/BE split means front-end deployments stop writing data pages on every user's machine, smaller FE files reduce corruption risk from local crashes, and each user's local crash only affects their FE copy — not the shared data. However, splitting alone does not fix crashes caused by network instability, antivirus interference with the back-end file, or VBA code problems. It is one of the most effective structural changes but not a complete fix for all crash causes.

MS Access Database Keeps Crashing — 9 Emergency Fixes (Not Generic Advice)

Q: Why does my MS Access database keep crashing?

The most common causes of a repeatedly crashing MS Access database are: a ghost MSACCESS.exe process holding a stale lock file from a previous crash, the database file stored in OneDrive or a cloud sync folder that interleaves partial writes, two versions of Access installed simultaneously causing COM registration conflicts, antivirus scanning the live .laccdb lock file during peak usage, a 32-bit ActiveX control or reference loaded in 64-bit Office, or unclosed DAO/ADO recordset objects that exhaust Windows GDI resources over time. Fix the ghost process and lock file first — those two steps resolve most startup crashes immediately.

Q: Can storing an Access database in OneDrive cause it to crash?

Yes — this is one of the most common and destructive crash causes we see in 2025 and 2026. Microsoft explicitly does not support storing live Access databases in OneDrive, SharePoint sync folders, or Dropbox. Cloud sync clients interleave their own write operations with Access's file saves, breaking the page-level consistency that JET/ACE requires. The result is a corrupted file that crashes on open, produces 'unrecognized database format' errors, or silently loses data. Move the database to a local drive or a standard network share (not a sync folder) immediately.

When your MS Access database keeps crashing — on open, under load, when a specific form runs, or randomly throughout the day — you need a sequence that preserves data and cuts through noise fast. This guide covers nine specific, ordered fixes for US businesses. Not "try Compact and Repair." Not "disable antivirus." The actual causes, in the order you should check them.

Also see: MS Access error troubleshooting guide · Repair corrupted Access database · Fix slow MS Access database

Symptom → Fix Map — Start Here

Identify your crash pattern below, then jump directly to the right fix. Do not apply fixes randomly — the wrong fix in the wrong order can destroy recoverable data.

▸Crashes every time on startup→Fix 1 (ghost process) + Fix 2 (lock file) + Fix 3 (trusted location)

▸Crashes on one PC but not others→Fix 5 (two Access versions) + Fix 7 (bitness mismatch)

▸Started after Office update→Fix 7 (bitness) + Fix 9 (/decompile)

▸Crashes when stored on OneDrive/SharePoint→Fix 4 (cloud sync) — move the file immediately

▸Random crashes, no error message→Fix 6 (antivirus) + Fix 8 (DAO leaks) + Event Viewer section

▸Crashes after hours of use, fine at startup→Fix 8 (DAO/ADO resource leaks) + Fix 6 (antivirus)

▸Crashes when opening a specific form/report→Fix 9 (decompile/new shell) — specific object corruption

▸Crashes get worse over weeks→Fix vs Stabilize section — structural debt, not a one-time fix

First Aid — Do These 3 Things Before Anything Else

System down — do this now

If your Access database crashed and will not reopen, do these 3 steps before attempting any repair — in this order.

Task Manager → end all MSACCESS.EXE: Press Ctrl+Shift+Esc. Look for any MSACCESS.EXE in the Processes list. End all of them — even ones that say "Not Responding." A zombie Access process holds the .laccdb lock file and guarantees the next open will crash.
Delete the .laccdb sidecar file (only after confirming no legitimate user is active): Open File Explorer, go to the folder where the database lives. Delete the .laccdb file (for .accdb) or .ldb file (for legacy .mdb). Never delete the .accdb data file itself.
Test from a Trusted Location: Copy the database to a local folder, then add that folder to Access Trust Center → Trusted Locations (File → Options → Trust Center → Trust Center Settings → Trusted Locations → Add New Location). If it opens without crashing, the original crash was a macro security block — not corruption.

Why MS Access Really Crashes — It Is Almost Never "Random"

Access crashes are a symptom, not a root cause. The ACE engine is file-backed — the Access UI thread is tightly coupled to synchronous file I/O and Windows GDI painting. When anything in that chain lies — a network drop, a resource exhaustion, a mismatched library — the process terminates. What looks like "random freeze" to users is almost always one of nine specific, diagnosable causes. Here they are in order of frequency for US businesses in 2025–2026.

Fix 1 Ghost MSACCESS.EXE Process — The #1 Startup Crash Cause

After Access crashes, the MSACCESS.EXE process frequently does not terminate cleanly. It stays in Task Manager as a ghost — consuming the .laccdb lock file, blocking the next open attempt, and causing a second crash when the new session cannot acquire the lock. Most "my Access database crashes every time I try to open it" situations are this.

Press Ctrl+Shift+Esc to open Task Manager.
Click the Details tab.
Find any MSACCESS.EXE entries.
Right-click each → End Task. Do all of them.
Wait 10 seconds, then try opening the database again.

Fix 2 Stale .laccdb Lock File — Delete It (After Confirming the All-Clear)

The .laccdb file is Access's lock coordination file — it tracks which users have the database open. After a crash, this file often contains stale entries for users who are no longer connected. The next person to open the database sees a "file is locked by another user" error or a crash because the engine cannot reconcile the stale lock state.

After killing all MSACCESS.EXE processes and confirming with operations that nobody is actively in the database:

Navigate to the folder containing the .accdb file.
Find the file with the same name but .laccdb extension (e.g., if the database is Inventory.accdb, delete Inventory.laccdb).
Delete it. Access will create a fresh one on next open.

Fix 3 Trusted Location — Rule Out Macro Security Crashes

Access macro security policy can block VBA code from executing during the database load sequence — which produces a crash or immediate close with no error message. This is indistinguishable from corruption until you test it. The test takes two minutes.

Copy the database to C:\AccessTest\ (or any local folder you own).
Open Access. Go to File → Options → Trust Center → Trust Center Settings → Trusted Locations.
Click Add New Location. Browse to C:\AccessTest\. Click OK.
Open the database copy from that folder.

If it opens without crashing: the original crash was a macro security policy block — the fix is adding the production folder to Trusted Locations via Group Policy, not a database repair. If it still crashes from the Trusted Location: security policy is not the cause — continue to Fix 4.

Fix 4 OneDrive / Cloud Sync — Move the Database Off Immediately

This is one of the most destructive and most common Access crash causes in 2025 and 2026. Microsoft explicitly does not support storing live Access databases (.accdb or .mdb) in OneDrive, SharePoint document library sync, or Dropbox. Cloud sync clients interleave their own write operations with Access's file saves — breaking the page-level consistency that JET/ACE requires for every transaction.

The result is a database that crashes on open, produces "unrecognized database format" errors, or silently loses data — often with no warning until the damage is discovered days later.

Check this right now:

Right-click the .accdb file in File Explorer. Look at the Location path. If it contains OneDrive, SharePoint, Dropbox, or any cloud sync folder path — stop. Move the file to a local drive or a standard network share (not a sync folder) before attempting any repair. Repairing a file while it is in a sync folder will re-corrupt it.

Fix 5 Two Access Versions Installed — COM Registration Conflict

When a standalone Microsoft Access installation (Access 2019 purchased separately) and a Microsoft 365 Click-to-Run Access installation coexist on the same machine, they share Windows COM registrations that conflict at runtime. The result is resource utilization crashes, COM object instantiation failures, and crashes that affect both installations — and are impossible to reproduce on a clean machine.

Open Control Panel → Programs → Programs and Features.
Look for two Microsoft Office or Access installations.
Remove the older standalone version — keep only Microsoft 365 or the most current version.
Restart and test.

This crash pattern is most common after an IT department rolls out Microsoft 365 without first removing the pre-existing Access installation.

Fix 6 Antivirus / Endpoint Protection — Scoped Exclusions, Not Blanket Disable

Real-time antivirus scanning of the .accdb file and — more critically — the .laccdb lock file during peak usage introduces write lock races that produce crashes appearing random. The AV scanner's scan cycle timing relative to Access's write operations determines whether a given session crashes, which is why the pattern looks random.

Work with IT to add these specific exclusions — not a blanket antivirus disable:

Exclude the folder containing the .accdb back-end file from real-time scanning.
Exclude .laccdb and .ldb file extensions from real-time scanning globally.
Scheduled scans of the .accdb file are fine — real-time scan of an open database is the problem.

Fix 7 32-bit vs 64-bit Bitness Mismatch — The Silent Startup Killer

A database built for 32-bit Access containing 32-bit ActiveX controls, or VBADeclare statements without PtrSafe, will crash immediately on open in 64-bit Access — usually with no meaningful error message. This is the most common crash pattern after an IT department upgrades machines from 32-bit to 64-bit Office 365.

Step 1 — Confirm your Access bitness:

File → Account → About Access. Look for "32-bit" or "64-bit" in the version string.

Step 2 — Check for bitness-sensitive VBA declarations:

In VBA Editor (Alt+F11), use Ctrl+F to search all modules for Declare Function or Declare Sub. Any that do not have the PtrSafe keyword will crash 64-bit Access. Add PtrSafe after Declare and replace Long handle parameters with LongPtr.

Step 3 — Check ActiveX controls:

Common 32-bit-only controls: MSCOMCTL.OCX (TreeView, ListView, ImageList), calendar controls, common dialog boxes. These have no 64-bit equivalent and must be replaced with native Access alternatives. See legacy Access database upgrade for the full ActiveX replacement process.

Fix 8 DAO/ADO Resource Leaks and GDI Exhaustion

Crashes that happen after hours of use, get worse throughout the day, and disappear after a restart almost always trace to resource leaks. The two most common:

DAO/ADO recordset handles not closed

Every OpenRecordset call without a corresponding .Close and Set rs = Nothing leaks a handle. Search all VBA modules for OpenRecordset and verify every call has cleanup in both the normal exit path and the error handler.

GDI resource exhaustion from heavy images

Forms with embedded OLE images, large bitmaps in logo controls, or multiple subforms each loading images exhaust Windows GDI handle limits after extended sessions. Replace OLE image controls with image path references stored in text fields — Access loads the image file at display time rather than storing the binary in the database.

Fix 9 /decompile and New-Shell Import — When the Container Is Damaged

When none of the above fixes resolve the crash and the database consistently crashes when opening a specific form, report, or module — the compiled VBA p-code or the object binary stream is corrupted. Two approaches, in order:

Option A: /decompile on a disposable copy

This discards all compiled p-code and forces recompile from source text — useful when corruption is in the compiled stream but not in the module text itself.

"C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE" /decompile "D:\Recovery\copy_app.accdb"

Adjust the Office path for your version (Office16 = 2016/2019/2021/365) and bitness. After it opens: VBA Editor → Debug → Compile. Fix any reference errors. Save. Do not run /decompile on your only copy.

Option B: New-shell import (when /decompile also crashes)

Create a new blank .accdb and import objects in controlled waves. When one import fails, you have named the specific corrupt object without torturing the ACE catalog further.

Create a new blank .accdb in the same Access version.
External Data → Import & Link → Access → select the damaged file.
Import tables only. Validate row counts.
Import queries. Validate.
Import forms and reports one batch at a time. Note which one fails.
Import modules last. Compile and fix references.

The object that fails to import is the corruption carrier. If it is a form, create a blank replacement and manually rebuild the controls — the data is safe in the tables. See repair corrupted Access database for the full new-container protocol.

Fix vs. Stabilize — What the Difference Costs You

A fix buys a window: kill the ghost process, delete the stale lock, move the file off OneDrive. It gets you back to work today. Stabilization changes the architecture so the failure mode stops recurring — split FE/BE, move to wired storage, replace 32-bit ActiveX controls, fix DAO lifetime in every error path, add proper antivirus exclusions with IT documentation.

If your database crashes more than once a month, you are carrying structural debt, not experiencing bad luck. Each crash-and-repair cycle risks data loss. Each forced-kill by a user who grew frustrated created another ghost process. The cost of a proper stabilization engagement is a fraction of a data loss event or a month-end close that fails at the worst possible time.

Request a stability audit Emergency database repair Contact — priority channel

Event Viewer — Read the Crash Evidence Before Calling Anyone

Windows Event Viewer records every application crash with the faulting module name, exception code, and timestamp. Reading this before escalating a crash to a consultant or Microsoft support cuts triage time dramatically — because you arrive with evidence, not a description.

Press Win+R, type eventvwr, press Enter.
Navigate to Windows Logs → Application.
Click Filter Current Log. Set Event source to Application Error. Set the time to the 5 minutes around the crash.
Look for entries with MSACCESS.EXE as the faulting application.

What the faulting module tells you:

dao360.dllDAO resource exhaustion or unclosed recordset — Fix 8

mso.dllOffice component crash — check for two Access installations (Fix 5)

ntdll.dllMemory corruption — often DAO leaks (Fix 8) or bitness mismatch (Fix 7)

vbe7.dllVBA engine fault — p-code corruption, /decompile first (Fix 9)

MSACCESS.EXEACE engine fault — check network path, run /decompile on a copy (Fix 9)

Exception codes:

0xC0000005 (Access Violation) = memory read/write fault — usually DAO leaks or bitness. 0xC000041D (Fatal User Callback) = exception in a callback from Windows into your VBA code — check event handlers. 0x40000015 (Stack Overflow) = recursive VBA call without exit condition.

FAQ — MS Access Database Keeps Crashing

Why does my MS Access database keep crashing?

The most common causes in order: ghost MSACCESS.exe process holding a stale lock file, database stored in OneDrive or a cloud sync folder, two Access versions installed simultaneously, antivirus scanning the live .laccdb file, a 32-bit ActiveX control in 64-bit Office, unclosed DAO recordsets exhausting GDI resources, or p-code corruption requiring /decompile. Start with Fix 1 (kill ghost processes) and Fix 2 (delete stale lock file) — those two steps resolve most startup crash loops immediately.

Why does Access crash every time on startup?

Startup-only crashes almost always trace to a stale .laccdb lock file from a previous crash, or macro security policy blocking AutoExec code from running. Kill all MSACCESS.EXE processes in Task Manager, delete the .laccdb file, then test from a Trusted Location folder. If it opens from Trusted Location but not from the original path, the fix is adding that path to Trusted Locations — not a database repair.

Can storing an Access database in OneDrive cause crashes?

Yes — move it immediately. Microsoft does not support live Access databases in OneDrive, SharePoint sync, or Dropbox. Cloud sync clients interleave partial writes with Access saves, which breaks JET/ACE page consistency and corrupts the file. Check the file location path in File Explorer — if it contains OneDrive or SharePoint, move to a local or standard network path before attempting any repair.

Why does Access crash on some PCs but not others?

Machine-specific crashes almost always mean a bitness mismatch (32-bit vs 64-bit Office) or a duplicate Access installation on the affected machines. Check File → Account → About Access to compare bitness across the affected and unaffected machines. Also check Programs and Features for two Access or Office installations on the crashing machines.

Does splitting Access FE/BE stop crashes?

Usually reduces crashes significantly. A proper FE/BE split means front-end updates stop touching data pages, smaller FE files lower corruption risk from local crashes, and a user's local crash only affects their front-end copy. However, splitting does not fix crashes caused by antivirus interference with the back-end file, OneDrive storage, bitness mismatches, or VBA resource leaks.

Why does Access freeze with no error dialog?

A freeze with no error message is almost always the UI thread blocked on network I/O (waiting for a slow SMB read to complete), an ODBC query with no timeout running against SQL Server, or GDI resource exhaustion from unclosed DAO objects or heavy images. Open Event Viewer (Win+R → eventvwr) and look for MSACCESS.EXE entries around the freeze time — the faulting module name tells you exactly which of these caused it.

Can antivirus cause Access to crash?

Yes. Real-time AV scanning of the .laccdb lock file during peak usage causes write lock races that produce crashes that look random. Work with IT to add folder-level exclusions for the database folder and .laccdb/.ldb extension exclusions — not a blanket antivirus disable.

How do I document an Access crash for a consultant?

Provide: exact Access and Office build number (File → Account → About Access), whether FE/BE are split, network path and connection type (wired LAN, Wi-Fi, VPN), reproduction steps under five minutes, which user profiles and machines are affected vs. not, Event Viewer Application log entries for MSACCESS.EXE around the crash time, and a sanitized copy of the front end. That bundle reduces remote triage from hours to minutes.