After applying the quality update for the latest channel (preview version) of Microsoft Access (64-bit), version 2408 (build 17928.20066) dated 8/14, the MSACCESS.EXE process won't end even after closing Microsoft Access application. The reproduction steps are as follows: Create a form named Form1. On Form1, create a command button named Command1. In the Click event of Command1, write "Application.Quit". Run the application, click Command1 on Form1 to close the application. Afterward, when you check the Task Manager, MSACCESS.EXE process won't end. This issue does not occur in the 32-bit version. I believe this is a bug. Can you advise where I should report this? Rolling back to version 2407 resolved this issue.

Can't go back. The versions are not logged on my PC.

Kathleen, MS365 does not log updates the way the old MSI versions did, none the less if you follow the instruction from https://www.youtube.com/watch?v=JROodrU7CEQ and/or https://www.devhut.net/microsoft-office-uninstall-an-update/ you should be able to roll your build back and get some stability. Everything is further detailed in my article about this latest bug: https://www.devhut.net/another-msaccess-exe-process-not-closing-properly-bug/ Actually, before getting into rolling back your installation, did you ever try creating a Trusted Location for your database folder? It has worked for some people facing this bug, including myself. If you are unfamiliar with how to do so, look at: https://youtu.be/QRWufXhnwpM

I can't revert due to our IT policy, and making the front and back end trusted has no effect. However, I've been able to mitigate the "Error 3048 - Cannot open any more databases" issue to a degree by rewriting the VBA code, removing every instance of call to CurrentDB and replacing it with a similar code call to the below and ensuring it's closed and set to Nothing after use. I also replaced every instance of DLookup with a call to NiceDlookup from here DLookup and “NiceDLookup” | Access JumpStart , in particular the second version by Eric Blomquist (which actually doesn't compile and needs a little tweak). I haven't noticed any performance regressions. It doesn't solve the .exe being left open, but at least I can use my database without it falling over itself instantly from too many open databases. Function CurDB() As DAO.Database Set CurDB = Access.Application.DBEngine(0)(0) End Function

unfortunately... my company IT regulation is restricting users modify the regedit btw updating from me.. i am able to run the macros after downgrade to prev. version office so if you all facing the issue, you can downgrade the version before 2408 and waiting update fix version.

In any environment controlled by IT, simply put in a ticket to have the system downgraded and mention the known bug, crashing, hung processes, risk of corrupting data, downtime, .... they will resolve the issue with ease. I also recommend supplying a little to one of the support articles on the subject and getting your manager to also put in a request to add administrative weight to the matter so it is resolved promptly. That said, IT, have tools to automate this with ease and considering the issue at hand they should have no issue doing so. In my experience, when properly presented IT has always helped out in resolving such matters.

After updating Access in Office 365 to version 2408, the MSACCESS.EXE process remains after exiting Access.

Anonymous

After applying the quality update for the latest channel (preview version) of Microsoft Access (64-bit), version 2408 (build 17928.20066) dated 8/14, the MSACCESS.EXE process won't end even after closing Microsoft Access application.

The reproduction steps are as follows:

Create a form named Form1.
On Form1, create a command button named Command1.
In the Click event of Command1, write "Application.Quit".

Run the application, click Command1 on Form1 to close the application. Afterward, when you check the Task Manager, MSACCESS.EXE process won't end.

This issue does not occur in the 32-bit version. I believe this is a bug. Can you advise where I should report this?

Rolling back to version 2407 resolved this issue.

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

97 answers

Anonymous

2024-09-02T18:18:38+00:00

Can't go back. The versions are not logged on my PC.
Was this answer helpful?

0 comments No comments
Anonymous

2024-09-02T19:31:50+00:00

Kathleen,

MS365 does not log updates the way the old MSI versions did, none the less if you follow the instruction from

https://www.youtube.com/watch?v=JROodrU7CEQ

and/or

https://www.devhut.net/microsoft-office-uninstall-an-update/ you should be able to roll your build back and get some stability.

Everything is further detailed in my article about this latest bug: https://www.devhut.net/another-msaccess-exe-process-not-closing-properly-bug/

Actually, before getting into rolling back your installation, did you ever try creating a Trusted Location for your database folder? It has worked for some people facing this bug, including myself. If you are unfamiliar with how to do so, look at: https://youtu.be/QRWufXhnwpM
Was this answer helpful?

0 comments No comments
Anonymous

2024-09-03T00:39:56+00:00
I can't revert due to our IT policy, and making the front and back end trusted has no effect.

However, I've been able to mitigate the "Error 3048 - Cannot open any more databases" issue to a degree by rewriting the VBA code, removing every instance of call to CurrentDB and replacing it with a similar code call to the below and ensuring it's closed and set to Nothing after use. I also replaced every instance of DLookup with a call to NiceDlookup from here DLookup and “NiceDLookup” | Access JumpStart, in particular the second version by Eric Blomquist (which actually doesn't compile and needs a little tweak).

I haven't noticed any performance regressions. It doesn't solve the .exe being left open, but at least I can use my database without it falling over itself instantly from too many open databases.
```
Function CurDB() As DAO.Database 

Set CurDB = Access.Application.DBEngine(0)(0) 

End Function
```
Was this answer helpful?

0 comments No comments
Anonymous

2024-09-03T02:42:29+00:00

unfortunately... my company IT regulation is restricting users modify the regedit

btw updating from me.. i am able to run the macros after downgrade to prev. version office

so if you all facing the issue, you can downgrade the version before 2408 and waiting update fix version.
Was this answer helpful?

0 comments No comments
Anonymous

2024-09-03T10:27:26+00:00

In any environment controlled by IT, simply put in a ticket to have the system downgraded and mention the known bug, crashing, hung processes, risk of corrupting data, downtime, .... they will resolve the issue with ease. I also recommend supplying a little to one of the support articles on the subject and getting your manager to also put in a request to add administrative weight to the matter so it is resolved promptly.

That said, IT, have tools to automate this with ease and considering the issue at hand they should have no issue doing so. In my experience, when properly presented IT has always helped out in resolving such matters.
Was this answer helpful?

0 comments No comments