Microsoft Word COM interop from console application

I've got a .NET Core 3.1 console application that's using Word COM interop, except when it tries to create the Microsoft.Office.Interop.Word.Application object it throws an exception:

System.Runtime.InteropServices.COMException (0x80070520): 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. (0x80070520).
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean wrapExceptions, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& hasNoDefaultCtor)
   at System.RuntimeType.CreateInstanceDefaultCtorSlow(Boolean publicOnly, Boolean wrapExceptions, Boolean fillCache)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, Boolean wrapExceptions)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic, Boolean wrapExceptions)
   at System.Activator.CreateInstance(Type type)

This is the constructor call I'm using:

_app = new Application
{
    DisplayAlerts = WdAlertLevel.wdAlertsNone,
    Visible = false,
    FileValidation = MsoFileValidationMode.msoFileValidationSkip,
    Caption = "FOO"
};

What causes this?

Overview

For anyone stumbling into this issue December 2020 or later:

I manage a reporting "server" (actually is a Windows 10 Pro desktop install) that relies on Excel automation via the COM interop. All of the reporting is scheduled via the native Task Scheduler and is set to run even when not signed in (this is configured to use a domain account). Beginning around the 2nd week of December, all of our Excel automation ceased functioning. I knew this was caused by an environment change, as none of our automation code has changed in over 6 months. Initially, I believed it to be a problem with Windows 10 2004/20H2 (as both updates had been applied the first week of December); however, trial and error seems to point to both the aforementioned Windows updates and the latest Office 2016 update (Version 2011).

I ran through the suggested troubleshooting in the linked questions above and other solutions that show up when searching for System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject or Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070520. Steps attempted included registry tweaks, repair installs of Office, and ensuring there were no pending updates for Windows or Office. Initially, re-installing Office seemed to be the fix, as it addressed the first problem (or changed the error, at least). After some more trial and error, I stumbled into the actual resolution, as well as the approximate cause.

Problem

Office automation scheduled via the Windows Task Scheduler will not run following installation of Windows 10 2004/20H2 and Office 2016 (Version 2011).

Resolution

Under Component Services > Computers > My Computer > DCOM Config, locate Office Licensing COM Server 16 and right-click on it. Launch the properties window, then go to the Security tab. Under the Access Permissions header, click on Edit... next to the Customize radio button. Ensure that the user setup to run the automation from the Task Scheduler is present in the group / user list and is granted both Local Access and Remote Access.

Notes + Helpful Links

The underlying cause of this issue appears to have been a loss of permissions in the DCOM Configuration for the Office licensing server due to either the Windows Feature update OR the Office 2016 Version 2011 update.

The following links did not get me to the solution, but were useful in narrowing down the issue:

• FlowHeater Forum (had a useful script and general troubleshooting info)
• Microsoft Answers Solution for error code 80070520
• Microsoft Update Overview for the December 8th update