Office Current Channel build 19929.20090 breaks third-party COM Interop with Outlook — looking for known issue or workaround

Summary

Office Current Channel build 19929.20090 (Version 2604, released April 21, 2026) introduces a regression that breaks COM Interop activation of Outlook.Application from third-party desktop applications. Rolling back to the prior build 19822.20182 (Version 2603) consistently resolves the issue.

Error

Calling applications receive: System.Runtime.InteropServices.COMException (0x80080005): Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).

The failure occurs at COM activation itself (before any Outlook method is invoked), when an external application calls new Outlook.Application() via the Microsoft.Office.Interop.Outlook PIA.

Reproduction

1. Machine running Windows 11, classic Outlook (OUTLOOK.EXE), connected to Microsoft 365 / Exchange Online.
2. Install Office Current Channel build 19929.20090.
3. From a non-elevated user session with Outlook fully running, launch a third-party application that uses Outlook COM Interop to compose/send email (Microsoft.Office.Interop.Outlook PIA, calling new Outlook.Application() then CreateItem(olMailItem)).
4. Observe: COM activation fails with CO_E_SERVER_EXEC_FAILURE.
5. Roll Office back to 19822.20182 via Office Deployment Tool / OfficeC2RClient.exe /update user updatetoversion=16.0.19822.20182.
6. Reproduce step 3: COM activation succeeds, application works as expected.
7. Re-apply 19929.20090: failure returns.

The rollback/re-apply cycle has been validated on the same machine multiple times. The issue is deterministically tied to the build.

What is not the cause (ruled out)

• Not a UTOPIA-specific or vendor-specific issue. Multiple third-party applications using the standard COM Interop pattern are affected.
• Not new vs. classic Outlook. Affected machines have classic Outlook installed, running, and connected. The new Outlook (olk.exe) is not involved in the failing scenario.
• Not elevation mismatch. Verified in non-elevated user contexts on affected machines. PowerShell New-Object -ComObject Outlook.Application succeeds on the same machine in the same user context immediately before/after UTOPIA fails — but with build-dependent results: works on 19822.20182, fails on 19929.20090.
• Not Outlook profile state. Profile recreation provides only transient relief; the issue returns deterministically with the build.
• Not policy/security configuration. A baseline-and-diff comparison of registry policies, DCOM configuration, programmatic access settings, ASR rules, and Outlook COM Add-in registrations between the working (19822.20182) and broken (19929.20090) states shows zero changes outside of Office binaries themselves.
• Not a Windows update. No Windows updates were installed between the working and broken states.

Diff between working and broken builds

A controlled before/after capture on the same machine shows the only changes between 19822.20182 (working) and 19929.20090 (broken) are the following Office binaries:

Of particular note: MSOUTL.OLB (the Outlook COM type library) jumped two major build series, suggesting a non-trivial change to the type library between these releases. This is a plausible suspect for the COM Interop regression but I have no way to inspect what specifically changed.

Environment

• OS: Windows 11
• Office product: Microsoft 365 Apps for Business (O365BusinessRetail)
• Update channel: Current Channel
• Office platform: x64
• Outlook account type: Microsoft 365 / Exchange Online
• Calling applications: 32-bit, using Microsoft.Office.Interop.Outlook PIA

Workaround

Pin affected machines to build 19822.20182 via Office Deployment Tool or registry policy: reg add HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate /v enableautomaticupdates /t REG_DWORD /d 0 /f

Combined with rolling the build back via: "C:\Program Files\Common Files\Microsoft Shared\ClickToRun\OfficeC2RClient.exe" /update user updatetoversion=16.0.19822.20182 displaylevel=true

This is not a sustainable fix — it leaves users without subsequent security updates — but is sufficient until a fixed build is available.

Asks

1. Acknowledgment of the regression in the classic Outlook known-issues page so other admins can find it.
2. Confirmation of which file (OUTLOOK.EXE, MSO.DLL, OLMAPI32.DLL, EMSMDB32.DLL, or MSOUTL.OLB) introduced the regression, and what changed in COM activation behavior.
3. Guidance on whether third-party applications using the standard Microsoft.Office.Interop.Outlook PIA need to update their PIAs, change their threading model, or take other action — or whether this is an unintended regression that will be reverted.
4. Expected build in which a fix will ship.

Happy to provide additional diagnostic output (registry diffs, event logs, process traces) on request.

Dear @Chris Wolfl,

Good day, and thank you for reaching out to the Q&A forum and bringing this issue to our attention.

As a forum moderator, I genuinely wish I could directly access your environment or inspect backend systems to diagnose and resolve this for you. However, our role here is limited to providing general technical guidance and pointing you toward the most effective next steps.

Based on your description and my research, the error “Server execution failed” (HRESULT: 0x80080005) when instantiating Outlook.Application via classic COM Interop (Microsoft.Office.Interop.Outlook) is an issue that has surfaced occasionally following major Office updates. These issues are often related to changes in Outlook startup behavior, COM activation, or DLL loading (for example, OUTLOOK.EXE, MSO.DLL, and related components).

Your specific build (Version 2604 / Build 19929.20090) is very recent, so public reports are still emerging. I checked the Service Health in the Microsoft admin center and did not find any advisory that directly matches your scenario. Additionally, Microsoft’s release notes for this build mention various fixes but do not explicitly call out COM interop or Outlook.Application instantiation issues.

The fact that your controlled rollback test works on Version 2603 (Build 19822.20182) but fails on Version 2604 strongly suggests a regression introduced in the newer build.

For line‑of‑business applications that rely on classic Outlook COM interop, the most reliable immediate workaround is to remain on the previous stable build:

• Use the Office Deployment Tool (ODT), Group Policy, or Intune to defer updates and pin Office to Version 2603 (Build 19822.20182) or earlier.
• This approach helps avoid repeated breakage while protecting application stability.

To ensure the issue is properly tracked and prioritized for a fix, I strongly recommend that the Global Administrator in your organization create a service request with Microsoft Support, including your diagnostic logs and the results of your rollback testing. A technical support engineer can perform a remote session to investigate the situation, verify the backend configurations, and run any necessary synchronization tools to resolve the problem. If the issue requires further attention, they can escalate it to a specialized team for deeper analysis.  For detailed instructions on how to get support, please refer to Get support - Microsoft 365 admin. If you don't know who your IT administrator is, please refer to this article: How do I find my Microsoft 365 admin? - Microsoft Support 

I know this isn't the answer you were hoping for, and it's disappointing when the solutions aren't straightforward. Please know that as a forum moderator, directing you to the correct, specialized support is the most effective help I can provide from my position. Thank you again for your detailed contribution and for sharing your findings so clearly, they’re genuinely helpful to the wider community. I sincerely hope this issue is resolved quickly for you, and I wish you a smooth and swift resolution.

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.

There is no documented known issue in the provided material that specifically calls out Version 2604 (Build 19929.20090) breaking Outlook COM Interop or returning 0x80080005 when creating Outlook.Application.

However, the context does show a clear pattern for similar regressions introduced by specific Office builds that affect Outlook and other Office apps, and how they are handled:

1. Regressions introduced by a specific build are treated as known issues and then fixed in a later build.
2. The recommended short‑term mitigation is to revert Office to the last known good build and temporarily block automatic updates until a fixed build is released.

Examples from the context:

• Outlook 2016 Monthly Channel Version 1805 (Build 9330.2087) caused crashes when external applications interacted with Outlook via COM. This was fixed in the next Monthly Channel build (9330.2118). The guidance was to update Office to the fixed build and, in the interim, restart Outlook to pick up service-side mitigations for POP/IMAP scenarios.
• Microsoft 365 apps on Windows Server 2016 crashed after updating to Version 2412 (Build 18324.20168/20190). The fix was released in Version 2412 (Build 18324.20194), and the documented workaround was to revert to the prior Version 2411 (Build 18227.20152) using officec2rclient.exe /update user updatetoversion=... and optionally disable updates until the fix was available.

Given that rolling back from 2604 (19929.20090) to 2603 (19822.20182) fully restores COM automation in the described environment, the safest supported pattern based on the available documentation is:

1. Keep affected users on the last known good build
   • Revert Office to Version 2603 (19822.20182) using the standard “revert to earlier version of Office” procedure for Microsoft 365 Apps.
   • After reverting, disable automatic updates from within an Office app (File → Office Account → Update Options → Disable Updates) to prevent reinstallation of 2604 until a newer, fixed build is confirmed.
2. Monitor for a newer Current Channel build that supersedes 19929.20090
   • When a newer Current Channel build is released, test COM automation with Outlook in a controlled environment before broadly re‑enabling updates.
3. If server‑side automation is involved
   • If the third‑party application is running Outlook Interop from a service or non‑interactive context, be aware that Office interop is not supported for server‑side automation and is known to be unreliable. The recommended guidance is to avoid Office interop from services and instead use supported APIs or patterns. This does not explain a regression between two desktop builds, but it is relevant if the line‑of‑business app is running in a service context.
4. No change required to third‑party PIA usage is indicated
   • The provided documentation for similar regressions does not require changes to how third‑party apps use the Outlook PIA; the issues were addressed by Office fixes in subsequent builds. The working vs. broken behavior tied only to the Office build strongly suggests this is the same pattern.

In summary, based on the available information, the recommended course is to:

• Keep affected users on Version 2603 (19822.20182) as a workaround.
• Temporarily disable Office updates to avoid reinstalling 2604.
• Plan to move forward once a newer Current Channel build is available and validated, following the same pattern as prior Outlook/Office regression fixes.

References:

• External applications crash sending email through Outlook
• Classic Outlook and Microsoft 365 applications crashing on Windows Server 2016
• How to revert to an earlier version of Office
• SQL Server 2022, Visual Studio 2022 - Microsoft VB 2022 script task interacting with Excel COM Errors - Microsoft Q&A