CODEWITHSUNDEEP
c#.netwcfweb-services
jao
jao

Reputation: 18620

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

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?

Upvotes: 4

Views: 5863

Answers (3)

havardhu
havardhu

Reputation: 3616

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

Upvotes: 4

Huusom
Huusom

Reputation: 5912

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).

Upvotes: 0

Dimitris Maniatis
Dimitris Maniatis

Reputation: 146

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.

Upvotes: 1

Related Questions