0 comments
.NET 
Introduction
When using a named pipe binding for WCF services one may come across errors that denote the very promising “The pipe has ended” with seemlingy random errorcode. These errors can be quite hard to debug as the error message itself is not very descriptive.
I’ve come across this error quite a few times lately when working on an application that uses named pipes as the transport layer for WCF services and found some useful pointers that might help others to fix similar issues with their services. In this article
I’m going to show how you can find out about leaky pipes in your own WCF applications (Yep, without calling a plumber if that is what you were thinking).
The scenario
A leaky pipe can usually be found in cases where there’s an error on the serverside of the setup. Clientside errors are easily catched by the runtime and routed through the application code towards a log or the debugger.
Problems reading from the pipe or the pipe being closed unexpectedly are almost always caused by problems in the services itself or in one of the behaviors configured on the server.
What is causing the leaky pipe?
One of the reasons a named pipe fails is caused when serialization of a datacontract type fails, the pipe is going to leak. In other words, the runtime closes the pipe without actually telling the client that something went wrong serializing the request. This raises an exception on the client with the an exception message like the following:
“There was an error reading from the pipe: Unrecognized error 109 (0x6d).”
Important: There might be a different error message depending on the location of the failure and other conditions. At this moment I’m not aware of all the specific errorcodes regarding named pipe failures.
Looking for more clues
Knowing that a pipe failed because something went wrong on the server presumably when serializing a response to the client is sadly not helping much when you’re trying to fix the problem. There is however one way to find out more about this particular type of problem. The service will log the serialization problem in the tracelog when you have it turned on for the service. This really helps to tackle the problem, because the error message being logged tells quite a lot about the problem.
All activities that caused a failure in the service are highlighted in the left panel with a red color. When you select a red activity in the list the details get displayed in the listview on the right. Now it’s pretty obvious something failed miserably.
To get more details about the actual exception you can select the item with the text “Throwing exception” this displays the exception activity in the bottom half of the screen. There it tells me I’ve got a problem with a datacontract type not being serialized correctly. Looks like I forgot to fill the StringMember property of my CompositeType object.
Beside the error that caused the leaky pipe you can also see the cause of the leak itself. The WCF immediately aborts the channel and request context after the exception is thrown.
Conclusion
Serialization exceptions inside a WCF service can cause all kinds of errors on the client that can be very hard to debug without knowing where to start looking for the actual problem. The tricks presented in this article not only work for named pipes, but can also help ease the pain when debugging serialization failures in combination with other bindings in WCF.