How to make sure you don't get WCF Faulted state exception?

Question

I am getting this exception:

The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

The WCF service uses the default wsHttpBinding. I am using WCF in the following way wherever I am using it:

using (var proxy = new CAGDashboardServiceClient())
{
    proxy.Open();
    var result = proxy.GetSiteForRegion(ddlRegions.SelectedValue);
    ddlSites.DataSource = result;
    ddlSites.DataBind();
    proxy.Close();
}

The error line shown in the message seems to be after last proxy.close. Not sure what is going on. I am launching the service from within visual studio 08.

Here is the trace information:

The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

Server stack trace: 
  at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)

Exception rethrown at [0]: 
  at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
  at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
  at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
  at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
  at System.ServiceModel.ClientBase`1.Close()
  at System.ServiceModel.ClientBase`1.System.IDisposable.Dispose()
  at CAGDashboard.UserControls.ucVolunteerCRUDGrid.ddlRegions_SelectedIndexChanged(Object sender, EventArgs e) in C:\Documents and Settings\rballalx\My Documents\Visual Studio 2008\Projects\DashboardCAG\CAGDashboard\UserControls\ucVolunteerCRUDGrid.ascx.cs:line 81
  at System.Web.UI.WebControls.ListControl.OnSelectedIndexChanged(EventArgs e)
  at System.Web.UI.WebControls.DropDownList.RaisePostDataChangedEvent()
  at System.Web.UI.WebControls.DropDownList.System.Web.UI.IPostBackDataHandler.RaisePostDataChangedEvent()
  at System.Web.UI.Page.RaiseChangedEvents()
  at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

score 67 · Accepted Answer · edited Jan 13 '12 at 15:33

67

You should avoid putting client proxies in using blocks.

edited Jan 13 '12 at 15:33

svick

236,525
50
385
514

answered Feb 10 '09 at 05:23

Brian

117,631
17
236
300

1

thanks!! i tried without using statement too...without success :( – Perpetualcoder Feb 10 '09 at 07:27
7

I wrote some wrapper code that helps with the WCF + using block issue http://nimtug.org/blogs/damien-mcgivern/archive/2009/05/26/wcf-communicationobjectfaultedexception-quot-cannot-be-used-for-communication-because-it-is-in-the-faulted-state-quot-messagesecurityexception-quot-an-error-occurred-when-verifying-security-for-the-message-quot.aspx – Damien McGivern Aug 09 '09 at 18:45
6

But it's IDisposable. "using" is the best practice! – Amy B Jan 30 '12 at 17:01
The best practice is to call the `Close` method if the class provides one. – AMissico Oct 31 '12 at 22:21
David. Using is _not_ best practice for WCF host and proxies. Its best practice to not use "using". Might be counter-intuitive, but there you go. – Casper Leon Nielsen Jan 24 '13 at 13:34
1

Using is not desired because it (1) can hide errors and (2) some exceptions (e.g. communication exceptions) require you to call "Abort" to release resources. If your channel closes properly you don't have an issue here, but if it does not, you can leave resources open until the garbage collector gets around to cleaning them up. This is why try-catch is better. You can specifically call out the exceptions you need to address, and you don't mask errors as you would with a try-finally (using statement). – Zack Jannsen Nov 05 '13 at 12:47
9

This is very poor design by the WCF team IMO. – Doctor Jones Apr 23 '15 at 15:21

score 20 · Answer 2 · edited May 23 '17 at 10:31

Update:

This linked answer describes a cleaner, simpler way of doing the same thing with C# syntax.

Original post

This is Microsoft's recommended way to handle WCF client calls:

For more detail see: Expected Exceptions

try
{
    ...
    double result = client.Add(value1, value2);
    ...
    client.Close();
}
catch (TimeoutException exception)
{
    Console.WriteLine("Got {0}", exception.GetType());
    client.Abort();
}
catch (CommunicationException exception)
{
    Console.WriteLine("Got {0}", exception.GetType());
    client.Abort();
}

Additional information

So many people seem to be asking this question on WCF that Microsoft even created a dedicated sample to demonstrate how to handle exceptions:

c:\WF_WCF_Samples\WCF\Basic\Client\ExpectedExceptions\CS\client

Download the sample: C# or VB

Considering that there are so many issues involving the using statement, (heated?) Internal discussions and threads on this issue, I'm not going to waste my time trying to become a code cowboy and find a cleaner way. I'll just suck it up, and implement WCF clients this verbose (yet trusted) way for my server applications.

The following question on SO lists exceptions and best practices on how to handle them: http://stackoverflow.com/questions/6130331/how-to-handle-wcf-exceptions-consolidated-list-with-code — makerofthings7, Jun 15 '11 at 21:18

score 7 · Answer 3 · answered Apr 24 '14 at 02:38

7

If the transfer mode is Buffered then make sure that the values of MaxReceivedMessageSize and MaxBufferSize is same. I just resolved the faulted state issue this way after grappling with it for hours and thought i'll post it here if it helps someone.

answered Apr 24 '14 at 02:38

Nishant

195
1
6

This issue is tricky! You solved it for me and spared me few hours. Thanks – Shahar G. Feb 08 '16 at 12:43

score 1 · Answer 4 · answered Apr 21 '15 at 15:53

1

This error can also be caused by having zero methods tagged with the OperationContract attribute. This was my problem when building a new service and testing it a long the way.

answered Apr 21 '15 at 15:53

Ryan Rodemoyer

5,548
12
44
54

score 0 · Answer 5 · answered Apr 13 '16 at 19:07

0

Similar to Ryan Rodemoyer's answer, I found that when the UriTemplate on the Contract is not valid you can get this error. In my case, I was using the same parameter twice. For example:

/Root/{Name}/{Name}

answered Apr 13 '16 at 19:07

Gil Milow

320
1
5
10

How to make sure you don't get WCF Faulted state exception?

5 Answers5

Linked