Comments by John Whitmire (Top 20 by date)

See my response to Maciej Los.

@Ralf Meier and @Maciej Los: I was able to do a check where the only difference is the O/S. It provided some answers and opened other questions.
When I opened the VS2010 project in VS2015 under Windows 7, the same difference appeared in the form Designer. (Simply opening either the project or the form designer--I don't know which--changed the buttons' locations in the *designer.cs file.) I did the same "correction," moving the buttons back to their correct location, and saved the form. The files that were saved (*.cs and *.resx) were unchanged from how they had been before opening the project! But now, the form looked correct in VS2015.
I built the app with VS2015 and ran it on both O/S versions. It looked fine on Win7 where it was built, but moved the buttons in Win10. I tried the reverse, building in Win10 and executing in Win7, and the same thing happens.
Note again that the difference mentioned in the OP is the only difference I can find among the now three copies of the project. The app has another form with several User Controls on it. I have seen nothing else affected by swapping between the O/S versions or VS versions. The control layout and properties are the same. Margins, padding, etc. are all defaulted. Anchor is bottom-right for these buttons and for most of the others on the other form and its User Controls. The csproj file specifies .NET 4 Client in both scenarios.
So, it seems that the O/S versions have a slight rendering difference that manifests in this scenario. The new question is why the difference shows in the VS2015 Designer under Win7 until I save the form's files in VS2015. At that point, something hidden changes and the form designer then renders as expected, yet without having made any changes to the generated source code.

Ping applies way ahead of this. We know the remote machine is present and alive. We don't know if the service we connected to on it is still alive. But all that is rather independent of this odd message delay I'm seeing in WCF.
I have found that it is related to object locks being used in operations on a different WCF channel. These things shouldn't be coupled at all (the other channel connects to a completely different service), but maybe they are... somewhere.

Never having needed pinning before, I had to refresh my understanding of what it is, but after doing so, I still don't see how that would apply.

I neglected to say that the status update also functions as a heartbeat. (I keep forgetting that part.) In addition to the remote service's running status, the local service also needs to detect that it died.

The 2-second message is a status update. The 10 and 30 second messages are heartbeat messages between a server and HTTP client.

Too bad the documentation page I found (not in the vstudio path) didn't have that statement. It makes the answer very clear. Thanks for pointing it out.

Alas, there is no easy way. However, the IApplicationDestinations::RemoveDestination module exists for this purpose, doesn't it? If only I could find the right wiring to use it....

WordApp.RecentFiles is the Application MRU, not the JumpList managed by Windows that holds my unwanted entries. The WindowsApiCodePack provides mechanisms for managing a custom category in the JumpList, but not the Windows-managed Recent category. There is a method in shell32 for removing entries, but I don't know enough to figure out how to use it since it involves internal structures and interfaces that I can't yet comprehend.

Targeting Word 2010. The human-readable registry entries are the MRU lists that show on the application window. Our unwanted entries do not appear there, so nothing is required for that.

The registry entries that appear to be the JumpList are in binary and I haven't found any reference on reading/modifying those entries. There is also the (virtual?) folder ...\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations with files named [guidAppId].automaticDestinations-ms that contain binary JumpList data (credit goes to nirSoft for that info), but I haven't found any descriptions of their data nor any means of obtaining the app ID guid for Word that would be required to know which file to access.

As stated in the question, our temporary files are added to the JumpList when the add-in calls Range.InsertFile(). Also of interest is the addition of the document template file (dotx) in the JumpList when Documents.Add() is called with a custom template. We don't want that one either, but I figured the solution to one is the solution to the other. There are flags on some system Open calls to suppress the addition of the file to the JumpList. I would hope for something similar in these Word methods. Or the inverse of SHAddToRecentDocs(...).

Been there already. Clearing the list is not acceptable. I need the programmatic equivalent to "right-click and select 'Remove from this list'."

I must be missing something in what you said. This sounds like exactly what I was doing. The config file contains the channel definitions (2 of them, one TCP, one IPC). The two calls to Marshal(object, uri) aren't different from what you show, except that my URIs are not the same as the channel names. Is there something special about that?

Reason for my vote of 3
Helpful, but not yet an answer.

Following your lead, for which I am grateful, I have found several similar forum threads, most of which end up where I currently find myself: at a dead end. Someone asks the question about catching these things, a responder says that they use the UnhandledException event, and either the submittor or a third person responds that it won't work for them. And the trail ends there.

The link you provided does provide a few clues, but hasn't (yet) led me to any answers in two days of heavy searching. I can't get the UnhandledException event to fire for anything that happens after the OnStart method completes. In fact, I can't even get anything logged anywhere about the unhandled exception... except in the VS debugger.

The UnhandledException event is working for some people. I want to learn what obscure thing they are doing and I'm not that makes the difference.

OK, a little more experimenting revealed that I don't need the two URIs after all; I can make it work with just one. This is now just a curiosity question.