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]

I stopped searching, it definitely has to do with code in the database. Also with Onedrive

[#3]

@JEEDEE23 Hi! This issue got resolved last year. MS released a bad version of Access. Once the released the fixed version everything was fine and back to normal. Glad you fixed your issue. :)

[#4]

killed Gammarly and the problem went away. Thank you.

[#5]

@Florian1290 

close access with a button on your form invoking this event, it always works, of course a non saved record, will not be saved.

x = Shell ("cmd.exe /c TASKKILL /F /IM msaccess.exe")

[#6]

@JEEDEE23 

As Coskerk says "This issue got resolved last year. MS released a bad version of Access. Once the released the fixed version everything was fine and back to normal."  

The issue disappeared for me about 8 months ago after MS issued an update.  My  updated Access installs have been operating without this issue for quite some time.

Karl Donaubaur was correct when he cited an MS update as the source of the problem shortly after it happened.  I well remember the panic it created.

[#7]

How come I still have the issue then?

[#8]

Well now that I look back through my journal. I did an in-place reinstall of windows 11 to clear up other issues like unreliable copy/paste and no sound for 5 minutes after I turned on my earphones. In-place reinstall left all my files and apps as they were. Most of the windows bugs were gone but unreliable copy/paste is still crops up occasionally. A few weeks later, Access was still not closing properly. Suspecting that there might be a bug fix, I downloaded the Office 365 Premium Offline Installer (which includes Access) and used it to reinstall office. Problem gone. A few days later when I opened Access again, it started closing properly. No hidden background process. I checked using Sysinternals Process Explorer. So I am not sure whether the Windows or Office reinstalls fixed the problem or subsequent updates automatically installed fixed the problem but have not experienced the problem for several months.

[#9]

@CycloBiker 

Yes, that could be a solution. Me too, I installed brand fresh win 11, but let the office 365 run from  the cloud.
Let it be clear, I only  have this issue the moment I start using  the database, it is quite full with code. But normally the docmd.quit acsaveAll works fine, until recently...
Can you tell me the offline 64-bit downloadable version or send me a link to it?
The behaviour starts, the moment one changes any record in any table, but only  in a form. Changing a lot of records, even in related tables, in the source tables, without even opening a form, does close access properly. 
To be clear, this database is 10 years old and always closed properly. (upgraded it to 64-bit around 5 years ago)

[#10]

Started noticing this problem recently too. Same behavior as what you describe in previous posts. I'm on Office 365 version 2302 on Win Server 2019. Using taskkill on a Command Button works but it doesn't remove the .laccdp lock file. Hoping a new update fixes this problem or someone discovers a workaround.

[#11]

@Tho_Map  That is correct. The 'taskkill' is therefore only to be used if one is sure, everything is saved. So if you are editing a record, and click on the quit button whitout saving that edited record, the record is not saved. 
Well, you speak about workaround, as far as I could detect, this is the only one. (you can also invoke the taskkill in an 'on close' event:

When you close a form, the Exit and LostFocus events occur before the events associated with closing the form (such as Unload, Deactivate, and Close), as follows:

Exit (control) -LostFocus (control) -Unload (form) -Deactivate (form) -Close (form)
source here 

[#12]

@JEEDEE23 Thanks for your reply and explanation. 

A user will sometimes have multiple access front-ends open at the same time so I needed to taskkill by process ID so the close button only closes the current db.  I added this function to a module to get the process ID of the current db (http://allapi.mentalis.org/apilist/GetCurrentProcessId.shtml_:  

Declare Function GetCurrentProcessId Lib "kernel32" Alias "GetCurrentProcessId" () As Long

 Our Infosec group doesn't allow us to call cmd.exe so I used powershell instead to call taskkill:

Shell ("powershell taskkill.exe /f /t /PID " & GetCurrentProcessId)

I noticed that sometimes the lock file does close?  Maybe the slight delay sometimes when calling the shell allows the Application.Quit or DoCmd.Quit to complete and close the lock file?

[#13]

Another variation on the same theme
I have an analyzer app that checks on the properties of external Access databases using automation.
To ensure the background Access process is terminated when I close the analyzer (or change to view details of another database, I use WMI to kill that Access instance:

       'kill any existing instances of appAcc & hence leftover instances of Access in task manager
       'this causes error 91 if appAcc not yet created e.g. when form first loaded
       'use error handling in such cases
30       With appAcc
40               .CloseCurrentDatabase
50                  DoEvents
60                  If Application.hWndAccessApp = appAcc.hWndAccessApp Then WMI_KillProcess "MsAccess.exe"
70                  DoEvents
80                  .Quit
90                  DoEvents
100       End With

[#14]

@Tho_Map 

Indeed, your solution (which is of course an unusual workaround) is more accurate.

Concerning your last remark: you can check that: 

Shell ("powershell taskkill.exe /f /t /PID " & GetCurrentProcessId)
docmd.quit acSaveAll

if the .laccdb has disappeared, access was closed, if it is still there, access was only killed. You should put  it like this then

Shell ("powershell taskkill.exe /f /t /PID " & GetCurrentProcessId,false)

that way, access won't wait for the shell command to finish and proceed to the next line.

[#15]

@JEEDEE23I've been dealing with this problem since moving to Win11 and Office 365.

The problem (zombie processes) seems to be related to using either docmd.quit or application.quit to close your Access db.

Also, why should a user/customer have to kill zombie processes? Shouldn't MS handle this?

Shell ("powershell taskkill.exe /f /t /PID " & GetCurrentProcessId)

Rod

[#16]

Hi folks,

At this point I am no longer sure we are talking about the same problem. In January and February there was a zombie that remained in the background after Access closed. It was linked to EoAExperiences.exe (in %windir%\system32 and Grammarly in this post. Killing these process solved the problem.
https://learn.microsoft.com/en-us/answers/questions/681552/msaccess-exe-(all-versions)-wont-close-pr...

The problem has has also been linked to trusted locations and other possible causes in this thread:

https://techcommunity.microsoft.com/t5/access/access-doesn-t-close-properly-a-remaining-background-p...

On page 4 of the thread, BillCQ mentiond an update that fixed the problem. Bart-K gives a link to the update. Coskerk confirms resolution.

I am sure you are aware of these posts so I apologize if you have already applied the various solutions mentioned before the update came out. For me, they worked. With the update applied, and assiduous application of subsequent updates, I have had not further problems but ,,, my applications at the moment are all single computer, single user. You may have other issues that I have not encountered.

[#17]

Of course you are right, MS should handle this, which they don't...

[#18]

@CycloBiker 

Hi, yes for sure I read all of it, but as many persons indicate, Microsoft should address this.
Anyway:

1. I do a clean install of Win11Pro (insider or not)
2. I install office 365
3. give it time some days to update everything, use the pc.
4. Bam.
   I never use Grammarly, nor did I ever see that  EoAExperiences.exe (it is on my PC, but when opening it: "this app can't be used on your pc")
   I did not yet install via an offline download of the complete office 365 package (as suggested also somewhere above) but I don't have time nor interest to do so.
   I use my button with the taskkill and maybe some day I will remark that simply using the X to close, works again... or not ...

Thanks for answering and keeping this issue alive, it is possible we don't talk about the same causes  but certainly about the same results: Using an MS database with some vba code, and closing the database with the X worked until somewhere during 2022, and since then, closing MS Access 'the normal way' is impossible. For me: English Version of today Dutch keyboard and time zone, and Belgian regional settings (veeeerrryy important to know, because this causes sometimes other issues)

[#19]

Hi JeeDee23: You sure have tried hard to fix the problem and I well understand your frustration. And I also agree MS should fix it. Super frustrating as is reduced users confidence in the Access application you made for them. My guess is that the real problem is that MS does not know what is causing it. They may have fixed issues with EoAExperiences.exe and Grammarly because users found out, probably by pure luck, what was causing the problem. Unable to predict what is causing the issue for some users and not others, because every user is using a different combination of apps and Windows subsystems, I bet they cannot handle the complexity.

Is there anyone who can provide guidance on how to trap the error and trace the cause? But maybe I am wrong: did my problem disappear because it was fixed by updates or because I disabled EoAExperiences.exe? If the latter is the case, maybe the problem is not solved at all, even in my case.

[#20]

@CycloBiker 

Normally they should be able to track this through the proces monitor tool:

https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

It will clearly state what is wrong, but I think due to privacy reasons, they don't use this tool much (certainly won't demand you to do it)

[#21]

killing Grammerly worked for me. I recently installed the Grammarly Desktop version and then I got the zombie Access process described here. This thread helped me solve the problem. Grammarly Desktop is not responding to the Access close event and is keeping it open in the background - naughty!