After updating Microsoft 365 Apps / Access to build 16.0.20026.20182, our ASP.NET Web API application began crashing. The IIS worker process (w3wp.exe) terminates with an unhandled fault in mso20win32client.dll whenever application code calls into the Acc

Prashant Nichal 0 Reputation points
2026-07-03T09:59:08.09+00:00

After updating Microsoft 365 Apps / Access to build 16.0.20026.20182, our ASP.NET Web API application began crashing. The IIS worker process (w3wp.exe) terminates with an unhandled fault in mso20win32client.dll whenever application code calls into the Access Database Engine (ACE OLE DB) through COM to read an Access (.mdb) database.

This worked correctly on the previous Office/ACE build. Rolling back the Office/ACE update immediately resolves the crash, which strongly indicates a regression introduced by this update.

  1. Environment
Item Value
OS Windows Server 2019 LTSC (build 10.0.17763)
Application ASP.NET Web API (.NET Framework 4.8) hosted in IIS
Faulting process c:\windows\system32\inetsrv\w3wp.exe, version 10.0.17763.1
Office / MSO build 16.0.20026.20166 (loaded in dump); update reported as 16.0.20026.20182
ACE modules ACECORE.DLL / ACEES.DLL / ACEOLEDB.DLL — 16.0.20026.20010
Data access ADO (msado15.dll) + ACE OLE DB provider reading a .mdb file, invoked via COM automation
  1. Symptoms / Windows Error Reporting data

From the Application event log (Application Error 1000):

Faulting application name: w3wp.exe, version: 10.0.17763.1

Faulting module name: mso20win32client.dll, version: 0.0.0.0, time stamp: 0x6a2cb210

Exception code: 0x1e89a3d4

Fault offset: 0x00000000004408cd

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

Report Id: 771657ba-8cd3-4b51-b69b-734d700f44bb

Client-side, the in-flight HTTP request dies mid-execution and surfaces as "A task was canceled" (the request thread is destroyed when the worker process crashes).

  1. Crash-dump analysis (user-mode dump of w3wp.exe)

A full user-mode dump was captured via WER LocalDumps. Analysis confirms:

Faulting thread call stack (managed → native transition):

InlinedCallFrame

InlinedCallFrame

IL_STUB_CLRtoCOM <-- managed→native COM call that faulted

<app>.API CALL

<app>.API CALL

... (ASP.NET Web API pipeline) ...

The fault occurs precisely at the COM transition into the ACE-backed component (a ListAll()/recordset read against the .mdb), inside native Office code — not in managed application code.

Patched modules confirmed loaded at crash time:

  • mso20win32client.dll — 16.0.20026.20166 (the faulting module)
  • mso.dll, mso30/40/50/98win32client.dll — 16.0.20026.20166
  • ACECORE.DLL, ACEES.DLL, ACEOLEDB.DLL — 16.0.20026.20010

Exception objects found on the managed heap:
Count Exception Detail
19 System.Runtime.InteropServices.COMException HRESULT 0x8004E004 — "There is no MTS context available"
5 System.InvalidCastException HRESULT 0x80004002 — "Specified cast is not valid" (COM QueryInterface)
1 System.StackOverflowException process-fatal, uncatchable
1 System.ExecutionEngineException process-fatal, uncatchable
1 System.OutOfMemoryException during the native ACE call

The StackOverflowException / ExecutionEngineException explain why the entire worker process terminates rather than returning a handled error — the failure originates in native Office code and cannot be caught by managed exception handling.

  1. Steps to reproduce
  2. On a server with Microsoft 365 Apps / ACE build 16.0.20026.20182, host an application that uses the ACE OLE DB provider (via COM/ADO) to read an Access .mdb.
  3. Invoke the code path that opens the recordset from the .mdb.
  4. w3wp.exe faults in mso20win32client.dll (Application Error 1000, exception code 0x1e89a3d4).
  5. Workaround currently in place
  • Rolling back / pinning the Office-ACE build to the pre-16.0.20026 version stops the crashes completely. This is our only current mitigation and confirms the update is the trigger.
  1. Business impact

The affected API is used in production. On our server-farm environment the crash occurs on essentially every call to the affected endpoint, causing repeated worker-process recycles and failed requests for all users on that worker.

  1. Questions / requests for Microsoft
  2. Is this a known regression in the Office/ACE 16.0.20026.20182 build affecting the ACE OLE DB provider / mso20win32client.dll?
  3. Is a fix or fixed build available or planned? If so, which build and target date?
  4. What is the recommended supported configuration for reading Access .mdb data from a server-side service given this change?
  5. Is there a supported way to pin the ACE component to a known-good version while remaining on a current Office channel?After updating Microsoft 365 Apps / Access to build 16.0.20026.20182, our ASP.NET Web API application began crashing. The IIS worker process (w3wp.exe) terminates with an unhandled fault in mso20win32client.dll whenever application code calls into the Access Database Engine (ACE OLE DB) through COM to read an Access (.mdb) database. This worked correctly on the previous Office/ACE build. Rolling back the Office/ACE update immediately resolves the crash, which strongly indicates a regression introduced by this update.
    1. Environment
    Item Value
    OS Windows Server 2019 LTSC (build 10.0.17763)
    Application ASP.NET Web API (.NET Framework 4.8) hosted in IIS
    Faulting process c:\windows\system32\inetsrv\w3wp.exe, version 10.0.17763.1
    Office / MSO build 16.0.20026.20166 (loaded in dump); update reported as 16.0.20026.20182
    ACE modules ACECORE.DLL / ACEES.DLL / ACEOLEDB.DLL — 16.0.20026.20010
    Data access ADO (msado15.dll) + ACE OLE DB provider reading a .mdb file, invoked via COM automation
    1. Symptoms / Windows Error Reporting data
    From the Application event log (Application Error 1000): Faulting application name: w3wp.exe, version: 10.0.17763.1 Faulting module name: mso20win32client.dll, version: 0.0.0.0, time stamp: 0x6a2cb210 Exception code: 0x1e89a3d4 Fault offset: 0x00000000004408cd Faulting module path: C:\Program Files\Common Files\Microsoft Shared\Office16\mso20win32client.dll Report Id: 771657ba-8cd3-4b51-b69b-734d700f44bb Client-side, the in-flight HTTP request dies mid-execution and surfaces as "A task was canceled" (the request thread is destroyed when the worker process crashes).
    1. Crash-dump analysis (user-mode dump of w3wp.exe)
    A full user-mode dump was captured via WER LocalDumps. Analysis confirms: Faulting thread call stack (managed → native transition): InlinedCallFrame InlinedCallFrame IL_STUB_CLRtoCOM <-- managed→native COM call that faulted <app>.API CALL <app>.API CALL ... (ASP.NET Web API pipeline) ... The fault occurs precisely at the COM transition into the ACE-backed component (a ListAll()/recordset read against the .mdb), inside native Office code — not in managed application code. Patched modules confirmed loaded at crash time:
    • mso20win32client.dll — 16.0.20026.20166 (the faulting module)
      • mso.dll, mso30/40/50/98win32client.dll — 16.0.20026.20166
        • ACECORE.DLL, ACEES.DLL, ACEOLEDB.DLL — 16.0.20026.20010
    Exception objects found on the managed heap:
    Count Exception Detail
    19 System.Runtime.InteropServices.COMException HRESULT 0x8004E004 — "There is no MTS context available"
    5 System.InvalidCastException HRESULT 0x80004002 — "Specified cast is not valid" (COM QueryInterface)
    1 System.StackOverflowException process-fatal, uncatchable
    1 System.ExecutionEngineException process-fatal, uncatchable
    1 System.OutOfMemoryException during the native ACE call
    The StackOverflowException / ExecutionEngineException explain why the entire worker process terminates rather than returning a handled error — the failure originates in native Office code and cannot be caught by managed exception handling.
    1. Steps to reproduce
    2. On a server with Microsoft 365 Apps / ACE build 16.0.20026.20182, host an application that uses the ACE OLE DB provider (via COM/ADO) to read an Access .mdb.
    3. Invoke the code path that opens the recordset from the .mdb.
    4. w3wp.exe faults in mso20win32client.dll (Application Error 1000, exception code 0x1e89a3d4).
    5. Workaround currently in place
      • Rolling back / pinning the Office-ACE build to the pre-16.0.20026 version stops the crashes completely. This is our only current mitigation and confirms the update is the trigger.
    6. Business impact
    The affected API is used in production. On our server-farm environment the crash occurs on essentially every call to the affected endpoint, causing repeated worker-process recycles and failed requests for all users on that worker.
    1. Questions / requests for Microsoft
    2. Is this a known regression in the Office/ACE 16.0.20026.20182 build affecting the ACE OLE DB provider / mso20win32client.dll?
    3. Is a fix or fixed build available or planned? If so, which build and target date?
    4. What is the recommended supported configuration for reading Access .mdb data from a server-side service given this change?
    5. Is there a supported way to pin the ACE component to a known-good version while remaining on a current Office channel?
Microsoft 365 and Office | Access | For business | Windows

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Karl Donaubauer 3,501 Reputation points MVP
    2026-07-04T07:39:29.0166667+00:00

    Hi,

    I asked the Access product team: They are aware of this problem and have already created a fix which will be released in version 2607.

    If you want to verify the fix: It's included in build 16.0.20228.20014 that should be available in the Current Channel Preview later today.

    Servus
    Karl

    Access Forever, News, DevCon
    Access-Entwickler-Konferenz AEK

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  2. Michelle-N 20,735 Reputation points Microsoft External Staff Moderator
    2026-07-03T12:45:43.7933333+00:00

    Hi @Prashant Nichal

    Based on the highly detailed telemetry and crash dump analysis you provided, I understand that your production ASP.NET Web API application hosting on IIS (.NET Framework 4.8 / Windows Server 2019) began crashing immediately after updating Microsoft 365 Apps / Access to build 16.0.20026.20182.

    Specifically, the IIS worker process (w3wp.exe) terminates with an unhandled process-fatal StackOverflowException / ExecutionEngineException stemming from the native Office module mso20win32client.dll whenever your managed code initiates a COM/ADO call via the ACE OLE DB provider to read an Access (.mdb) database. Rolling back the Office/ACE update instantly resolves the issue, confirming a regression introduced by this specific build.

    Given the depth of your diagnostic data, here is the current outlook and the recommended path forward:

    Based on currently available public Microsoft documentation, there is no official tracker, public advisory, or confirmed knowledge base (KB) article explicitly documenting this mso20win32client.dll / ACE OLE DB crash within w3wp.exe for build 16.0.20026.20182. Because it is not yet publicly documented as a known issue, a specific fixed build number or targeted patch release date has not been announced on public channels.

    Your current workaround, rolling back and pinning the Microsoft 365 Apps Click-to-Run installation to the last known-good pre-16.0.20026 version is the most stable approach for your production environment right now.

    To get this escalated to the product team and to determine if a private hotfix is available, I highly recommend that you raise a formal case via Engage Support.

    I hope this information helps you move closer to a permanent fix.

    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.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.