How do I debug this WCF web service? ("ServiceChannel is in the Faulted state")

Question

I have a weird error in a web service that causes the web service to become unavailable. It will return a error

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

When I refresh the Application Pool, the error goes away. I already added some debugging logging (using Log4net) but it doesn't show any helpful information.

There's nothing in the event log either.

How do I successfully debug this web service (which has worked for over 2 years and all of a sudden starts returning these errors)?

This is in C# / .NET 3.5.

Update: the webservice simply pulls data from a sql server (Customer data), wraps it in a dataset and sends it back to the client.

*Update 2: * I think I found the error: A client was not closing a connection. Is that plausible?

Jao this is a duplicated question of this one: http://stackoverflow.com/questions/530731/how-to-make-sure-you-dont-get-wcf-faulted-state-exception — Davide Piras, Sep 04 '11 at 12:15
I'm not working with the using statement, but the other answer might be helpful to me — jao, Sep 04 '11 at 12:26

score 4 · Accepted Answer · edited Nov 27 '19 at 13:24

You can add service logging using the System.ServiceModel.MessageLogging functionality provided by the framework. It will log all internal WCF exceptions, which typically occurs on a higher level than the service contract, thus you might never see it with standard debugging.

After the error has been logged, the produced .svclog can be inspected and analyzed manually using the Service Trace Viewer Tool

This functionality has helped me solve WCF problems where the root cause was impossible to determine based on the exception info available to the client or server. For example, I had a credential issue that merely produced an exception message along the lines of 'The connection was closed by the remote host' on the client, and no exception at all on the server. Going through the logs on the server pointed out the exact issue in less than 3 minutes.

Add the following to your app.config / web.config (modify to fit your need). This is enabled through configuration only, i.e. no programming required to set it up.

<configuration>  
 <system.diagnostics>  
  <sources>  
    <source name="System.ServiceModel"  
            switchValue="Information, ActivityTracing"  
            propagateActivity="true" >  
      <listeners>  
        <add name="xml"/>  
      </listeners>  
    </source>  
    <source name="System.ServiceModel.MessageLogging">  
      <listeners>  
        <add name="xml"/>  
      </listeners>  
    </source>  
    <source name="myUserTraceSource"  
            switchValue="Information, ActivityTracing">  
      <listeners>  
        <add name="xml"/>  
      </listeners>  
    </source>  
  </sources>  
  <sharedListeners>  
    <add name="xml"  
         type="System.Diagnostics.XmlWriterTraceListener"  
               initializeData="C:\logs\Traces.svclog" />  
  </sharedListeners>  
 </system.diagnostics>  

 <system.serviceModel>  
  <diagnostics wmiProviderEnabled="true">  
      <messageLogging   
           logEntireMessage="true"   
           logMalformedMessages="true"  
           logMessagesAtServiceLevel="true"   
           logMessagesAtTransportLevel="true"  
           maxMessagesToLog="3000"   
       />  
  </diagnostics>  
 </system.serviceModel>  
</configuration>

More information found here

score 1 · Answer 2 · answered Sep 04 '11 at 12:21

1

It could be a network connectivity issue. Have a look here

Could it be that your service is taking too long to respond? The fact that it has been working for 2 years may mean that you have too much data and you service is not longer able to query them fast enough.

If you can run it some local machine, it might help if you install a tcp/ip monitoring tool and see the exact request (and response if you get one).

If it is a SOAP webservice try running it through SoapUI.

Just some thoughts.

answered Sep 04 '11 at 12:21

Dimitris Maniatis

146
3

We recently upgraded from 1Mbps to 20Mbps. Might that cause issues? – jao Sep 04 '11 at 12:27
Not likely. Higher bandwidth does not affect the time the service takes to respond. You should keep in mind that the processing on the webservice side is probably taking too long to respond. Can you post more info on your webservice? – Dimitris Maniatis Sep 04 '11 at 12:38
the webservice simply pulls data from a sql server (Customer data), wraps it in a dataset and sends it back to the client. – jao Sep 04 '11 at 12:57
I think I found the error: A client was not closing a connection. Is that plausible? – jao Sep 04 '11 at 16:53
@jao, I suggest that you post this last comment as an edit to your question, so that it is more visible. – stakx - no longer contributing Sep 04 '11 at 18:08
@jao A channel has a state. If it fails (e.g. because of a connectivity issue) then it's state will be set to Faulted. If that channel is then used in an attempt to send messages, the exception that you are experiencing will occur. But this is not - to the best of my knowledge, an error that is 'returned'. This error originates on the client side, if the server was the part that closed the connection, and vice versa. So if your server e.g. closed the connection because of a recieve timeout, and the client afterwards tried to re-use that closed channel, the client would crash with your error – havardhu Sep 04 '11 at 18:08

score 0 · Answer 3 · edited Apr 11 '16 at 14:36

If you can debug on the server - or attach a remote debugger - try to disable "just my code" in Tools -> Options -> Debugging and break on all exceptions (CTRL-D, E). You should be able to catch all the internal exceptions that WCF throws.

But your comment about a client not closing connections sounds true. There is a bug in the IDisposable() implementation in ClientBase (see http://ardalis.com/idisposable-and-wcf).

How do I debug this WCF web service? ("ServiceChannel is in the Faulted state")

3 Answers3