I have some controls I'm trying to add to the document actions pane for a custom template. Any time I do so, I get this error:
System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
I have come across a variety of search results related to this problem, and based on some of them, it seems this can happen in previous versions of Word when the document map is enabled (which has been moved into the new navigation pane in 2010). But mine is definitely disabled, so that isn't much help. I tried enabling it to see the difference, and the error changes to some combination of the above error and these two:
Exception from HRESULT: 0x8004063B
You are currently viewing this document in multiple windows. To attach an XML expansion pack, you must first close all additional windows so that you are viewing the document in only one window. (I'm not viewing it in multiple windows or trying to attach an XML schema)
But that's kind of irrelevant, I just recorded it here for posterity.
Anyway, this only happens on certain machines. Here's what I found that differs. There's a checkbox in File > Options > Trust Center > Trust Center Settings > Message Bar called Enable Trust Center Logging. This undocumented setting outputs to:
%USERPROFILE%/AppData/Local/Microsoft/Office/TCDiag/WDTCD.log
In that log file, I see many entries like this one:
Content Type: SmartTags
Binary: "c:\Program Files (x86)\Common Files\Microsoft Shared\VSTO\vstoee.dll"
Certificate: Microsoft Corporation
Certificate Signature: Microsoft Code Signing PCA
Certificate Status: Trusted
Trust Center Decision: Enable Content
Most of these are the same between those machines where the actions pane works, and those where it doesn't. However, the entry above for vstoee.dll is not the same. It says this on non-working machines:
Certificate Status: Untrusted
Trust Center Decision: Block Content
The Microsoft Corporation certificate is in my list of trusted publishers and it expired on 7/22/2015. It's a code signing certificate, and vstoee.dll was timestamped when signed with it, so it should still be recognized as good (if you check it via the filesystem, this checks out). Further, this DLL is used when loading my add-in (#2 under loading process). So if the add-in loads at all, this later usage should not matter.
So here's my question. Why is vstoee.dll trusted when loading an add-in, but not trusted on some machines when adding controls to a document actions pane?
It turns out the Microsoft Corporation certificate was not actually in the trusted publishers list. There were several others with the same name, but the expiration dates were different. Adding it to that list solved the problem.
Unfortunately this doesn't explain why the add-in was able to load, since it uses the same file.