安装Windows 11 2026年6月安全更新(KB5094126)后，一款运行20余年的MFC架构C++遗留程序通过Automation调用Microsoft Word时出现故障，未修改的客户代码同步失效。具体表现为调用Documents.Open()打开本地模板文件时，Word立即抛出**"Type conflict"**异常（底层COleDispatchDriver::InvokeHelperV中m_lpDispatch->Invoke()返回错误码0x80020005）。

代码实现说明：获取Word Documents集合后调用Open()，仅传入固定本地模板路径参数，其余参数均通过COleVariant设置为DISP_E_PARAMNOTFOUND以使用默认值，已排除文件不存在或路径非法问题；且在Word Visual Basic编辑器中可正常打开该模板文件。

排查方向 #

• 验证参数类型与Word Automation接口的匹配性
  安全更新可能严格了参数类型校验，即使是可选参数，DISP_E_PARAMNOTFOUND的传递方式是否符合当前Word版本的要求？尝试将部分可选参数显式传入对应类型的默认值（如bool类型传VARIANT_FALSE，VARIANT类型传VT_EMPTY），替代DISP_E_PARAMNOTFOUND，看是否能绕过类型校验。

• 检查Word Automation接口的参数变化
  该安全更新可能调整了Documents.Open()的参数列表：

  • 确认是否有原可选参数变为必填项，可通过Word对象浏览器（VB编辑器中按F2）查看Documents.Open的最新参数定义，对比代码中传入的参数数量和顺序；
  • 排查是否新增了未文档化的必填参数，尝试按接口定义的完整参数列表传递所有参数（包括显式设置默认值），而非仅传路径和DISP_E_PARAMNOTFOUND。

• 测试不同路径下的模板文件
  虽然推测不是路径权限问题，但可将模板文件移至非AppData\Local路径（如桌面）测试，确认是否是更新后对特定目录的访问限制导致的隐性类型校验失败。

• 对比更新前后Word Automation的行为差异
  在未安装该更新的测试环境中复现原代码逻辑，确认是否仅更新后出现问题；同时尝试使用IDispatch直接调用（绕过MFC的COleDispatchDriver封装），排查是否是MFC封装层与更新后的Word接口不兼容。

• 检查Word安全设置的变更
  安全更新可能调整了Word的宏或Automation安全策略，查看Word选项中的信任中心设置，确认是否启用了限制Automation调用的选项，尝试临时放宽权限测试是否恢复正常。

内容的提问来源于stack exchange，提问作者Thomas Pollehn