Access doesn't close properly. A remaining background process can only be terminated in task manager

[Florian1290]

Since yesterday I noticed that in all my Access databases there is a problem when I close them.

When I close a database, it leaves a background process that can only be terminated in Task Manager. Without this, it is not possible to (re)open databases!

I have already checked some possible causes. It also concerns databases that I have not changed at all in recent months and that worked fine until this week. Therefore, I have to assume that it is a bug in an automatic update!

It seems that it has to do with a malfunction in the deallocation of allocated memory in VBA source code.

Did anyone experience the same problem? Are there already fixes or solutions available?

[#2]

Hi KiwiMarkNZ,  Thanks for letting us know about the solution you found.  Unfortunately I am not a Grammarly  user and have never installed it.  However, reading the thread, I was reminded that disabling EoAExperiences.exe solved the problem for me. I plan to try that again.

[#3]

@CycloBiker 

Nononono, this should not at all be an issue. One says this, one says that. The fact remains:

If you have an Access Database with certain code in it, certainly some ActiveX components, which are MS supported, logically the Database should close properly, when clicking the close button.

This is not happening, and it is not Microsoft's doing, it is impossible to anticipate all behaviours or all possible outcomes when a user (the person that made the database first of all), has not determined his or her, cause of the problem.

I know that somewhere, over the years, I added so much code, references, non-updated or, - not anymore compatible of properly closing - objects, controls, data, etcetera...

So I know I have to close MS Access, MS doesn't. So If make a button, with the docmd.quit SaveAll and the work is done.

Remove the cross to close the database, so there is no discussion possible of how to close my db.

[#4]

I have experienced the same problem.  When I terminate the running process and open the database from within the Access interface then the program opens and when I close it the running process terminates.  However, when I try to double click on the database file in windows explorer the database does not open.  I can at that point still open the database from within Access but then when I close the database the process remains running the the record locking file remains open.  If I then terminate the task manager process and again open and close the database from within Access, the record locking file closes. 

[#5]

This is a slight variation on infrequent problem, but one which seems to occur consistently once it appears in a particular accdb. Unfortunately I have not found a resolution and a discussion in a group of current and former Access MVPs did not yield any definitive answers or suggestions.

[#6]

@George Hepworth The only and final solution is a button and docmd.quit acsaveall.

[#7]

I'm glad to hear that works in that situation. Unfortunately, it is not generalizable.

[#8]

@George Hepworth and everyone.

I really need help!  I have a 25+ year old Access database that has been running just fine, and continues to run just fine on older computers, and still works fine after upgrading to the 64 bit, latest version.

Even back then, I set it up with a main program MDB (now acddb), and linked tables to a separate accdb file.  The program uses extensive VBA code- more than 750k lines of code! - and everything has been working just fine until this Spring.

Any new customer who has installed it has the same issue reported here.  You can open it once, but then when it closes, it's 'locked' and the only way to bring it back is to reboot the computer or kill the MSACCESS.EXE process.

I have updated to the latest version 17531.20120, added the directory to the Trust center, and allowed / disabled all warnings about Active X and other 'malicious' code which I do have as the program generates fixed length file reports, and then deletes "Kill command".   While I have always had an "Exit/Quit" button that runs "DoCmd.Quit", I am going to test "DoCmd.Quit acQuitSaveAll"

Question- can someone let me know the definite version where everything used to work?  And what's really weird is that on my dev laptop (MS Surface Pro 9), *all* of my previous customers, *and* my wife's laptop, everything works perfectly.  But on these two latest installs, same **bleep** 'zombie' process happens.

Any and all help greatly appreciated and if you solve my problem, likely rewarded, lol.  :)

TIA!

-Jon

ps - This is software for scheduling kids at summer camps, so if there are any summer camp guys here who feel sorry, help a fellow camp guy out!  ;)

pss - The only thing- so far- that these two installs have in common is how the hard drive is partitioned.  That is, they have a C:\ drive, but it's only for the operating system.  Since I place the two Access files on their desktop, I did notice that the actual folder location is something like "C:\users\MS - One Drive\desktop\Camp Scheduling Pro"  Where as on mine, it's actually on the C:\ drive itself?

[#9]

@CampDirector 

With the OneDrive reference, you may have put your finger on a possible angle to investigate. I hadn't considered that before. The one accdb I have which randomly hangs shouldn't be any different with regard to OneDrive, but who knows. I'll look into that if I can.

[#10]

@George Hepworth 

Just found out something really interesting and confirmed it screws up Access. It's the Windows "Ease of Use Setting", specifically, Text Cursor Indicator.

I replicated on my dev machine (where Access was behaving normally):

1. Close all Access DB's.
2. Goto Windows Settings, Accessibility (left hand menu).
3. Click on Text Cursor and enable Text Cursor Indicator "ON"
4. Open Access DB, then close it.
5. Trying to open it again does not work, MSACESS.EXE still running, only way is to end task.
6. To get your computer "back to normal", simply disable Text Cursor Indicator, and Access opens and closes normally.

So maybe we are getting closer? I need to check my customer's computers to see if they have this enabled. At the same time, it's RIDICULOUS that Microsoft can't fix this!!!

-Jon

[#11]

@CampDirector 

Two points. 

First, several people have been able to rule out OneDrive as a factor.

Two, until we can actually pin down the problem, it's impossible to craft a resolution. In fact, because the problem is random for most people who experience it, it's hard to know where to even begin.

Cases in point.

• We needed to rule out the OneDrive aspect. Two other people and me have come to the conclusion it's probably not a factor after all. 

• You've identified what appears to be a different problem with that Windows cursor setting, but until someone can confirm that one way or the other, again, it's not possible to begin trying to fix it.

Your help and continued feedback is invaluable and very much appreciated.

The problem has gained the attention of a number of experienced Access developers which should also bolster efforts to track it down.

[#12]

@CampDirector

Thank you!

There is independent confirmation about the Ease of Access setting by user @Cosimo (who I alerted to this ongoing lengthy thread). His/her post is at AccessForums.net: https://www.accessforums.net/showthread.php?t=89691&p=524246#post524246

I have just tested this myself and get exactly the same outcomes as you describe with multiple copies of MSACCESS.EXE remaining in Task Manager although I was still able to reopen the same apps again in each of my tests

This issue is I think close to having at least one definitive cause now confirmed as being replicable.

[#13]

Unfortunately, I think the Ease of Use setting for the cursor is not the whole story. It is replicable. However, others experience the occasional hanging instance regardless of this setting. We're on the right track, but not across the finish line.

[#14]

@George Hepworth 

I completely agree there is more to it than Ease of Access settings. That is fully reproducible and triggers a hanging instance every time

However that doesn't explain the random occurrences. There must be another cause as well itr maybe several. It may be that these are all triggers for some other more fundamental issue. 

[#15]

@George Hepworth 

I completely agree there is more to it than Ease of Access settings. That is fully reproducible and triggers a hanging instance every time

However that doesn't explain the random occurrences. There must be another cause as well or maybe several. It may be that these are all triggers for some other more fundamental issue. 

[#16]

Hi,

Since this problem has been occurring extremely often recently and is being discussed in various forums, we published a documenting AFo article and drew Microsoft's attention to it. Microsoft's Access team is currently investigating the problem. We will update the article as soon as there are any new developments.

Servus
Karl
****************
Access Forever
Access News
Access DevCon
Access-Entwickler-Konferenz AEK

[#17]

Karl: Special thanks to you for drawing the many aspects of this problem together and initiating a solution. Also, a tip of the hat to lsadogs and the many others who have helped trace the source to something reproducible. Let's hope this is the lead, MS needs to put a stake in the heart of the zombie so never emerges in any of the other circumstances Karl has curated. Got my fingers crossed!

[#18]

Just for clarification, for complicated reasons, my replies are listed as @Isladogs or @MendipDataSystems depending on which workstation I reply on! I'd love to be able to sort that out!
Karl wrote the article based on the evidence of various people here and other forums. The most important thing was being able to reliably reproduce at least one cause - in this case the Ease Of Access text cursor indicator which was first reported by @CampDirector and later confirmed by several of us

[#19]

Hi,

Today we could make an important update to our documenting article when Microsoft informed us that they are planning a fix for the next Office update to version 2405, which will be released in about 2 weeks.

Let's hope that all variants will be fixed with it. Testing this will then be the job of those affected.

Servus
Karl
****************
Access Forever
Access News
Access DevCon
Access-Entwickler-Konferenz AEK