WCF Services can be a pain to debug.  By default they do not propagate error and exception information to the caller for security reasons.

There are several different approaches you can take to debug your WCF service, but let’s take a look at one of the most powerful ones.

You can enable a trace log for your service very easily by adding the following to your app/web config file:

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Information, ActivityTracing"
                propagateActivity="true">
            <listeners>
                <add name="traceListener"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="C:\Logs\Traces.svclog"  />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

You can use a relative path or leave the path out completely in which case the log will be written to the current directory.  This will depend on how your hosting your service.  For this reason it is often easier to just specify a full path.

Now when you run your application you will see a file created.  If you double click on the file, or otherwise launch SvcTraceViewer.exe you will get lots of good information about your service.

If you are getting an exception, the trace should have some entries highlighted in red.  Examining those entries more closely will provide details on the underlying exception.  In my example below we see that I have a serialization error (the exception items are selected so they are not showing as red in the screenshot):

The WCF tracing is built on top of System.Diagnostics.  WCF is not the only system that provides trace information.  Trace Logging is highly configurable.  You can set different log levels for different types of information.  You can set different targets.  You can consume traces in different ways as well.

This MSDN article provides a good starting point for customizing your trace logging.

The most common setting you will likely use though is the Trace Level.  This will let you make the log extremely verbose if trying to track down a difficult bug or performance issue, or you can set the log to a higher level so the log doesn’t grow so large but you still get critical errors.

Some common settings would be as follows:

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Off"
                propagateActivity="true">
            <listeners>
                <add name="traceListener"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="C:\Logs\Traces.svclog"  />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Information, ActivityTracing"
                propagateActivity="true">
            <listeners>
                <add name="traceListener"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="C:\Logs\Traces.svclog"  />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

This MSDN article covers recommended settings for production systems:

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Warning"
                propagateActivity="true">
            <listeners>
                <add name="traceListener"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="C:\Logs\Traces.svclog"  />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

You can also use the Configuration Editor Tool to edit your config file, enable tracing and setting the trace level.

Now off to fix the error.