Forum Discussion
Access doesn't close properly. A remaining background process can only be terminated in task manager
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?
- 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
189 Replies
We are running Access runtime only for automated reports. The option for Trust Center does not exist so I added it to the registry. This didn't work. I also went to an earlier version but the Click-to-Run automatically updated the runtime again to the latest version with the bug. You cannot disable Click-to-Run. If you stop or disable it you cannot run any Access or Office program. I have waited for the auto update "fix" and it hasn't happened. Any suggestions? Does anyone know when the fix is supposed to be pushed out?
- The trusted location workaround fixed my issue. In case someone who needs the instructions of adding trusted location in MS Office. https://support.microsoft.com/en-us/office/add-remove-or-change-a-trusted-location-7ee1cdc2-483e-4cbb-bcb3-4e7c67147fb4
The links to the articles have been provided over and over in this and other threads here. A quick search will turn up what you are looking for.
Florian1290 I applied the trusted locations recommended workaround and I am still getting the 3048 error on a app that has been running for years and no updates in the last 6 months.
- I got it working by first applying the trusted location and then opening the database from within Access instead of using the short cut.
Hi,
Can you tell more details?
Are you sure you did the trusted location thing completely?
- If the database is located in a network, are you sure the correct level is enabled, e.g. in the trusted location settings the tick to include the subdirectories is set?
- If the application is separated into frontend and backend, have you tried putting the backend in a trusted location as well?
- Could it be that AMSI is enabled for everything by a directive, as mentioned in the Microsoft support article?
If the Trusted Location doesn't work, your other option is to roll back to an earlier Office build,
that doesn't have the bug (usually 14729.20260).
Servus
Karl
************
Access News
Access DevCon
Yes, I had the same problem. I reverted back to version 14729.20248 to solve the problem.
Follow these instructions. https://support.microsoft.com/en-us/topic/how-to-revert-to-an-earlier-version-of-office-2bd5c457-a917-d57e-35a1-f709e3dda841
- Problem solved for me:
In/with Microsoft Access open I went to
{File{Options{Trust Center -> then{Trust Center Settings} then {Trusted Locations} then{Add new location
I then browsed to the path were my database was, then clicked {ok} to add to the list.
This seemed to solve the Problem I was having.
Does this mean I can no longer use databases in any other folders? If I say the C:\ folder is ok, does doing so include all sub folders?Andrew2265 That's actually an interesting question in a different way. I would ask it this way, should one EVER place accdb/accdes in untrusted locations? I think not. That's the reason for the Trusted Locations approach in the first place.
That said, it's up to your organization to determine its security plan.
No, you have to explicitly tell Office to trust subfolders.
- Thanks for your Response, some data is not “Trusted Data Location” worthy. Tanks sizes, Pump sizes, water flow calculation data, etc. If there is hundreds of projects, each in their own folder, and each project has it’s own Access Data file, or other Microsoft Files, It seems problematic to declare each folder “Trust Worthy” I guess one could organize all projects under a main “Project Folder” and then do the subfolder declaration.
I guess in some organizations where un-trustworthy people might be working or have access, then perhaps “Trusted Data Locations” is critical. But in some cases, it seems unnecessary.
- Adding database folder (a local path) to trusted locations worked for me. We send emails through VB code in Access and have not seen problems since adding folder to trusted locations.
- Interesting that your emails are not affected, but am I correct that the folder is on the same computer as the database? Mine is located on another and although I made that path a trusted location, it still fails (\\server\Shared\FCTS\SLAB - Reports\SigningHub Documents)
This same error started for me today too, after a MS Office update applied to my laptop. Microsoft have updated something, and screwed up part of MS Access...
I see from the replies about listing the DB as Trusted Location, but mine already is. I'll see what other possible solutions look palatable. [Edit: Nope, Trust Centre had forgotten my DB location (which hasn't changed for many years). After re-adding the dir into Trust Centre, the error "Error 3048 - Cannot open any more databases" went away.I also wan't getting the error message that pops up when active content tries to run in a non-trusted dir and it's not clear at all how the error message matches the solution, so, perhaps the MS update has messed something else up behind the scenes to do with the Trust Centre, rather than directly to do with MS Access.
Well, yesterday I posted to say that my DB was already in Trusted Location. This is because otherwise I get the "Active Content" warning and parts of it don't run. But then I realized that Windows had 'forgotten' the directory's entry in Trust Centre, and I re-added it. That fixed the "Cannot open any more databases" error.
Well today, the error returned, and Windows had AGAIN forgotten the Trusted Location, and I had to add the DB's dir into Trust Centre again.
I take it that this is all part of the errors resulting from the same MS Office update from the 2nd/3rd of Feb, and it'll all go back to normal.
- Thanks for that information. As far as I know at this point MS has not yet completely isolated the problem, so this could prove useful experience.
I was getting Access 3211 errors "The database engine could not lock table "tmpCentreRow" because it is all ready in use by another person" and it only started happening with the latest release. 16.0.14827.20158. Putting the folder used by access into a trusted location in the Trust Centre cured the problem. So a big thankyou to the person who suggested it.
- What worked for me, after much flailing between 2201 and 2112 - "Online Repair" of Microsoft 365 via appwiz.cpl. This left me with 2201, which still did not work correctly (MS Access zombie process after quit). I then checked for updates - again, this was after repairing - and I was then updated from 2201 to 2108 (?!) which actually works without a problem.
I did try making Trust Center changes detailed here, which did not help in my case. Possible I wasn't adding the correct locations. Bottom line, not using version 2201 and back to normal behavior here. Hoping next official update goes better.
