WCF Tracing

After deploying application a proper troubleshooting policy should be ready in order to perform maintenance activity of our project life cycle. Here we will see different tools available from Microsoft within visual studio in order to manage, configure, debug and troubleshoot WCF service after deployment. Note that if you are unfamiliar with WCF, please read my WCF Tutorial .

WCF Tracing can track all the events or only specified events in the program. Tracing is built upon the System.Diagnostics namespace of the .NET Framework. The Debug and Trace classes under this namespace are responsible for debugging and tracing purpose.

Tracing is turned off by default and needs to be enabled   to start using tracing. We can enable tracing by two ways. One is through code and another is from config file. Enabling tracing in configuration is the optimal method since we can easily turn it on and off as required. When debugging  is  no longer required we should turn tracing enable off.

Enabling Tracing

The following code snippet will enable tracing through configuration file:


<trace autoflush="true" />


<source name="System.ServiceModel"



<add name="TraceListeners"


initializeData= "c:\Log\trace.svclog"/>





In this example, the name and type of the trace listener is specified. The Listener is named TraceListeners and the standard .NET Framework trace listener (the native format for the tool - System.Diagnostics.XmlWriterTraceListener) is added as the type. The initializeData attribute is used to set the name of the log file for that Listener. Here the fully qualified file name is used as “c:\Log\trace.svclog”.

Tracing Levels:

Tracing Levels:
The tracing level is controlled by the switchValue setting. The available tracing levels are described below:

SL. No


Tracked Events

Content of the Tracked Events



No traces are emitted.



Out of memory exception, Stack overflow exception, Application start
errors, System hangs, Poison messages



All exception are logged

Unexpected processing has happened. The application was not able to
perform a task as expected. However, the application is still up and running.



Timeout exceeded, Credential rejected, throttling exceeded, receiving
queue nearing capacity

A possible problem has occurred or may occur, but the application
still functions correctly. However, it may not continue to work properly.



Channels and endpoints created, message enters/leaves transport, configuration
read, general helpful information

Important and successful milestones of application execution,
regardless of whether the application is working properly or not.



Debugging or application optimization

Low level events for both user code and servicing are emitted.


Activity Tracing

Tracing for transfers, activity boundaries, start/stop

Flow events between processing activities and components.



All listed events

Application may function properly. All events are emitted.

Trace Sources:

WCF defines a trace source for every assembly. Traces generated within an assembly are accessed by the listeners which are defined for that source. The below trace sources are defined:

  • System.ServiceModel: Logs all stages of WCF processing, whenever the configuration is read, a message is processed in transport, security processing, a message is dispatched in user code, and so on.
  • System.ServiceModel.MessageLogging: Logs all messages that flow through the system.
  • System.IdentityModel: Logs data for authentication and authorization.
  • System.ServiceModel.Activation: Logs the activity of creating and managing service hosts.
  • System.IO.Log: Logging for the .NET Framework interface to the Common Log File System (CLFS).
  • System.Runtime.Serialization: Logs when objects are read or written.
  • CardSpace: Logs messages related to any CardSpace identity processing that occurs within WCF context.