Home/ Questions/Q 6011965
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T02:20:07+00:00

I have a C# Windows Service that I recently moved from .NET 3.5 to

  • 0

I have a C# Windows Service that I recently moved from .NET 3.5 to .NET 4.0. No other code changes were made.

When running on 3.5, memory utilzation for a given work load was roughly 1.5 GB of memory and throughput was 20 X per second. (The X doesn’t matter in the context of this question.)

The exact same service running on 4.0 uses between 3GB and 5GB+ of memory, and gets less than 4 X per second. In fact, the service will typically end up stalling out as memory usage continue to climb until my system is siting at 99% utilization and page file swapping goes nuts.

I’m not sure if this has to do with garbage collection, or what, but I’m having trouble figuring it out. My window service uses the “Server” GC via the config file switch seen below:

  <runtime>
    <gcServer enabled="true"/>
  </runtime>

Changing this option to false didn’t seem to make a difference. Futhermore, from the reading I’ve done on the new GC in 4.0, the big changes only effect the workstation GC mode, not server GC mode. So perhaps GC has nothing to do with the issue.

Ideas?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well this was an interesting one.

    The root cause turns out to be a change in the behavior of SQL Server Reporting Services’ LocalReport class (v2010) when running this on top of .NET 4.0.

    Basically, Microsoft altered the behavior of RDLC processing so that each time a report was processed it was done so in a seperate application domain. This was actually done specifically to address a memory leak caused by the inability to unload assemblies from app domains. When the LocalReport class processed an RDLC file, it actually creates an assembly on the fly and loads it into the app domain.

    In my case, due to the large volume of report I was processing, this was resulting in very large numbers of System.Runtime.Remoting.ServerIdentity objects being created. This was my tip off to the cause, as I was confused as to why processing an RLDC required remoting.

    Of course, to call a method on a class in another app domain, remoting is exactly what you use. In .NET 3.5, this wasn’t necessary as, by default, the RDLC-assembly was loaded into the same app domain. In .NET 4.0, however, a new app domain is created by default.

    The fix was fairly easy. First I needed to go enable legacy security policy using the following config:

      <runtime>
    <NetFx40_LegacySecurityPolicy enabled="true"/>
  </runtime>

    Next, I needed to force the RDLCs to be processed in the same app domain as my service by calling the following:

    myLocalReport.ExecuteReportInCurrentAppDomain(AppDomain.CurrentDomain.Evidence);

    This resolved the issue.

    • 0