问题
I have two WCF services hosted in a single Windows Service on a Windows Server 2003 machine. If the Windows service needs to access either of the WCF services (like when a timed event occurs), it uses one of the five named pipe endpoints exposed (different service contracts). The service also exposes HTTP MetadataExchange endpoints for each of the two services, and net.tcp endpoints for consumers external to the server.
Usually things work great, but every once in a while I get an error message that looks something like this:
System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://localhost/IPDailyProcessing that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.IO.PipeException: The pipe endpoint 'net.pipe://localhost/IPDailyProcessing' could not be found on your local machine. --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName(Uri uri) at System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey(EndpointAddress address, Uri via) at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout) at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call(ServiceChannel channel, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade) at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
It doesn't happen reliably, which is maddening because I can't repeat it when I want to. In my windows service I also have some timed events and some file listeners, but these are fairly infrequent events. Does anyone have any ideas why I might be encountering an issue? Any help would be greatly appreciated.
回答1:
Check if "Net.Pipe Listener Adapter" service is running in Services management console. This is used by WAS to receive any request on named pipe.
回答2:
I got a similar error in past, and, if I remember right, it was something wrong with the data passed to/from service. In my case problem was in data size (I used the WSHttpBinding, so there is a http default limit). The way I found the problem was to add logging in related methods, find the problematic data, and try to reproduce the problem in some debug-friendly environment and make it happen (crash) constantly with data you found.
In my case the exception message was not related to the problem, which sometime happens in WCF.
回答3:
I'm not sure whether this is germane to your discussion, because I've never used the .net named pipes, but I do recall that the .net tcp socket endpoints had a known bug that resulted in "endpoints occasionally being terminated for no apparent reason", and unfortunately the official MS response was a "workaround" which involved checking that the socket was still up before sending a message through it, and re-opening it in the case that it wasn't. I'd like to think that the named pipe endpoints aren't as unreliable as the "reliable TCP endpoints", but you might want to look into the "known periodic TCP socket failure" to see whether it also extends to named pipes.
Sorry that this isn't really an answer, and I hate to suggest that you might have to add the inefficiency of checking to ensure that it's up before sending a message, etcetera.
来源：https://stackoverflow.com/questions/1247185/there-was-no-endpoint-listening-at-net-pipe-localhost