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 w

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:

https://technet.microsoft.com/en-us/sysinternals/handle.aspx?f=255&MSPPError=-2147217396

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 0 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 broke
• "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.

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

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

a. running as System service, so the scope for listening named pipe service is global.

b. listening on the root address of “net.pipe://localhost/” (e.g. without any sub-paths/segments).

c. Using a StrongWildcard host name comparison mode.

d. Items a through c mean that Garmin’s application is essentially a catch-all for any net-pipe connection that doesn’t match something more specific.

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

Answer 3

One possible answer to your question "How can another application, simply by running, break our own application...":

1. The other application also uses the WCF NetNamedPipeBinding.
2. Both applications create service endpoints using base + relative URLs.
3. The applications' choice of base address, and HostNameComparisonMode is such that there is a name collision between the applications on one of the URL variants used by the client-side WCF stack to locate the metadata for the service.

I have no idea whether the Garmin service actually does use WCF NetNamedPipeBinding, but this is one possibility you should investigate. The problem can be avoided by always using absolute URLs for NetNamedPipe endpoints.

---

OK, so following the updates to the question, we now know that the Garmin service is using WCF NetNamedPipeBinding, and we know that your application registers its service using an absolute address, so the above explanation is not the complete story.

Here is another hypothesis:

1. Suppose the Garmin service runs in a process which has the security privilege SeCreateGlobalPrivilege (which a Windows service will have unless specially coded to disable the privilege).
2. Suppose it also registers its WCF Named Pipe endpoint with a base address of net.pipe://localhost and relative endpoint addresses.
3. Now its service metadata will be published using a shared memory mapping object with a name in the Global namespace.
4. Your service application is not a Windows service. My hypothesis is that its process does not have the security privilege SeCreateGlobalPrivilege. If this is the case, its service metadata will be published using a shared memory mapping object in its Local session namespace only.
5. Now your client process tries to initiate a connection when the Garmin service is running... the WCF client-side channel stack NetNamedPipeBinding element tries to locate the service metadata for your service based on your service URL net.pipe://localhost/MyWCFConnection. As explained in the link above, it will execute the search using various variants of the service URL in turn to derive a name for the shared memory object containing the metadata. It looks in the Global namespace first, for the full list of variants in turn, before looking into the Local namespace.
6. In this case, the first attempt will be for the name derived from "net.pipe://+/MyWCFConnection", and presumably it fails to find an object with this name in the Global namespace.
7. However, the second attempt will be based on the variant "net.pipe://+/", and this will match the name of the Garmin service's shared memory mapping published in the Global namespace. Because of the search order, it will never get to your service's metadata published in the Local session namespace.
8. Your client attempts to connect to the Garmin service's pipe. Let's assume the Garmin service has some security implemented which results in your client being rebuffed with an Access Denied (e.g. it may set an ACL on its pipe). The result might well surface as an EndpointNotFoundException. [LATER EDIT: Actually, most likely what is happening is that your client is actually connecting to the Garmin service, initiating the framing protocol's preamble handshake, and receiving back a framing protocol fault (http://schemas.microsoft.com/ws/2006/05/framing/faults/EndpointNotFound) because the URL requested in the Via record won't match what the Garmin service is expecting. The binding is then dropping the connection and surfacing this fault to your client code as an EndpointNotFoundException.]

What can you do about it? I would suggest:

• If the above hypothesis or something similar can be confirmed, and Garmin are using base+relative addressing with a base of just net.pipe://localhost, best would be to get them to own the problem: they could fix such a problem very easily by changing their base address to something more likely to be unique.
• You could perhaps work around it by finding some way for your service application to run with the security privilege SeCreateGlobalPrivilege: this isn't easy without making it a Windows service or running As Administrator, but maybe not impossible. Then your metadata would also be published in the Global namespace and the client's search would find it before Garmin's.
• [Later edit] Maybe there is a workaround involving setting the HostNameComparisonMode property of the binding to Exact, and using a synonym for localhost as the host part of the service URL (e.g. net.pipe://127.0.0.1/MyWCFConnection). This may steer the search around the Garmin variants so that your client has a chance to consider names in the Local session namespace. I don't know that it will work, but worth a try, I would have thought.
• And a very long shot: Does your company have a product support relationship with Microsoft? Arguably this is a serious design flaw in WCF: if you make a fuss about it you might possibly get Microsoft to issue a QFE patch for it e.g. to provide a binding property to tell the client-side stack to only try the Local namespace.