Access instance remains in memory once closed (1 Viewer)

I do have an add-in - but pretty sure Colin will as well. However I really don't want to remove it and reinstate as a normal process. I'll see if I can do it once to verify. Ditto anti-virus. Do you have add-in's? if not, perhaps you can try the code, see what you get?
 
I'm running Access 2019 Version 2507 (Build 19029.20208) 64-bit.

I have a self made Microsoft Access AddIn active and two VBE AddIns (MZ-Tools and another self made one).

Also I have an anti virus software (ESET Endpoint Antivirus) running in the background.

I tested your code from posting #4 and can see a new msaccess.exe instance will be created and shown in the details chapter of the task manager, but it will disappear immediately.

Unfortunately, I am unable to reproduce your issue. It is functioning as intended and expected here.
 
I'm running Access 2019 Version 2507 (Build 19029.20208) 64-bit.

I have a self made Microsoft Access AddIn active and two VBE AddIns (MZ-Tools and another self made one).

Also I have an anti virus software (ESET Endpoint Antivirus) running in the background.

I tested your code from posting #4 and can see a new msaccess.exe instance will be created and shown in the details chapter of the task manager, but it will disappear immediately.

Unfortunately, I am unable to reproduce your issue. It is functioning as intended and expected here.
I am on the same, but mine fell over on GetSystemMenu
 
Correct. It was in post #1 but only if the middle section was uncommented. If so API declarations were needed
 
i have similar issue with CJ, using Win 11, Office 2024 x64, it does leave access in memory..

you can still use app.Quit on your app, together with "force-killing it".
since if Access close normally, the "kill" sub will not find the access window handle
and will exit without message (if you comment out the msgbox).
 
Last edited:
I've done some more testing - in a win10 VM I have 365, 64bit office which was on a fairly old version (2412 Build 18324.20194) and the code ran as expected - the access instance is removed - takes 2-3 seconds.

I upgraded to the latest version (2508 Build 19127.20154) and the code still works the same.

So far as I can see there is no difference between the two environments, other than the Windows version win10 v win11 and the former is hosted in a VM). I know Colin is on win10, @arnelgp are you on win10 or win11?

This is the code I used:
Code:
Sub testAccessInstance()
Dim acc As Access.Application


Set acc = New Access.Application

Stop

'acc.Quit acQuitSaveNone
acc.DoCmd.Quit acQuitSaveNone
Stop
Set acc = Nothing

End Sub

One thing to note - in win10:
If acc.Quit is used, that removes the instance on executiong so Set acc = Nothing doesn't do anything (in respect of the instance)
If acc.DoCmd.Quit is used, that does not remove the instance, but it is removed when Set acc = Nothing is executed
 
Last edited:
I’ve already responded to Chris via a separate email exchange but for others reading this I can confirm that using the latest simple code in 365 under Win 10, the background instance is always destroyed but the time that happens depends on whether acc.Quit is used or the older acc.DoCmd.Quit

As I can’t test in Win 11, I will forward this to the other members of the AccessForever team to find out whether they can replicate the hanging instance in Win11 environment.
 
i am on win11 and it does not terminate the app normally.

so as i have suggested keep the .Quit thing and the Kill thing.
since when it got closed normally (via .Quit) the Kill thing will
not find the Window handle or PID and will exit quietly.
 
Somehow I feel I'm sacred and blessed by Microsoft. Because using offered code in #28, .quit leaves Access process in task manager, but setting acc to nothing closes the process.
Or am I misunderstanding the whole process you're talking about.
win 11, office 365, 64 bit

2025-08-29_19-32-30.gif
 
@KitaYama : Simply waiting a few seconds more instead of executing "Set acc = Nothing" doesn't help too? So the variable has definitely to be set to Nothing?
 
Simply waiting a few seconds more instead of executing "Set acc = Nothing" doesn't help too?
No, it wont.
I gave up after waiting for 10 minutes. If .quit needs more than 10 minutes to close the process, then it's not of a use.
 
@AHeyne
Some correction.
@CJ_London 's code in #28 has commented out the following line.
acc.Quit acQuitSaveNone
If I uncomment this line, the process is shut down. There's no need to set acc to nothing.

12.gif
 
I ran the code in post #28 and the second instance was removed?
Win 11 24H2 and 32bit Access
1756472773562.png
 

Attachments

  • 1756472764859.png
    1756472764859.png
    4.7 KB · Views: 16
@KitaYama
So in summary you are using Win11 but see the same results as both @CJ_London and I have using Win10.
@isladogs I'm really lost in this thread. Maybe I didn't understand the problem at all.
From what I can understand, I think @CJ_London claimed that he opens a database, and when he closes it, the process of the opened database remains in task manager.

What I see, with his own code, as the gifs show, when his code opens an instance of Access, a process is added to task manager.
When he uses .Quit, the added process is closed in task manager too.
Again, I'm on win11, office 365 x64
 
use the complete code on the earlier post, not a simple open/close of access app.
open the app, open a db ,Run a public sub/form/sub. close the db, and quit the app.
 
use the complete code on the earlier post, not a simple open/close of access app.
open the app, open a db ,Run a public sub/form/sub. close the db, and quit the app.
Earlier post doesn't compile. So I created a db with a public test function.
Still the same result :

100.gif


"Test" is a public function in Database2.accdb that returns the name of current database.
 

Users who are viewing this thread

Back
Top Bottom