OleDbConnection using Microsoft.ACE.OLEDB.16.0 causes an access violation in mso98win32client.dll on app closing

Same problem here,
https://developercommunity.visualstudio.com/t/Severe-Downgrade-Bug-in-Microsoft-Access/11068584

To get in contact with a Microsoft Support Expert is nearly impossible if you really have a problem... This is so pain in the '*'§&§

Hi Jonathan Riley

As far as I know, this is the conflict between Office Click-to-Run (C2R) and the standalone ACE redistributable occurs in two stages:

Office C2R uses a virtualized COM environment. When the standalone ACE redistributable is installed, both compete for the Microsoft.ACE.OLEDB.16.0 registry key. Frequent Office updates consistently overwrite the redistributable’s entries, causing the system to load conflicting binaries (like the unstable mso98win32client.dll shim).

The 0xC0000005 access violation happens during process termination. The .NET finalizer thread attempts to release COM wrappers (RCWs) while the native OS is simultaneously unloading the underlying DLLs. This creates a use-after-free error as .NET tries to communicate with a memory address that has already been cleared.

Given this context, you can try two workaround options below first and let me know the results:

Option 1:

Explicitly release the connection pool and force a full GC cycle before the process exits. This ensures all COM RCWs are released while the native libraries are still alive.

Imports System.Data.OleDb
Imports System.Runtime.InteropServices
Module Module1
    Sub Main()
        Dim connectionString As String = "Provider=Microsoft.ACE.OLEDB.16.0;Data Source=[PATH TO accdb]"
        Try
            DoWork(connectionString)
        Finally
            ' Critical: flush the OleDb connection pool and force COM cleanup
            ' BEFORE the runtime begins its shutdown sequence
            OleDbConnection.ReleaseObjectPool()
            GC.Collect()
            GC.WaitForPendingFinalizers()
            GC.Collect()
            GC.WaitForPendingFinalizers()
        End Try
    End Sub
    Private Sub DoWork(connectionString As String)
        Using conn As New OleDbConnection(connectionString)
            conn.Open()
            Console.WriteLine("Connection Open!")
            ' ... do work ...
        End Using ' Dispose is called here automatically
        Console.WriteLine("Connection Closed!")
    End Sub
End Module

Option 2: Switch from OLEDB to ODBC

To use this, you would switch your imports to System.Data.Odbc:

Imports System.Data.Odbc
Module Module1
    Sub Main()
        ' Use the ODBC driver instead of OLEDB
        Dim connectionString As String = "Driver={Microsoft Access Driver (*.mdb, *.accdb)};Dbq=[PATH TO accdb];"
        Dim conn As New OdbcConnection(connectionString)
        
        If conn Is Nothing Then
            Throw New Exception("Error creating database Connection")
        End If
        
        Try
            conn.Open()
            Console.WriteLine("Connection Open!")
        Catch e As Exception
            Console.WriteLine("Error: " & e.Message)
            Throw e
        Finally
            If conn IsNot Nothing Then
                If conn.State <> ConnectionState.Closed Then
                    conn.Close()
                    Console.WriteLine("Connection Closed!")
                End If
                conn.Dispose()
            End If
        End Try
    End Sub
End Module

Hope my answer will help you.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

The crash is consistent with a conflict between different ACE/Office components and how the ACE OLE DB provider is exposed on a 64‑bit system, especially after Office updates.

Key points from the provided information:

1. Jet vs ACE and 32‑/64‑bit
   • Jet OLE DB and Jet ODBC are 32‑bit only and cannot be used from a 64‑bit process.
   • ACE (Access Database Engine) exists in both 32‑bit and 64‑bit versions, but normally only one architecture is allowed on a device and must match the Office architecture.
   • When Office is installed as Click‑to‑Run, ACE may be isolated so that external applications cannot reliably use it unless ACE is installed correctly outside the virtualization bubble.

   “ACE is provided in both 32-bit and 64-bit architectures. However, only one architecture is allowed on a device. The architecture of ACE must match the architecture of the Office installation on that computer.”

   “Click-to-Run installations of Office run in an isolated virtual environment… Some applications outside Office may not be aware of where to look for the installation in the isolated environment.”

2. Office/ACE version interaction and updates
   • When multiple Office/ACE components are present (for example, Office 365/2021 plus older ACE redistributables), Office updates can change which ACE bits are used for OLE DB.
   • There is a documented case where Office 365 version 2002 changed which ACE provider is used for COM OLE DB, and that change altered connection behavior (resource pooling, locking, etc.). This demonstrates that Office updates can change ACE/OLE DB behavior for external applications.

   “Starting with version 2002 of Office 365, the version of Ace shipped with Office 365 will be the provider for COM OLEDB interfaces, while with prior versions, the version of Ace included with the MSI product would be used.”

   In the described scenario, after an Office update, the ACE/OLE DB stack that is actually loaded changes, and the crash occurs in an Office DLL (mso98win32client.dll) on process shutdown.
3. Coexistence of 32‑bit and 64‑bit ACE drivers
   • There is a supported workaround to have both 32‑bit and 64‑bit Access Database Engine drivers co‑exist, but it requires:
     1. Completely uninstalling all Access drivers.
     2. Cleaning specific Office registry keys (mso.dll entries) to ensure no leftover ACE/Office bits are referenced.
     3. Installing the 64‑bit ACE redistributable silently.
     4. Deleting the mso.dll registry key again.
     5. Installing the 32‑bit ACE redistributable silently.
   • This procedure ensures that the correct ACE binaries are registered and reduces conflicts between Office and ACE redistributables.

   “Follow the steps below to have both 32-bit and 64-bit Access drivers co-exist on your machine:

   1. Uninstall all the Access driver versions from your machine.
   2. Go to the registry editor… and navigate to… HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Common\FilesPaths and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\FilesPaths.
   3. Check if the "mso.dll" registry key is present… If the key is present, this means that you haven't uninstalled all the drivers.
   4. Download a new version of Microsoft Access Database Engine… install the 64-bit driver using command prompt (CMD) with the command AccessDatabaseEngine_x64.exe /quiet…
   5. Go back to registry editor and delete the "mso.dll" registry key and its value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\FilesPaths. Lastly, install the 32-bit driver using command prompt (CMD) with the command AccessDatabaseEngine.exe /quiet… This will allow both the 32-bit and 64-bit drivers to co-exist on your machine.”

Given the behavior described (works until Office updates, then crashes in an Office DLL on shutdown), the most relevant mitigations from the context are:

1. Ensure a clean, consistent ACE installation
   • Remove all existing Access Database Engine versions and related Office ACE components.
   • Clean the mso.dll registry entries under the Office 14.0 and 16.0 Common\FilesPaths keys as described.
   • Reinstall the 64‑bit Access Database Engine 2016 Redistributable using the documented silent install command so that the 64‑bit ACE provider is correctly registered for external applications.
   • If 32‑bit Office components or tools are also needed, follow the documented coexistence steps exactly so that both 32‑bit and 64‑bit ACE can coexist without conflicting registrations.
2. Align architecture and usage
   • Confirm that the application is compiled as 64‑bit and that the installed ACE provider is 64‑bit.
   • Avoid mixing mismatched architectures (for example, 64‑bit app with only 32‑bit ACE, or vice versa), as this can cause provider load failures or undefined behavior.
3. Avoid relying on the Office Click‑to‑Run ACE for external apps
   • For a stable external application, rely on the Access Database Engine redistributable rather than the ACE that ships inside a Click‑to‑Run Office installation, because the latter is virtualized and can change behavior with Office updates.
   • The documented “Unable to use the Access ODBC, OLEDB, or DAO interfaces outside Office Click-to-Run applications” article shows that C2R Office can prevent reliable use of ACE from external processes; using the redistributable ACE outside the C2R bubble is the supported pattern.

If, after cleaning and reinstalling ACE as above, the crash still occurs only after specific Office updates, the next step would be to treat it as an Office/ACE bug and open a support case with Microsoft, providing crash dumps that show the fault in mso98win32client.dll during ACE provider unload.

References:

• Microsoft OLE DB Provider for Jet and Jet ODBC driver are available in 32-bit versions only
• Unable to use the Access ODBC, OLEDB, or DAO interfaces outside Office Click-to-Run applications
• Can't establish a connection to Access Database Engine OLE DB
• Office error: Accdb remains locked after OLEDB connection is closed