There isn’t much information at this point in time on the root cause and no official fix to the issue (there are workarounds however, see below), but it would seem that with the most recent update(s) Microsoft Access no longer closes properly and leaves instances of the msaccess.exe running in the background.
Table of Contents
- Finally Fixed
- What We Know So Far
- Terminating Hidden Access Processes
- Possible Workarounds
- A Fix?
- Where’s Microsoft In All Of This?
- More Than Just Access Impacted By This Bug?
- Identifying Your Current Office/Access Version/Build Number?
- Other Resources on the Subject
Finally Fixed
To update your installation, in any Office application (Excel, Word, Access, …), simply go: File -> Account -> Update Options -> Update Now
After Office performs the update, you should now be running Version 2408 (Build 17928.20156) and you should no longer have the issues described below.
Note, this latest update has yet to appear in Microsoft’s Update history for Microsoft 365 Apps (listed by date) webpage.
What We Know So Far
General Information On The Bug
Misery loves company!
Know that you are not alone facing this issue. So, here are a few threads on the matter if you’d like to see what other people are reporting.
If you open the FE then the first time it opens ok. When you close access the lock file is still there and multiple access tasks are visible in task manager (see image)…
I’m stopping here, but there are many, many more.
Version and Builds Impacted
People have reported this issue occurring with versions:
- 2407
- 2408
some of the builds mentioned by people in various threads pertaining to this issue include:
- 16.0.17830.20138
- 16.0.17830.20166
- 16.0.17928.20066
- 16.0.17928.20080
- 16.0.17928.20114
Also note that people have reported this bug impacting both 32 and 64-bit Office installations.
In some instances, the database may function, but simply won’t close properly, but for others they will get resource/memory error messages (see below) and the database will crash. In all cases, the msaccess.exe process remains running in the background.
Weird Errors Being Reported
What’s a little odd with this latest bug is the fact that people are reporting a whole slew of different error messages, such as:
Another symptom that some users are reporting is that Compact and Repair doesn’t work.
Can’t Launch The Database After Closing
Since the process doesn’t shutdown, or doesn’t shutdown properly, it doesn’t release the Microsoft Access lock file (ldb, laccdb). So the next time someone goes to launch that database they will get an error like:
The solution there is to go into the folder that house the database file and delete the lock file (ldb, laccdb).
My Personal Experience
During my testing, beyond what is listed above, I encountered a situation where I could NOT close Access. I would click the ‘X’ Close button, it would flash and I’d be right back at the same place. I would have no Navigation Pane and further validation showed no active database either??? So it appeared to close the database, but not Access itself.
Also, on the same database, when I would try to perform a Compact and Repair, instead of doing so, I would get a file dialog entitled “Database to Compact From”. This would make sense, based on my analysis that “it appeared to close the database, but not Access itself”.
I have also been able to cause the hung process by using the Modern Web Browser control. So simply used some of my previous demo databases and after opening the a form with the Modern Web Browser control and then closing the database the msaccess.exe process would not terminate properly and would remain running in the background.
The only solution was to forcibly kill the msaccess.exe, delete the orphaned laccdb (lock file) and then restart the database.
FYI, this behavior was consistent and reproducible when working with VBA recordsets.
Terminating Hidden Access Processes
Since Access closes improperly, it leave hidden processes running in the background.
The easiest way to deal with this is to open the Windows Task Manager, go to the Processes tab and then find any msaccess.exe process (should be under the Background Processes section of the listing) and end them (right-click and select End task). Be sure you are killing msaccess.exe and not some other process!!!
Another approach is to create a new blank text file and input
taskkill /IM "msaccess.exe" /F
as it’s content and save the file. Then rename the file to KillAccessProcesses.bat (or any other name of your choosing, the important thing is that it has a bat file extension!). Finally, double-click on the file to run it. It will end all msaccess.exe (Microsoft Access) processes.
Once you have successfully terminate the hidden process(es), then you should be in a position to go into your database folder and delete any leeftover lock files (ldb, laccdb). At this point, you should be able to open your database again, but be sure to implement a workaround first.
Possible Workarounds
Option 1 – Rollback Your Installation Build
One option that solves the issue is to rollback your installation to a prior build number. If you are unfamiliar with this, you may like to review my article and video on the subject:
Which build you need to rollback to depends on your update channel:
- Current => 16.0.17726.20160
- Monthly => 16.0.17628.20188
- Semi-Annual => 16.0.17328.20452
Also, after rolling back your installation do not forget to disable automatic updates until Microsoft releases a fix to this bug.
If you’re in an environment where updating is controlled by your IT department and the above does not work, then obviously you must make a request for them to rollback the office version/build being used. They have the means to automate this process throughout the company (or just a subset of users) with ease and normally will be more than happy to do so to avoid crashing and the potential of data lost through corruption because of this bug! Also, mention how it is impeding work. So put in a ticket and specifically mention there is a known bug with the current version and you can provide links to articles such as this one. I’d also recommend asking your manager to put in a request on the matter to add the necessary management weight into the mix so your request is treated promptly.
Option 2 – Creating a Trusted Location Instead of Using the Enable Content to Create a Trusted Document
I received a comment to my YouTube video in which @AzulonKaiba mentioned that setting up Trusted Locations fixed this issue in the past. I was intrigued.
On my development PC, I typically simply use the Enable Content button which the make the file a Trusted Document so the code and everything works fine. I wasn’t setting up Trusted Locations (I do that for my clients though).
Long story short, I tested (I was running Version 2408 (Build 17928.20114)), tested again, and again and low and behold I could reproduce the hanging process when the db was a Trusted Document only. The minute I created a Trusted Location for the folder, then suddenly no more hung process. I deleted the Trusted Location and the hung process was back, … so on and so forth. In my specific case, I was able to trigger the issue by using a form in my database that contained a Modern Web Browser control. (Others have reported the issue triggered by working with recordsets in VBA)
This is by far not an in depth testing, but I was able none the less to reliably reproduce the issue and the fix. So it does look like there is an issue with Trusted Documents which Trusted Locations does not suffer from.
Moral of the story though, @AzulonKaiba suggestion appears to hit the mark. So if you are experiencing this bug, try creating a Trusted Location for the folder housing the database and see if the issue with hung processes goes away.
If you don’t know how to create Trusted Locations, then check out my video on the subject:
Option 3 – Replace CurrentDB Calls
As proposed by G_R1 in one of many threads on the subject, you can replace all your VBA calls to CurrentDB with Access.Application.DBEngine(0)(0) to minimise crashing… It does not however resolve the hung process issue. This simply may allow you to use your database. He also replaced domain functions (DLookuUp for instance) with custom UDFs.
Personally, I wouldn’t go about changing all my code and would instead first try the Trusted Location option and if that didn’t work, then simply Roll back my Office build until Microsoft puts out a proper fix.
A Fix?
In a forum thread, on 2024-09-04, Karl Donaubauer states:
If that is true, and I have found no official statement anywhere regarding this whole mess to confirm or deny the statement, that would potentially mean that we might see a fix on Patch Tuesday of next week, so September 10th, 2024. Let’s hope.
Where’s Microsoft In All Of This?
I know they are aware of the issue, but beyond that I can’t say.
As of the publishing of this article, the Microsoft Access Dev Team haven’t published anything on the subject (at least not that I’m aware of) on their Fixes and Workaround webpage, nor on their Access Blog.
So several weeks after this issue first surfaced, we still have no official acknowledgement of the issue or sense of when we might see a proper fix.
I also checked the ‘Microsoft 365 admin center’ -> ‘Service health’ and there is no mention of any such issue at hand! By now, there’s no excuse why there isn’t an entry about this issue with an ETA on resolution.
Once again the Ostrich Syndrome hits Microsoft.
All we can hope for at this point in time is that a fix is forthcoming in the next update, perhaps in version 2409, fingers crossed.
More Than Just Access Impacted By This Bug?
During unrelated work, I have noticed Excel not closing excel.exe process properly and it remaining in my task manager. So this issue may go beyond just impacting Access and may be a more generalized Office issue.
I haven’t investigated any further this observation, but I did find it very curious that it would occur while we are seeing similar consistent behavior with Microsoft Access.
Identifying Your Current Office/Access Version/Build Number?
If you wish to verify your current version and/or build number and don’t know how, take a look at the following:
Other Resources on the Subject
AccessForever has now put out a small article on the subject which is nice to see.