How to prevent WCF from closing communication channel after SerializationException? RRS feed

  • Question

  • Precondition: WCF communication based on NetNamedPipeBinding and NetDataContractSerializer

    Problem: If a SerializationException occurs comunication channel is set to Faulted is then closed.

    Question: How can I achieve to make WCF more tolerant against SerializationExceptions so the channel remains open for subsequent calls? I am talking here about SerializationExceptions which are occuring inside the WCF layer (not to be confused with Exceptions occuring in the code of your service logic). Are there any hooks to manipulate the serialization behaviour of WCF and which could be of use here? 
    Monday, July 21, 2014 9:18 AM

All replies

  • Hello,

    You should have a look at this MSDN article which explains the differents states of WCF proxies:

    This is how you should handle the differents states.

    Basically, here you should not worry about SerializationException. You should be sure that your code will handle the different states and you'll recreate a proxy when needed. Then in a second time you should investigate why you are having SerializationException to identify the root cause of this issue. But as a WCF proxy point of view this shouldn't be a concern.


    Monday, July 21, 2014 9:46 AM
  • Thank you for the quick answer! In my scenario one WCF proxy instance is shared by multiple consumers which are located in various components. The service contract is designed in a generic manner. It offers methods which allow a given service provider to propagate its service so that a interested consumer can find this service and use it. This is done by a handshake-like sequence of operations. Providers and consumers are using duplex communication (involving client callbacks). Now if one service call provokes a SerializationException in the WCF layer, all consumer-provider pairs are affected, because they are all using the same proxy instance. A failover mechanism would involve to repeat the handshakes of all affected comsumer-provider pairs. In this situation I would rather like to change the behaviour of the WCF layer in regard to SerializationExceptions if this is possible. So for me the question still remains if WCF is providing mechanisms to change this behaviour.
    Monday, July 21, 2014 12:16 PM
  • I understand better the context now thanks for sharing the details.

    Have you tried to implement a custom ErrorHandler on WCF to handle the SerializationException?

    Apparently, SerializationException is quite special according to this thread ( and is not catch by an ErrorHandler. 

    How often do you get this exception? Which serializer are you using?

    Monday, July 21, 2014 3:33 PM
  • Thanks again for your answer! We are using the NetDataContractSerializer. I can reproduce the exception with an UnitTest by making a test service return an object which is not prepared for serialization.  We aren't using the WCF ErrorHandling/Fault mechanism. Instead we are using an own implementation which works well for exceptions that occur in the service logic but not for exceptions which occur within the WCF layer itself (SerializationException, InvalidDataContractException). 
    So far my observations are corresponding with the article you mentioned in your answer above. I will try out to implement a WCF ErrorHandler but I don't really expect that this approach will solve my problem concerning the disconnection of the communication channel if an exception occurs within the WCF layer ... 

    Tuesday, July 22, 2014 9:48 AM
  • Hi,

    Yes, when occurs the exceptions, this would cause the service to be rendered unusable by any subsequent connections.

    The following may be a fix for recovering the service from the faulted state for us to handle the Faulted event of the communication channel, please try to check it:

     channelFactory = new ChannelFactory<IService>(endpoint);
     channelFactory.Faulted += OnChannelFaulted;
     var channel = channelFactory.CreateChannel();

    Then please try to define the OnChannelFaulted:

     void OnChannelFaulted(object sender, EventArgs e)

    Best Regards,
    Amy Peng

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, July 22, 2014 10:31 AM
  • Hi Amy,

    what I am looking for is a possibility to prevent the communication channel going into the "Faulted"-state after an internal exception occured.

    If this is not feasible, then I have to take the pain and think about how to deal with disconnected connections and failover, which probably is hard to accomplish in my scenario.

    But before I do that I'd like to eliminate the possibility that this behaviour can be changed in a way so the channel will not be  moved to the "Faulted"-state even though internal WCF exceptions have occured.



    Tuesday, July 22, 2014 11:25 AM
  • Hello,

    I implemented an IErrorHandler. It doesn't help me to avoid the closing of the channel. The sending of the non-serializable object caused an InvalidDataContractException. This exception is not recognized by ErrorHandler. The next usage of the channel is leading to a CommunicationException  "Pipe already closed" which is actually recognized by the ErrorHandler, but then it's already too late ... :-)


    Tuesday, July 22, 2014 3:04 PM