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

Question

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

Jonathan Riley 10

I recently updated one of our VB.NET 4.8 applications from 32 bit to 64 bit. The application uses an OleDbConnection using Microsoft.ACE.OLEDB.16.0 to connect to an access database. We noticed that when the application closes, it hangs for around 15 - 20 seconds then crashes with an Access Violation. In the Windows Application Event log I can see a crash event raised with the Faulting module path: C:\Program Files\Common Files\Microsoft Shared\Office16\mso98win32client.dll.

When the app was 32 bit, we used to use the 2010 32 bit access database engine and this worked fine. When the app was changed to use 64bit we moved to the 2016 64bit access database engine redistributable. This worked fine until we receive office updates (even on machines without a full office install). When office is updated the access violation occurs. Reinstalling the 2016 db engine fixes temporarily but then re-occurs when another office update is installed. I have Microsoft Office Professional 2021 64bit.

This example console app demonstrates the problem. When the app closes, it hangs and then gives an application error below:

Imports System.Data.OleDb
Module Module1
    Sub Main()
        Dim connectionString As String = "Provider=Microsoft.ACE.OLEDB.16.0;Data Source=[PATH TO accdb]"
        Dim conn As New OleDbConnection(connectionString)
        If conn Is Nothing Then
            Throw New Exception("Error creating database Connection : connection string <" & ConnectionString & ">")
        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()
                conn = Nothing
            End If
        End Try
    End Sub
End Module

Faulting application name: TestOleDBConnection.exe, version: 1.0.0.0, time stamp: 0x8c26270d

Faulting module name: mso98win32client.dll, version: 0.0.0.0, time stamp: 0x69c7d125

Exception code: 0xc0000005

Fault offset: 0x00000000000afaf3

Faulting process id: 0x6D64

Faulting application start time: 0x1DCC281EEB140D9

Faulting application path: C:\Users\piiremoved\source\repos\TestOleDBConnection\TestOleDBConnection\bin\Debug\TestOleDBConnection.exe

Faulting module path: C:\Program Files\Common Files\Microsoft Shared\Office16\mso98win32client.dll

Report Id:

Faulting package full name:

Faulting package-relative application ID:

0 comments

3 answers

Your answer

Answer 1

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:

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.”
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.
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:

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

Answer 2

Steven-N 25,315 Microsoft External Staff Moderator

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.

Jonathan Riley 10 Reputation points

2026-04-02T15:24:04.5833333+00:00

Thank you for your response, the background information and options.

I tried option 1 as you suggested and it still gives the same access violation error when the application exits.

Changing our application to use ODBC rather than OLEDB as you suggested in option 2 would need serious consideration. Our application is quite large with a number of access database interactions. Database performance is important and historically ODBC has been slower than OLEDB so this may not be a viable option.

Please let me know if you have any more suggestions.
Steven-N 25,315 Reputation points Microsoft External Staff Moderator

2026-04-03T00:21:38.57+00:00
Hi Jonathan Riley

Thank you for confirming the outcome.

The fact that OleDbConnection.ReleaseObjectPool() combined with forced garbage collection did not resolve the issue is an important diagnostic indicator. It suggests that the crash is occurring deeper within the COM/Office Click-to-Run interop layer during the uninitialization sequence, rather than simply being a connection-pool finalizer race condition.

You can attempt to bypass the specific shutdown sequence that triggers the crash by completely disabling OLE DB resource pooling and session-level service components. To do this, append OLE DB Services=-1; (or OLE DB Services=0;) to your existing connection string:

Dim connectionString As String = _ "Provider=Microsoft.ACE.OLEDB.16.0;" & _ "Data Source=C:\PATH\TO\YOUR.accdb;" & _ "OLE DB Services=-1;"

Disclaimer: Because these troubleshooting steps involve modifying database connection behaviors and application lifecycle events, and because I do not have direct access to your database or environment, please ensure you have secured full backups of your application and your Access databases before proceeding.

Regards
Steven-N 25,315 Reputation points Microsoft External Staff Moderator

2026-04-06T01:47:15.2+00:00

Hi Jonathan Riley

Is there any update from you?

If yes, please feel free to let me know.
Jonathan Riley 10 Reputation points

2026-04-07T12:01:13.4166667+00:00

Hi

Thank you for the additional suggestions, I have tried both the settings for OLE DB Services in the connection string but they don't seem to make any difference to the error. The application still hangs and crashes on close and reports the same error in the event log viewer.

Please let me know if you have any more suggestions.
Jonathan Riley 10 Reputation points

2026-04-07T14:58:27.4866667+00:00
One observation, the reg entry for Computer\HKEY_CLASSES_ROOT\CLSID{3BE786A2-0366-4F5C-9434-25CF162E475E}\InprocServer32 on a machine that displays the issue is:

C:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\Office16\ACEOLEDB.DLL

and on a machine that has the access ACE redistributable re-installed:

C:\Program Files\Common Files\Microsoft Shared\OFFICE16\ACEOLEDB.DLL

I updated the registry entry on the “broken” machine and it no longer displays the hanging application or records the error in the windows event log.

Is is correct/advisable to check for the value of this registry key in our software and programmatically correct it or re-install the ACE redistributable?
Steven-N 25,315 Reputation points Microsoft External Staff Moderator

2026-04-08T05:21:49.0966667+00:00
Hi Jonathan Riley

Regarding your concern, in my opinion it is NOT advisable to programmatically correct the registry key; re-installing or repairing the ACE redistributable is the correct and officially recommended approach.

While your registry hack effectively stops the immediate crash, here is why a programmatic registry fix is not recommended for production software:

Permission Blocks: Writing to HKEY_CLASSES_ROOT requires local Administrator privileges. If your users run the application under standard user accounts, attempting to programmatically alter this key on startup will result in an UnauthorizedAccessException and the app will fail.

Fragmented COM State: The Office Click-to-Run update doesn't just change the InprocServer32 path; it alters dozens of associated COM registry entries, TypeLibs, and interface mappings. Overwriting just the InprocServer32 key fixes the exit crash, but it leaves the overall COM registration in a fragmented state, which can trigger unpredictable exceptions elsewhere in your OLEDB interactions.

Regards
Jonathan Riley 10 Reputation points

2026-04-08T07:49:42.0966667+00:00

I complete agree with what you are saying, I wasn't comfortable with the registry hack approach.

What is the best way to test whether Office Click-to-Run has overridden the ACE settings? It doesn't feel like checking the value of the Computer\HKEY_CLASSES_ROOT\CLSID{piiremoved}\InprocServer32 is a reliable and consistent way of checking as the values could be different from machine to machine.

If I can reliably test whether the ACE setting have been overridden then I can trigger the ACE redistributable install.
Jörg 0 Reputation points

2026-04-08T08:26:56.1166667+00:00

Hi @steven-N,
In our case the ACE driver is part of the O365 installer and we have the same problems here.
I tried to repair the O365 Installation (online repair) but the error still occurs.
Can we get a ticket number to this issue? This is a downgrade bug and I need a time frame when this will be fixed by Microsoft. This has a high impact for our customers!
https://developercommunity.visualstudio.com/t/Severe-Downgrade-Bug-in-Microsoft-Access/11068584

Regards,
Day, David 0 Reputation points

2026-04-08T18:42:43.3533333+00:00
The First option did not solve the problem. The crash still occurs/ What is worse when you are using ACE in a IIS process this happens

Looking into the crash this is the stack trace

Mso98win32client.dll!std::unique_ptr<class google::protobuf::TextFormat::FastFieldValuePrinter const ,struct std::default_delete<class google::protobuf::TextFormat::FastFieldValuePrinter const > >::reset(class google::protobuf::TextFormat::FastFieldValuePrinter const *) Unknown

Mso98win32client.dll!Mso::Floodgate::FloodgateClientInitializer::~FloodgateClientInitializer(void) Unknown Mso98win32client.dll!Mso::Floodgate::FloodgateClientInitializer::`vector deleting destructor'(unsigned int) Unknown Mso98win32client.dll!Mso::RefCountedObject<struct Mso::Floodgate::IBeaconFeedback>::Release(void) Unknown Mso98win32client.dll!Mso::Floodgate::ClientCore::EmptyFloodgateEngine::~EmptyFloodgateEngine(void) Unknown Mso98win32client.dll!Mso::Floodgate::ClientCore::EmptyFloodgateEngine::`vector deleting destructor'(unsigned int) Unknown

Looks to be an issue with Floodgate and from what copilot told me that is an internal MS analytics feature.
Steven-N 25,315 Reputation points Microsoft External Staff Moderator

2026-04-09T06:22:51.5833333+00:00

Hi Jonathan Riley

In my opinion, the most reliable way to test if C2R has overridden the ACE settings is to read the default value of the InprocServer32 key and check for the presence of the \root\VFS\ (Virtual File System) directory structure, you can check the approaches below:

Read the default string value from HKEY_CLASSES_ROOT\CLSID\{ID}\InprocServer32.

Convert the path to lowercase and check if it contains \root\vfs\. If it does contain \root\vfs\, the DLL is being loaded from the Office C2R virtualized environment. This confirms the settings have been overridden, and you can safely trigger your ACE redistributable reinstall. Or, if it contains \common files\microsoft shared\office16\, it is safely pointing to the standalone redistributable.

However, as I am forum moderator, I have limited in testing environment, therefore, I highly recommend you follow my suggestions on isolated environment to prevent data loss.

Regards
Jonathan Riley 10 Reputation points

2026-04-09T07:28:10.61+00:00

Hi @Steven-N

Thank you for your suggestion, I have built this into our application and will test on a number of different machines. This feels like the best workaround for my issue at the moment. I am concerned about the longer term compatibility of the ACE and Office versions but we will need to continue to monitor and review.

Many thanks
Steven-N 25,315 Reputation points Microsoft External Staff Moderator

2026-04-10T04:35:07.17+00:00

Hi Jonathan Riley

I'm really happy to hear that the information I shared was useful to you! If you ever need more help, feel free to post your questions in the forum.

Regards
Steven-N 25,315 Reputation points Microsoft External Staff Moderator

2026-04-10T05:00:59.79+00:00

Hi Jörg

Apologize for the inconvenience

If you are the admin of the company and you are using Access 365, I highly recommend you create the support ticket directly via Admin Center for the further help from the specialist team about this.

Hope your problem will be solved soon.

Regards
Steven-N 25,315 Reputation points Microsoft External Staff Moderator

2026-04-10T05:08:25.4833333+00:00

Hi Day, David

In this context, could you try disable Just‑In‑Time debugging on the server and then address the underlying IIS crash.

After disabling JIT, review Event Viewer → Windows Logs → Application to identify the actual faulting module or .NET runtime error that caused w3wp.exe to terminate.

Regards
Jörg 0 Reputation points

2026-04-10T06:16:12.43+00:00

Hi @Steven-N
The problem is that we're a multinational software company and the O365 Admins are not located here.
We're using the OLE Db Driver to connect to databases in our software products.
So, the O365 Admins have nothing to do with our development section :-(

It's always a nightmare to get in contact with Microsoft from the point of view of an R&D department.

Regards
Steven-N 25,315 Reputation points Microsoft External Staff Moderator

2026-04-10T07:12:13.9+00:00

Hi Jörg

I understand that this situation can be inconvenient and frustrating, especially given the organizational boundaries between your development team and the Microsoft 365 administration. I sincerely apologize for any inconvenience this may cause.

However, as a forum moderator, I do not have visibility into internal tenant configurations nor the ability to escalate or engage Microsoft directly on behalf of a specific organization or department. My role here is limited to providing guidance and clarification based on publicly available information and documented behavior.

Thank you for your understanding

Regards

Answer 3

Jörg 0

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 '*'§&§

0 comments