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