WCF call causing memory leak

We are having problems with a WCF services call that is leaking memory. In our research we think we are calling the service correctly and handling errors that come back from it appropriately. We have even confirmed this with MSDN articles and sample WCF code obtained from a MS web site.

Here is a sample of the code that causes the leak. On the SaveAssociation call, the code on the other side throws an exception. This causes the channel to enter the faulted state. The first catch statement catches the exception (SystemException) and calls Abort() on the client which should immediately abort the session and close the client connection. However, watching this process run this code over and over in a loop we just see the memory used by the process climb and climb.

var client = new FrameworkServiceReference.MAServiceClient();

// Get User domain name
client.ClientCredentials.UserName.UserName = "username";
client.ClientCredentials.UserName.Password = "password";

OperationContextScope a1 = new OperationContextScope(client.InnerChannel);
MessageHeader<string> customHeaderAppID = new MessageHeader<string>("Account Management");
System.ServiceModel.Channels.MessageHeader a2 = customHeaderAppID.GetUntypedHeader("application", "http://www.ma.com");
OperationContext.Current.OutgoingMessageHeaders.Add(a2);

try
{
            client.SaveAssociation(association);
            client.Close();
}
catch (SystemException se)
{
            client.Abort();
}
catch (Exception ex)
{
            client.Abort();
}

Here is the error we receive…

System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Object reference not set to an instance of an object. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.NullReferenceException: Object reference not set to an instance of an object.
   at Multiview.Business.Core.CoreObject.ValidateItem(String Item, String Value)
   at Multiview.Business.Core.User.UpdateUser()
   at Multiview.Business.Core.User.Save()
   at Multiview.Core.ServiceLibrary.MultiviewService.SaveCRMUser(User user, Guid CRMGuid)
   at SyncInvokeSaveCRMUser(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessa开发者_开发百科ge3(MessageRpc& rpc)
   at System.ServiceMode...).

What can be done to stop this leak?

If memory on the server goes up, check the server log. Probably the object you return has a circular reference. This means that when it is returned, the server will throw a stack overflow when serializing the object.

Try to configure your service with:

IncludeExceptionDetailInFaults=true

And create some logs (server and client side):

<system.diagnostics>
<sources>
  <source name="System.ServiceModel" switchValue="Error, ActivityTracing" propagateActivity="true">
    <listeners>
      <add name="xml" />
    </listeners>
  </source>
  <source name="CardSpace">
    <listeners>
      <add name="xml" />
    </listeners>
  </source>
  <source name="System.IO.Log">
    <listeners>
      <add name="xml" />
    </listeners>
  </source>
  <source name="System.Runtime.Serialization">
    <listeners>
      <add name="xml" />
    </listeners>
  </source>
  <source name="System.IdentityModel">
    <listeners>
      <add name="xml" />
    </listeners>
  </source>
</sources>
<sharedListeners>
  <add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="C:\t\mylog.svclog" />
</sharedListeners>
</system.diagnostics>

If you have a problem with memory leaks you should start with some memory profiler and find which objects are living in your memory. That will lead you to the source of leakage.

You can start with the fact that OperationContextScope is disposable.