Forum Discussion
Access doesn't close properly. A remaining background process can only be terminated in task manager
- Yes, here also the update available (Europe). Tested en fix the problem. Trusted Location not necessary any more. But I highly recommend it. Otherwise you will have problem starting from April. MS is blocking marcos. Check https://techcommunity.microsoft.com/t5/microsoft-365-blog/helping-users-stay-safe-blocking-internet-macros-by-default-in/ba-p/3071805
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 https://support.microsoft.com/en-au/office/order-of-events-for-database-objects-e76fbbfe-6180-4a52-8787-ce86553682f9#bm1
Normally they should be able to track this through the proces monitor tool:
https://learn.microsoft.com/en-us/sysinternals/downloads/procmonIt 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)
- 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. Hi, yes for sure I read all of it, but as many persons indicate, Microsoft should address this.
Anyway:- I do a clean install of Win11Pro (insider or not)
- I install office 365
- give it time some days to update everything, use the pc.
- 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)
- Of course you are right, MS should handle this, which they don't...
- 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-properly-wh?orderBy=Newest
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-process-can/m-p/3103807
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. 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
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 acSaveAllif 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.
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 WithJEEDEE23 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?
