After installing Windows Update KB5094126 (June 2026) , our application fails when opening Word via COM automation. Error: HRESULT 0x80020005 (DISP_E_TYPEMISMATCH) Type mismatch Happens during Documents.Open() (IDispatch call) Fully reproducible Works again after uninstalling KB5094126 Impact: Breaks Word integration / reporting completely Affects multiple environments Tested with: Word 2013 Word 2021 Microsoft 365 → So not Office-specific, likely COM/Windows layer Question: Has anyone seen this after KB5094126? Was there a change in COM/OLE automation or VARIANT handling in this update?

Nearly 500 customers have the problem , all Word Version with Remote COM ! .Open has definitiv a problem ! Your software stack is doing this, after deinstalling KB5094127 the problem was gone ! Get on your seats and repair it, very sad because of our customers are very sad ! Microsoft sucks ! C++

It's happening with software I work on also (C++) It appears to be mostly related to using positional (non-named) parameters in methods that have optional parameters and passing vMissing for some of the optional parameters. COleVariant vMissing((long)DISP_E_PARAMNOTFOUND, VT_ERROR);

Hi @Daratha, Paul Thank you for sharing your concern. I’ve tested Word COM automation in my environment using PowerShell on a device running Windows with KB5094126 installed (OS Build 26200.8655). In this setup, both Word startup and the Documents.Open() call completed successfully without any errors. This suggests that the update does not universally break COM automation or Word integration. Based on your description and findings so far, it appears the issue is triggered after installing KB5094126, but the behavior may vary depending on the specific system configuration, runtime environment, and how parameters are passed during Word automation. Currently, Microsoft has not published any official documentation or known issue related to this behavior yet. To help you reach your goal more effectively, I recommend engaging with [GitHub Community Forum] for a deeper technical dive or to connect with individuals who have relevant experience and expertise. Some approaches may behave differently or be restricted depending on your specific environment akknd configuration. These forums include many experienced developers and Microsoft specialists who can assist with troubleshooting and guidance. Apologies for directing you to the relevant development support channel. As moderators in this forum, we do not have access to backend systems or the ability to directly influence Microsoft product behavior. Our guidance is therefore based on publicly available Microsoft documentation and resources. That said, I’ll do my best to provide additional insight where possible. If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 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.

After installation of KB5094126 the Word integration over COM fails

Daratha, Paul 95

After installing Windows Update KB5094126 (June 2026), our application fails when opening Word via COM automation.

Error:

HRESULT 0x80020005 (DISP_E_TYPEMISMATCH)
Type mismatch

Happens during Documents.Open() (IDispatch call)
Fully reproducible
Works again after uninstalling KB5094126

Impact:

Breaks Word integration / reporting completely
Affects multiple environments

Tested with:

Word 2013
Word 2021
Microsoft 365

→ So not Office-specific, likely COM/Windows layer

Question: Has anyone seen this after KB5094126? Was there a change in COM/OLE automation or VARIANT handling in this update?

Daratha, Paul 95 Reputation points

2026-06-11T19:00:40.4933333+00:00
Other sources complains about same problem. See

https://www.reddit.com/r/sysadmin/comments/1u31bje/kb5094126_breaking_word_integration_with_some/?rdt=38900

https://forums.zotero.org/discussion/132111/word-for-windows-zotero-experienced-an-error-updating-your-document
Viorel 127.3K Reputation points

2026-06-11T19:05:54.51+00:00

Which code has to be changed?
Leigh Menzel 10 Reputation points

2026-06-11T21:19:51.19+00:00

Yes, we are having the exact same issue with our software. I am looking for a solution now but was thinking I might update our Word and Excel reporting to a later version. You mentioning that it is also happening with Word 2021 and Office 365 is a huge help, thanks. I won't bother with that step for now then.
Lahinirina, Eric 15 Reputation points

2026-06-12T10:15:01.58+00:00

We are having the exact same issues. We are using Word COM automation with C++/MFC. And what we see so far is that calling a Word object method through a COleDispatchDriver inherited class crashes if you provide an optionnal parameter with COleVariant vtMissing((long)DISP_E_PARAMNOTFOUND, VT_ERROR);

This issue is quicky affecting all of our customers worldwide.
Leandro Rodrigues 5 Reputation points

2026-06-12T14:54:25.5366667+00:00

I've had the same issue with the OLE automation, solved after the hotfix removal.
Alan Reagan 16 Reputation points

2026-06-12T17:18:32.7333333+00:00

A vendor with affected software is attributing it to changes to Virtualization‑Based Security (VBS), Hypervisor‑Enforced Code Integrity (HVCI), and updated code integrity baselines. KB5094126 covers critical vulnerabilities. This needs to be fixed with Known Issue Rollback so KB5094126 doesn't have to be removed.
Koby Roberts 0 Reputation points

2026-06-16T01:02:30.42+00:00

I was able to use the Open method. However, I had to go straight IDispatch. I have to go around the MFC Wrappers.
Justin 30 Reputation points

2026-06-16T14:43:17.18+00:00

@Jürgen Hillmann

Nice to hear!!

I'm from Germany... ;-)
Jürgen Hillmann 5 Reputation points

2026-06-16T14:45:37.0266667+00:00

oh cool , i am also from Germany -

die Deutschen sind doch nicht so schlecht ! :-)
Jürgen Hillmann 5 Reputation points

2026-06-16T14:46:28.0666667+00:00

@Justin hope MS is not changing this behaviour anymore !!!!!
Houmard Matthias 0 Reputation points

2026-06-17T07:54:08.12+00:00

Following the installation of KB5094126, not only was the data transfer process in Word blocked, but the OLE or COM data transfer process in Excel was also blocked by third-party software. Interestingly, in Excel, the table was created in each instance, the header rows were visible and correct, but the table was not populated with content.
ChuckieAJ 411 Reputation points

2026-06-24T16:40:08.1666667+00:00

I am experiencing this now too with Word automation, including my userbase.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer accepted by question author

Homero Junior 80

My integration had been having issues ever since the update that broke it. All it took was installing this update—KB5101650—and everything started working again. Just install update KB5101650, restart, and you're all set.

0 comments

11 additional answers

Jürgen Hillmann 5 Reputation points

2026-06-12T06:32:45.7866667+00:00

Nearly 500 customers have the problem , all Word Version with Remote COM ! .Open has definitiv a problem ! Your software stack is doing this, after deinstalling KB5094127 the problem was gone !

Get on your seats and repair it, very sad because of our customers are very sad !

Microsoft sucks ! C++
Was this answer helpful?

1 person found this answer helpful.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Greg Pryor 10 Reputation points

2026-06-12T04:08:51.5666667+00:00

It's happening with software I work on also (C++)

It appears to be mostly related to using positional (non-named) parameters in methods that have optional parameters and passing vMissing for some of the optional parameters.
COleVariant vMissing((long)DISP_E_PARAMNOTFOUND, VT_ERROR);
Was this answer helpful?

10+ people found this answer helpful.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Hin-V 16,830 Reputation points Microsoft External Staff Moderator

2026-06-11T21:38:12.3566667+00:00

Hi @Daratha, Paul

Thank you for sharing your concern.

I’ve tested Word COM automation in my environment using PowerShell on a device running Windows with KB5094126 installed (OS Build 26200.8655). In this setup, both Word startup and the Documents.Open() call completed successfully without any errors. This suggests that the update does not universally break COM automation or Word integration.

Based on your description and findings so far, it appears the issue is triggered after installing KB5094126, but the behavior may vary depending on the specific system configuration, runtime environment, and how parameters are passed during Word automation.

Currently, Microsoft has not published any official documentation or known issue related to this behavior yet. To help you reach your goal more effectively, I recommend engaging with [GitHub Community Forum] for a deeper technical dive or to connect with individuals who have relevant experience and expertise. Some approaches may behave differently or be restricted depending on your specific environment akknd configuration. These forums include many experienced developers and Microsoft specialists who can assist with troubleshooting and guidance.

Apologies for directing you to the relevant development support channel. As moderators in this forum, we do not have access to backend systems or the ability to directly influence Microsoft product behavior. Our guidance is therefore based on publicly available Microsoft documentation and resources. That said, I’ll do my best to provide additional insight where possible.

If you have any additional concerns, feel free to comment below. I would be more than happy to assist.

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?

4 people found this answer helpful.
Gurdeep Ghai 10 Reputation points

2026-06-11T23:44:13.1+00:00

We are experiencing the same issue in our environment.

After installation of KB5094126, our Word COM automation started failing with a DISP_E_TYPEMISMATCH (0x80020005) / "Type mismatch" error when calling Documents.Open(). The issue was not present prior to the update.

Our affected systems are running Windows 11 Pro version 25H2, OS Build 26200.8457, Windows 11 Pro version 25H2, OS Build 26200.8524.

As part of our investigation, we uninstalled KB5094126 on an affected machine and the issue was resolved immediately. Reinstalling the update caused the issue to reoccur. This suggests a strong correlation between KB5094126 and the Word COM automation failure in our environment.

We are posting this to confirm that the issue is not isolated to a single environment and would appreciate confirmation as to whether Microsoft is actively investigating this behavior or has received additional reports.

Argos Solutions 0 Reputation points

2026-06-12T00:14:31.5633333+00:00

We are experiencing the same issue in our environment.

After uninstalling KB5094126 on an affected machine and the issue was resolved immediately.

Daratha, Paul 95 Reputation points

2026-06-12T06:10:13.5133333+00:00

We see the same on Windows 10 after having KB5094127 installed.

Because many other software vendors have same problem and in meanwhile each of our customers on different OS and Office versions are impacted, the issue must be deep in one of those updates.

Yes, with Powershell we were not able to reproduce the problem.

Gabriele 20 Reputation points

2026-06-12T06:42:59.4566667+00:00

Hi, your test is wrong. By calling via Powershell, COM interfaces they are called via early binding. The problem only occurs via late binding COM calls (via dispID). Something has changed in COM's low level code that does the marshaling of argument types

Lahinirina, Eric 15 Reputation points

2026-06-12T10:10:52.3966667+00:00

We are having the exact same issues. We are using Word COM automation with C++/MFC. And what we see so far is that calling a Word object method through a COleDispatchDriver inherited class crashes if you provide an optionnal parameter with COleVariant vtMissing((long)DISP_E_PARAMNOTFOUND, VT_ERROR);

This issue is quicky affecting all of our customers worldwide.

Adrian Jones 10 Reputation points

2026-06-14T14:07:26.51+00:00

As per the posts above the installation of KB5094127 has caused the COM integration to also stop working within in our application with Type Mismatch errors . Our application is a C++ / mfc application with many 1,000's of users. The only current workaround is to uninstall KB5094127 until the problem has been fixed by Microsoft.

The impact of this is issue is very high and this is being treated as a major incident.

Uninstalling KB5094127 has implication for Cyber Essentials Plus and therefore is a very short term solution.

Arjan Bakker 5 Reputation points

2026-06-16T08:22:03.6166667+00:00

In our case the problem occurs when calling a function that has multiple variant typed parameters. When calling it using the same object for multiple parameters, only the last parameter gets the correct object. All the other parameters will be empty.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

After installation of KB5094126 the Word integration over COM fails

11 additional answers

Your answer