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
Hi,
You are not alone. There are reports about it in all Access forums of the world. I answered it like this several times:
According to many posts in the last days M365 Current Channel version 2201 build 16.0.14827.20158 of Jan 26 causes
- a persistent .laccdb, an Access ghost process
- error 3048 cant open any more databases- other errors like "already in use by Admin"
The only remedy so far is to revert back to an older build of M365. See also the M365 version history.
I've reported it to Microsoft, too.
Servus
Karl
************
Access News
Access DevCon- What about downgrading runtime versions?
Ciao
DavideCiao Davide,
I've never done it myself. So, if somebody has been successful with the Runtime, please report/confirm it here for others.
Personally I would assume the same procedure as desribed in the linked articles also for the Runtime, i.e. with
TargetVersion="16.0.14729.20260"
I would expect to revert the installation back to the previous build of the Current Channel.
Servus
Karl
************
Access News
Access DevCon
Hi,
The Microsoft Access team has published a first version of a support article about this update bug: https://support.microsoft.com/en-us/topic/b2dce32b-b8b0-41f1-ba40-7876e524d9da
In it a fix is announced, but so far without a date. Until then, the workaround recommended is to put the database in a trusted location.
Servus
Karl
************
Access News
Access DevConHi,
Since we've seen a lot of positive reports about it and the trusted location is now also the officially recommended workaround by MSFT: In order to keep the thread readable, I think it would be good to especially post here when the workaround does NOT help or other new findings.
Servus
Karl
************
Access News
Access DevCon
If by now you don't know, the solution is simple: add the folders where the front and backend are located to Trusted Locations. AND You have to do it for every single user in your network, a step I missed doing the first time and the other two users kept having the problem.
- Keep in mind, though, that there have been reports where the Trusted Location workaround wasn't effective. See this note, for example, on the MS site:
https://support.microsoft.com/en-us/office/access-is-unable-to-close-and-leaves-lockfile-active-b2dce32b-b8b0-41f1-ba40-7876e524d9da
Note: This workaround will not work if AMSI (Antimalware Scan Interface) is enabled for all documents. More information about AMSI can be found here: Office VBA + AMSI: Parting the veil on malicious macros - Microsoft Security Blog
Also, it's not always clear that people are fully implementing this, but one has to be cautious.
- Same issue. QuitAccess macro close the access file, but the access program with blank screen still is open, and the linked text file is still shown as open and another job that is supposed to delete the linked text file cannot delete the file. When I rename the file with suffix, the access program is closed by the QuitAccess macro. And there are other files that I have QuitAccess macro because I run all my access files by schedule, and they all seem working. Only one file is having this issue. I am going to try trusted folder option I read earlier on this thread.
- Somehow I was not able to add a network folder as trusted location. I moved the file to C drive, and the file was closed properly. For now, this is the answer.
- 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. 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.
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.
- 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.
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.
- 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)
- 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.
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
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.
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- I got it working by first applying the trusted location and then opening the database from within Access instead of using the short cut.
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.
