0

I am designing a WCF service and client with callback using named pipe, when the server process the request from the client, I got the error#109 and eventually the pipe connection got aborted. Below is the tracing file from the server side. In case the font is too small to see, I should simply explain it:

The three exception marked in red happened when the request made from the client to the server. The function is pretty simple, is passes one string variable to the server. This error is #109 (3 consecutive exceptions, if that number means anything) and it doesn't give more information. And in this activity the pipe connection eventually got aborted. Also what's weird is we can see the next activity after the "Receive bytes on connection...", the "Processing message", it actually went through, meaning the server side processing did get called with the passed parameter. This can be verified in the debugger because on the server side the operation did get the passing string. Also inside the operation function if I try 

Dim callback = OperationContext.Current.GetCallbackChannel(Of ISSLServiceCallback)()
If DirectCast(callback, ICommunicationObject).State = CommunicationState.Opened Then 
   DoSomething()
End If

It actually goes into the If sentence, which I guess means the channel is actually alive so far.

Thanks for any help!

Tracing details

tete
  • 4,859
  • 11
  • 50
  • 81

2 Answers2

1

This exception means that the server side WCF channel stack has encountered the operating system error ERROR_BROKEN_PIPE 109 (0x6D) The pipe has been ended. This suggests your client side may have already disconnected when the service comes to write its response or interact with the callback channel.

I do know that one cause of ERROR_BROKEN_PIPE in the NetnamedPipeBinding is a certain pattern of mismatch of security expectations between the client's and the server's respective binding configurations - I suggest you check security configuration for consistency both sides.

If you want more help please post your client and service code, endpoint configuration and the stack trace and other details of each exception you see in the log trace.

Chris Dickson
  • 11,964
  • 1
  • 39
  • 60
0

I know this is an old thread, but I just ran into exactly the same issue.

Turned out the client proxy was being closed like this:

client.Abort();
client.Close();

.. rather than something along the lines of:

try
{
    client.Close();
}
catch (Exception ex)
{
    client.Abort();
}

.. which got rid of all the erors in the WCF trace file.

Kelly Wheeler
  • 1