在 IIS 中打开 MS Word 时出现 COM-Exception 0x80070520

Question

我有一个在 IIS 上运行的 .NET Web 服务 (SOAP)，它通过 COM 打开一个 MS Word 应用程序。

在集成构建中我们的一台测试机器上突然失败了，但出现以下异常：

Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80070520 A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520).

最近出现了我认为可能导致此行为的 Windows 和 Office 更新。不幸的是，当我将机器恢复到较早的备份时，更新会自动安装，我最终会遇到同样的错误，所以我无法可靠地证明这一点。 公司领域的基础设施也可能发生变化，但我不知道从哪里开始搜索。

本机运行 Windows 10 20H2 和 MS Office 2016 点击运行。 运行 IIS 应用程序的用户是公司域用户和管理员组的一部分。

其他机器（MS Office 变体的其他操作系统）确实有这个问题。但我担心这种行为也会出现在其他机器或生产环境中。

我还测试了在 PowerShell 中通过 COM 打开 MS Word 是否有效。 我看到很多关于任务计划程序的谷歌结果说我应该设置组策略“计算机配置\Windows设置\安全设置\本地策略\安全选项\网络访问：不允许存储用于网络身份验证的密码和凭据" 禁用，但这已设置为禁用。

Answer 1

我有一个在 IIS 上运行的 .NET Web 服务 (SOAP)，它通过 COM 打开一个 MS Word 应用程序。

Microsoft 目前不推荐也不支持任何无人值守、非交互式客户端应用程序或组件（包括 ASP、ASP.NET、DCOM 和 NT 服务）的 Microsoft Office 应用程序自动化，因为 Office 可能表现出不稳定Office 在此环境中运行时的行为和/或死锁。

如果您要构建在服务器端上下文中运行的解决方案，您应该尝试使用已确保无人值守执行安全的组件。或者，您应该尝试找到允许至少部分代码在客户端运行的替代方案。如果您使用服务器端解决方案中的 Office 应用程序，该应用程序将缺少许多成功运行所需的功能。此外，您将在整体解决方案的稳定性方面承担风险。

在Considerations for server-side Automation of Office 文章中了解更多信息。

Answer 2

首先是强制性免责声明：正如其他人已经提到的，您尝试做的事情不受支持，不可靠，它可以而且会在不可预测的时间中断； Word 将在没有明显原因的情况下使您崩溃或冻结（例如，在无法单击的简单消息框上），并且根据谁使用您的 Web 服务，这可能违反了您的 MS Office 用户许可证。

说了这么多：

请记住，应用程序池必须配置为加载用户配置文件才能通过自动化打开 Word。打开 IIS 管理器；在应用程序池下右键单击您的应用程序池； “高级设置”;在“流程模型”部分下，“加载用户配置文件”必须设置为 True。可能有人不小心把它关掉了。

如果没有成功，请在重新启动应用程序池后检查事件查看器下的内容，查看是否有错误指示阻止 IIS 加载该帐户的用户配置文件。