Access doesn't close properly. A remaining background process can only be terminated in task manager

Copper Contributor

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?

177 Replies

@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.





Can you tell more details?

Are you sure you did the trusted location thing completely?


  1. 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?
  2. If the application is separated into frontend and backend, have you tried putting the backend in a trusted location as well?
  3. 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).


Access News
Access DevCon


@Karl Donaubauer 

Adding my database files to the Trusted Location (though successful) did NOT solve my problem with Microsoft Access failing to close completely when I exit Microsoft Access.  Also, .ldb files remain undeleted.  I must use Task Manager to shutdown Access, then manually delete the stuck .ldb files, and only then will my database restart and run "normally for a while" before glitches reoccur, and I just go through all of these steps again.  Yes I did check "allow network folders".  This all started for me on-or-about February 2, 2022.  I am using Microsoft Office 2016 and 2019 on three machines.  All three machines are affected in exactly the same way.

Thank you for your contribution to this forum.

Trusted location did the job for me...thanks!!!
Unfortunately, mde/accdes are equally impacted by the bug.

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:

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.
Thanks. I guess I was one of the several fortunate ones. Glad to know that they'll be releasing a permanent fix.

@lease forward instructions on how to revert to previous Office 365 version.  Thanks.


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.

I got it working by first applying the trusted location and then opening the database from within Access instead of using the short cut.



When I post in international forums I usually remove the language part (it-it/, en-us/ etc.) from these Microsoft links. Then everyone gets the article in their browser language (or the US English original if there is no translation). The language of the page title in the link does not matter, only the Id is relevant:

However, sometimes the original US English version is more up-to-date than the translated versions or better than a (sometimes) machine-translated version.


Access News
Access DevCon

The trusted location workaround fixed my issue. In case someone who needs the instructions of adding trusted location in MS Office.



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?

Adding to 'Trusted Folders' worked for me as well.
How to deploy this ealsily to other users?
Use the small tool AddPath2016.exe from Gunter Avenius as Karl Donaubauer
suggested? Or will Microsoft come with a repair update soon?

Suggested workaround worked on Friday, not today. Only known "change" was a PC restart. Likely something else changed too, don't know. Tried removing and re-adding trusted locations, has not helped. Also don't know if we have AMSI enabled, have question in with IT.


UPDATE - Restarted PC, workaround again seems to be working. Makes very little sense to me.



    Function addTrustedLocation(strFolder As String, strLocationDescription As String, blnAllowSubFolders As Boolean, strOfficeApp As String, strOfficeVersion As String) As Boolean
'(developed july 2019 by Gert De Wilde)
        addTrustedLocation = False
        Const HKEY_CURRENT_USER = &H80000001
        Dim strParentKey As String, intLocCounter As Long, objRegistry As Object, varChildKey, arrChildKeys
        Dim strNewKey As String, tmpValue As String, keyAvailable As Boolean, lngStep As Long

        On Error GoTo Hdl

            lngStep = 10
            tmpValue = ""

            Select Case strOfficeApp
                Case "Word"
                    'strParentKey = "Software\Microsoft\Office\14.0\Word\Security\Trusted Locations"
                    strParentKey = "Software\Microsoft\Office\" & strOfficeVersion & "\Word\Security\Trusted Locations"

                Case "Excel"
                    'strParentKey = "Software\Microsoft\Office\14.0\Excel\Security\Trusted Locations"
                    strParentKey = "Software\Microsoft\Office\" & strOfficeVersion & "\Excel\Security\Trusted Locations"
                Case "Access"
                    'strParentKey = "Software\Microsoft\Office\14.0\Access\Security\Trusted Locations"
                    strParentKey = "Software\Microsoft\Office\" & strOfficeVersion & "\Access\Security\Trusted Locations"
                Case Else
                    'MsgBox("The application you specified is not covered by this procedure", , "Trusted location definition")
                    Exit Function
            End Select

            intLocCounter = 0
            lngStep = 15

            'objRegistry = GetObject("winmgmts:\\.\root\default:StdRegProv")
            Set objRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv") '10jul19
            lngStep = 20
            Call objRegistry.EnumKey(HKEY_CURRENT_USER, strParentKey, arrChildKeys)
            lngStep = 25
            If Not isArray(arrChildKeys) Then
                'the Trusted Location folder does not exist and needs to be created
                ' if only Acces Runtime is available, then the 'Trusted Locations' node does not yet exist
                'so create this node (will not cause error if already available) and one childkey
                'just to assure a childkey collection
                Call objRegistry.CreateKey(HKEY_CURRENT_USER, strParentKey)
                Call objRegistry.CreateKey(HKEY_CURRENT_USER, strParentKey & "\Location9")
                Call objRegistry.SetStringValue(HKEY_CURRENT_USER, strParentKey & "\Location9", "Path", strFolder)
                objRegistry = Nothing
                arrChildKeys = Nothing
                Set objRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
                Call objRegistry.EnumKey(HKEY_CURRENT_USER, strParentKey, arrChildKeys)

            End If

            lngStep = 26
            If isArray(arrChildKeys) Then
                'if a key with the specified path aleady exists, delete this key to be replaced
                For Each varChildKey In arrChildKeys
                    lngStep = lngStep + 1
                    Call objRegistry.GetStringValue(HKEY_CURRENT_USER, strParentKey & "\" & varChildKey, "Path", tmpValue)
                    If tmpValue = strFolder Then
                        Call objRegistry.DeleteKey(HKEY_CURRENT_USER, strParentKey & "\" & varChildKey)
                    End If

            End If

            lngStep = 30
            'refresh the array in case one has been deleted
            Call objRegistry.EnumKey(HKEY_CURRENT_USER, strParentKey, arrChildKeys)

            'keep track of child key numbering
            'missing holes should be filled so look for the first available locationX

            'first look if a slot between 0 and 9 is available

            If Not isArray(arrChildKeys) Then
                intLocCounter = 0
                keyAvailable = True
                If isArray(arrChildKeys) Then 'if no childkey array, skip this check
                    For intLocCounter = 0 To 9
                        keyAvailable = True
                        For Each varChildKey In arrChildKeys
                            If CInt(Mid(varChildKey, 9)) = intLocCounter Then keyAvailable = False
                        If keyAvailable = True Then Exit For
                End If
            End If

            lngStep = 40

            'else take the next available
            If keyAvailable = False Then
                For Each varChildKey In arrChildKeys
                    If CInt(Mid(varChildKey, 9)) > intLocCounter Then
                        intLocCounter = CInt(Mid(varChildKey, 9))
                    End If
                intLocCounter = intLocCounter + 1
            End If

            'now choose the key
            strNewKey = strParentKey & "\Location" & CStr(intLocCounter)

            lngStep = 50

            Call objRegistry.CreateKey(HKEY_CURRENT_USER, strNewKey)
            Call objRegistry.SetStringValue(HKEY_CURRENT_USER, strNewKey, "Path", strFolder)
            Call objRegistry.SetStringValue(HKEY_CURRENT_USER, strNewKey, "Description", strLocationDescription)

            If blnAllowSubFolders Then
                Call objRegistry.SetDWORDValue(HKEY_CURRENT_USER, strNewKey, "AllowSubFolders", 1)
            End If

            lngStep = 60

            addTrustedLocation = True

Exit Function

            MsgBox ("Error creating trusted location " & strFolder & " in step " & lngStep & " : " & Err & " " & Err.Description)

    End Function



@Cornelis77 You can add trusted locations with VBA code, from within your application. They can be written as registry keys. I once spent a day to create the VBA function addTrustedLocation below. In short, it checks if the specified location already exists and if not, creates it. Note that your environment may block the creation of trusted locations on the network.