WCF NamedPipe CommunicationException - “The pipe has been ended. (109, 0x6d).”

Question

I am writing a Windows Service with accompanying \"status tool.\" The service hosts a WCF named pipe endpoint for inter-process communication. Through the named pipe, the

Answer 1

This exception means there is a serialization problem on the server side.

This issue can be resolved by looking into the trace file (svclog). To turn tracing on use the following configuration:

<system.diagnostics>
        <sources>
            <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="false">
                <listeners>
                    <add name="traceListener" />
                </listeners>
            </source>
            <source name="System.ServiceModel.MessageLogging">
                <listeners>
                    <add name="traceListener" />
                </listeners>
            </source>
        </sources>
        <sharedListeners>
            <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\Remos\Log\WcfTraceServer.svclog" />
        </sharedListeners>
    </system.diagnostics>

In my case I was serializing a value that was not in the enum.

Answer 2

Had the same issue There was an error reading from the pipe: Unrecognized error 109 (0x6d).

• One reason was inconsistent binding between client and server <netNamedPipeBinding> <security mode="None"></security>... (no communication)
• The other intermittent issue was time-out related.

Both had the same top error message.

Increasing the time out in the server and client binding stopped issue from reappearing.

Binding time out that was set too low:

sendTimeout="00:00:05" receiveTimeout="00:00:05"

Stack trace: at System.ServiceModel.Channels.StreamConnection.Read(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout) at System.ServiceModel.Channels.SessionConnectionReader.Receive(TimeSpan timeout) at System.ServiceModel.Channels.SynchronizedMessageSource.Receive(TimeSpan timeout) at System.ServiceModel.Channels.TransportDuplexSessionChannel.Receive(TimeSpan timeout) at System.ServiceModel.Channels.TransportDuplexSessionChannel.TryReceive(TimeSpan timeout, Message& message) at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, 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)

Answer 3

Sometimes this error caused by polymorphic feature of objects. for example following service's method will return list of persons:

[OperationContract]
 List<Person> GetEmployee();

if we have Supervisor class inherited from Person class, and the above method try to return Supervisor Object, the WCF serializer class can not interpret the response, so this error will be raised.
The solution for this problem is to use "known types" or "service known types". we have to specify implicit objects may interact using method or service. For my example, we can put ServiceKnownType attribute in method or service declaration as following code:

[OperationContract]
[ServiceKnownType(typeof(Supervisor))]
List<Person> GetEmployee();

Answer 4

I had a lot of properties with no set{ } in it. Adding this solved my problem.

Answer 5

Same problem but solved thanks to Wojciech's answer.

I had to do a bit more digging to find where to put the <security> tag so here is how the start of the system.serviceModel section looks now ...

<system.serviceModel>
   <bindings>
     <netNamedPipeBinding>
       <binding>
         <security mode="None"></security>
       </binding>
     </netNamedPipeBinding>
   </bindings>
   ....

Answer 6

The IP Address was, it turns out, a complete red herring.

The real reason for the exception was invalid Enum values being returned by the WCF service.

My enum was defined thusly:

[DataContract]
public enum MyEnumValues : Byte
{
    [EnumMember]
    Enum1 = 0x10,
    [EnumMember]
    Enum2 = 0x20,
    [EnumMember]
    Enum3 = 0x30,
    [EnumMember]
    Enum4 = 0x40,
} 

It looks fine on the surface.

But the raw status reported by the underlying service was a Byte value of "0," and there was no corresponding Enum value for which to cast it.

Once I ensured that the Enum values were all valid, the tool lit up like a Christmas tree.

When in doubt, assume your WCF data is invalid.