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]

@isladogs I added Application.Quit to the On Close event of my form but got the following error:

Note however, my form and VB editor stayed open, and my Access window closed.  I had to end the task manually.

[#3]

@RayW1966 

In that case, either you are

a) still using a version that was affected by the bug from earlier this year - if so, a version update will fix it

b) or you have an issue with your code. Suggest you upload a cut down version of your database with most of the data and all unrelated objects removed.

[#4]

@isladogs 

I suspect I have an issue with my code.  I'm going to look at it again before uploading anything.  I'll keep you posted.

[#5]

We are experiencing this same behavior in Version 2207 now, and no possible Trusted Folder/File combination fixes it... I confirmed it has nothing to do with any code updates by opening a version from May that worked just fine previously that exhibited the same behavior of leaving a ghost process.

[#6]

Hi,

@ToddP What is your Office Build No?

Did you try to revert to the previous build? (see Daniel's description or Microsoft's)

If the problem does not occur with the previous build, that would be a strong indication of an update bug.

Servus
Karl
Access News
Access DevCon

[#7]

@Karl Donaubauer Just got the Office Deployment Tool setup to revert a 'few' versions to test that out so I'm working on that, was just really hoping someone else might be able to offer something better to avoid that for ALL affected computers.

[#8]

@Karl Donaubauer current build is 15427.20210

[#9]

Reverted to 15330.20230 and it's still leaving a process running in the background, but at least I can re-open the files successfully and it doesn't add a process each time the file is opened.
Then I reverted to 15330.20196 and it does the same thing.
Now I'm thinking that this has just been going on longer than I thought.
My concern with these processes running is what state is the file actually in when just killing the process. Or is there something else causing this?

[#10]

Hi ToddP. You may have tried this but I would start by checking if a process is left when opening a new blank accdb. If that doesn't leave a process running, I would be looking at autoexec macros, startup functions/procedures etc. of any db that does leave a process. And of course... the debugger's cardinal rule, "What's changed?"

[#11]

I've now discovered I have been chasing two issues, and I thought they were just connected and one was causing the other. I have still not solved my mystery for why a process is staying open in the background, but that at least appears to be a more isolated issue. The other issue was that the programs were crashing on other computers immediately when opening, but appears to be resolved now by late binding a subform that was recently added.

[#12]

Not all of our apps were leaving tasks behind. If quit was NOT in the same function called via Autoexec then the would be an orphan task. An hourly scheduled task which was problematic stopped producing orphans when its quit was moved into the top level function. (Access 365)

[#13]

I think it may be time to have another pair of eyes on your application and trace the program flow to isolate the problem(s). This does not appear to be an Access problem per se but rather a coding issue.

[#14]

It is not my application but an ancient legacy one that started leaving orphaned tasks. My only change was to delete one quit command in a sub-function which was already covered in the initial autoexe function and not needed.

[#15]

In that case, perhaps an excellent testing scenario would be to restore that quit command to see if it might address your problem with a process left running.....

[#16]

I have just started experiencing the same in 2209 (Build 15629.20208 Click-to-run 32 bit).
At first, I thought it was my project.
However, I can create a brand new accdb file and add a form, which will then open and close without issue. As soon as I whack a button on said form and save it, I get the issue. Access removes the lock file on close, but leaves the process open.

[#17]

@NiteOwl 

The problem: Access closes normally but will not reopen giving an error message saying something about you do not have permission..."

NiteOwl's Solution solution fixed the problem for me on 2022-12-15.

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

Here is the post to look for:

NiteOwl replied to NiteOwl:
------------------------------
‎Feb 03 2022 10:34 AM

You can also somewhat automate it by creating a .reg script or using group policy. The settings you need are:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Access\Security\Trusted Locations\DBLocation]
"Path"="C:\\DBFolder\\"
"AllowSubfolders"=dword:00000001
"Description"="Local DB Folder"
"Date"="2/2/2022 7:44 PM"

Prior to this patch, files in the Users\username\AppData folder were allowed but now they are being treated differently. It may be true for other locations as well.
------------------

The post be NiteOwl would not run as a .reg file. But it works: I opened regedit and manually created the key DBLocation at the end of the path cirted by NiteOwl. Then I manually created the sub keys and set the values he listed being careful to set the datatype of each value to match those observed in existing keys created in Trusted Locations.

[#18]

Hi,
I have the same issue, but I got rid of all that extra code and access still does not close. Could it have to do something with references in VBA? What did you do to solve it?

Thanks for the feedback.
A bit annoying, but maybe just logical to be punished if one's code is not perfectly written (I mean close all open connections to other references)

[#19]

@JEEDEE23 What I finally did was to add

Private Sub Form_Close()
        DoCmd.Quit acPrompt
End Sub

in my form On Close.  It worked.  Something so simple that I didn't even think of it when I was having the issue myself.  Hope this helps anyone having a similar issue.

[#20]

oooh, and I did docmd.Quit acSaveAll ...
thanks!
Indeed,it gives the system that few extra moments to close all and compact...

[#21]

For me, I tracked the issue down to Grammarly running in the system tray. If that was closed, I no longer received the behaviour. So if you use Grammarly, give that a try. It could be that or a similar add-in.