WCF: Generic Errors, Tracing And You

6 September 2012

Working on some RESTful WCF services, I've on occasion noticed the totally unhelpful and blank "the connection was reset" errors when calling some of my method calls. At the time, I was testing returning very large data sets so I had a suspicion I was probably hitting a limit in WCF somewhere; but hitting the service through the browser wasn't being particularly helpful.

I'd already included the <serviceDebug includeExceptionDetailInFaults="true" /> behaviour, which didn't seem to be helping - so I went for the next tool in the diagnosis toolbelt, WCF tracing.

It's pretty easy to enable this - just add the following to your web config:

<system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Warning, ActivityTracing"
          propagateActivity="true">
        <listeners>
          <add type="System.Diagnostics.DefaultTraceListener" name="Default">
            <filter type="" />
          </add>
          <add name="ServiceModelTraceListener">
            <filter type="" />
          </add>
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add initializeData="D:\logs\wcf\tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
          name="ServiceModelTraceListener" traceOutputOptions="Timestamp">
        <filter type="" />
      </add>
    </sharedListeners>
  </system.diagnostics>

Note that you should probably change the location of where you want the tracelog to be written (the initializeData property above) to be something that's relevant to your machine.

(you could probably even use the svcconfigeditor.exe utility in the Microsoft SDKs folder which is even easier, but mine took issue with the helpEnabled=true property on my endpoint behaviour. I may have had an old version of the utility so your mileage may vary.)

Now armed with the tracelog and Trace Log Viewer utility, I could finally get a proper error:

WCF Exception

As we can see, I just need to alter the configuration for the maximum number of items in the object graph, which is much more helpful than "the connection was reset". Moral of the story is that if you want to actually know what's going on in WCF, turn that tracing on!

The best part is, after the fact, I found someone else who clearly encountered the exact same thing I did. If only I'd come across that post first! :)

Tags: MaxItemsInObjectGraph, tracing, WCF

Add a Comment

No Comments