Turn on WCF Tracing for WCF Troubleshooting
Yesterday I posted an entry on dealing with larger result sets that cause Fidder to create a ReadResponse() failed error. In that post I mentioned I turned on WCF Tracing to help debug the problem. This is a setting that when turned on causes the WCF stack to generate a couple of log files that can be used to see the details of what is going on. You can read more about the details of WCF Tracing on the MSDN site.
To turn on WCF tracing you need to add some sections to the web.config or app.config of your application:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Error,ActivityTracing"
propagateActivity="true">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener"
name="Default">
<filter type="" />
</add>
<add name="ServiceModelTraceListener">
<filter type="" />
</add>
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging"
switchValue="Warning, ActivityTracing">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelMessageLoggingListener">
<filter type="" />
</add>
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="tracelog.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelTraceListener" traceOutputOptions="Timestamp">
<filter type="" />
</add>
<add initializeData="messages.svclog"
type="System.Diagnostics.XmlWriterTraceListener,
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">
<filter type="" />
</add>
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
<system.serviceModel>
<diagnostics>
<messageLogging logMalformedMessages="true"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="true" />
</diagnostics>
</system.serviceModel>
</configuration>
If you already have a serviceModel section you can just add the existing diagnostics section. Once you have these configuration sections in place WCF will start tracing all calls.
The tracing infrastructure creates two trace files. These files can be viewed using the Microsoft Service Trace Viewer.
The Service Trace Viewer breaks the trace report into a viewable representation of the data and much like fiddler gives you the ability to view the data in the raw XML format. If you notice at the bottom of the view (click the image to enlarge it to full screen) you will see the following error message.
There was an error while trying to serialize parameter urn:
[ProjectNameSpace].UI.WebSite.WebServices.ServiceContracts.[ServiceName]:FindOrdersResult.
The InnerException message was 'Maximum number of items that can be serialized or deserialized
in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota. '.
Please see InnerException for more details.
Service namespace obfuscation aside this tells me what the real issue with my service call is. In this case the result set is larger than the default allowed. It also tells me I what I need to do, increase the MaxItemsInObjectGraph property. This allowed me to concretely make decisions to solve my problem.
So just like you can inject detail error error logging in the ASP.NET pipeline, like ELMAH, you have a built in tracing and logging solution that comes with WCF.