COM-Exception 0x80070520 when opening MS Word in IIS

▲
-1
▼

I have a .NET Web Service (SOAP) running on IIS that opens a MS Word application via COM.

Out of a sudden this fails on one of our test machines in the integration build with the following exception:

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).

Lately there have been Windows and Office Updates that I think might cause this behavior. Unfortunately when I restore the machine to an earlier backup, the updates get installed automatically and I end up with the same error so I can not reliably prove this. There could also have been infrastructural changes in the company domain but I do not know exactly where to start searching.

The machine is running Windows 10 20H2 with MS Office 2016 click to run. The user running the IIS application is a company domain user and part of the Administrator group.

Other machines (other operating systems of MS Office variants) do have this problem. But I am a afraid that this behavior could wind up on other machines or in production environments too.

I also tested opening MS Word via COM in the PowerShell which works. I saw a lot of google results with something about task schedulers that say I should set the group policy "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network access: Do not allow storage of passwords and credentials for network authentication" to disabled but this is already set to disabled.

.net
iis
ms-word
com
ms-office
asked on Stack Overflow May 12, 2021 by rominator007 • edited May 12, 2021 by macropod

2 Answers

▲
1
▼

I have a .NET Web Service (SOAP) running on IIS that opens a MS Word application via COM.

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.

Read more about that in the Considerations for server-side Automation of Office article.

answered on Stack Overflow May 12, 2021 by Eugene Astafiev
▲
0
▼

First the mandatory disclaimer: as already mentioned by others, what you are trying to do is unsupported, it is unreliable, it can and it will break at unpredictable times; Word will crash or freeze on you for no apparent reason (e.g. on a simple message box that cannot be clicked on), and depending on who uses your Web Service it might be a violation of your MS Office User License.

With all that said:

Keep in mind that the App Pool must be configured to load a User Profile in order to open Word via Automation. Open IIS Manager; under Application Pools right click your App Pool; “Advanced Settings”; under the “Process Model” section, “Load User Profile” must be set to True. It’s possible that someone accidentally turned it off.

If that doesn’t pan out, check also under Event Viewer after restarting the App Pool, to see if there is an error indicating that something is preventing IIS from loading the User Profile for that account.

answered on Stack Overflow May 13, 2021 by Euro Micelli

User contributions licensed under CC BY-SA 3.0