3rd party app breaks our WCF application

Question

Our application uses WCF over named pipes to communicate between two processes (note: neither process is a Windows Service.) Our application has been running in the field without incident for a couple of years now.

We are now receiving reports that the presence of a third party application (specifically, Garmin Express) is breaking ours. I've installed Garmin Express in house and confirmed the behavior. Specifically the "Garmin Core Update Service", when running, causes our application to fail.

When the Garmin service is running, the "service" side of our application starts and has no problems creating the WCF endpoint. But when the client starts and attempts to connect to the service, it fails with EndpointNotFoundException, as if the service is not even running.

At this point, I can literally stop the Garmin service from the Services control panel, then re-run the client successfully without even restarting our own service. If I start the Garmin service again, further attempts to start the client fail. So this at least proves that our WCF service is up and running the whole time, and the Garmin software is somehow blocking our client's ability to connect to it.

We are using our own name for the endpoint address (e.g. something like "net.pipe://localhost/MyPrivateApplication"). I've tried changing this address to various other names, but that has no effect on the issue.

How can another application, simply by running, break our own application's ability to use WCF?

Update: by request, here is a code snippet from the service side. I've simplified it from our original code in an attempt to isolate the issue. So far, not a single change I've made has had any effect on the issue.

MyService service = new MyService();
ServiceHost host = new ServiceHost(service);
string hostAddress = new Uri("net.pipe://localhost/MyWCFConnection");
host.AddServiceEndpoint(typeof(IMyService), new NetNamedPipeBinding(), hostAddress);
host.Open();

Answer 1

I have found a method to display which applications use net.pipe (though not necessarily which are using it incorrectly).

First download the Handle application from Sysinternals (Microsoft). As a side-note: Process Explorer also lets you search for handles.

Then open a command prompt as administrator, and run Handle.exe net.pipe (minus quotes). This will list all applications using net.pipe that are currently running. From there, you can kill or disable one at a time, until your culprit is discovered. I almost never have more than 4-5 processes using it. If you fail to run command prompt as administrator, it may give zero or only irrelevant results.

Below are all the applications I've found that interfere with net.pipe:

• "HP Support Solutions Framework Service" - only some versions affected

• "Garmin Core Update Service" - fixed in newer versions but out of box is broken

• "WBE Service" - used by a couple dell laptops in conjunction with a wireless docking station

• "Intel(R) Security Assist" Service - I saw on a couple of Win10 laptops early 2016.

• "Baraccuda WSA Service" - Web Security Agent. Probably would upset a customer if you disabled this.

• "DropboxOEM.exe" - A variant of Dropbox for inclusion in store-bought PC's. Only noticed on Win10 so far. This one is unique, because it is the first I've found that is not a windows service, to the best I can tell.

• "MTC Service" - Installed on some Getac brand PC's. Unsure what it does.

• "pcdrcui.exe" - Not a service, but runs as admin. Component of Dell's SupportAssist.

• "Mitchell1/Shopkey SE Connection" or "ShopHubService" or "Mitchel1/Shopkey Data Backup Service" - Data synchronization service. Unsure what all it does.

• Procore Drive (Procore DriveService.exe). Uses net.pipe://+/:

   Procore DriveService.exe pid: 4204   type: Section        43C: \BaseNamedObjects\net.pipe:EbmV0LnBpcGU6Ly8rLw==
  

• Keynetix.Cloud.Launcher.Service.exe. Uses net.pipe://+/:

   Keynetix.Cloud.Launcher.Service.exe pid: 5524   type: Section        4B8: \BaseNamedObjects\net.pipe:EbmV0LnBpcGU6Ly8rLw==
  

• RevitAccelerator.exe (part of Autodesk Revit). This only gets run elevated immediately after installing Revit. Also, this issue is fixed in Autodesk Revit 2020.

• Wonderware InTouch IData Service (SE.Scada.Asb.InTouchDataService.exe) that comes with the Wonderware InTouch HMI system

• WKSSTrayNotification.exe (not a service, but a tray application part of ADDISON software)

Software maker DATEV has another list in German here (archived).

I support an application that requires net.pipe, so I'll update this list as I find more services that do this.

---

Stripping up to and including the leading net.pipe:E from the name will also help in making out the culprit, because the remainder of the name is Base64-encoded (also here). So taking \BaseNamedObjects\net.pipe:EbmV0LnBpcGU6Ly8rLw== from above as an example with PowerShell we can decode the name to:

$ [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("bmV0LnBpcGU6Ly8rLw=="))
net.pipe://+/

Answer 2

We at Microsoft have zeroed down the issue to the way Garmin Core Update Service creates named pipes. Named pipes can be created in different Scopes – Global and Local. Global scope is essentially machine wide and Local is specific to the user.

Garmin’s application is

1. running as System service, so the scope for listening named pipe service is global.
2. listening on the root address of “net.pipe://localhost/” (e.g. without any sub-paths/segments).
3. Using a StrongWildcard host name comparison mode.
4. Items 1 through 3 mean that Garmin’s application is essentially a catch-all for any net-pipe connection that doesn’t match something more specific.
5. It also means that Garmin is completely blocking all listeners that are using a local scope

The ideal fix for this would be a change in Garmin application such that it registers its net.pipe listener with a more specific URL.