ASP.NET Memory Leak: Byte arrays rooted in System.Security.Policy.Evidence

re: ASP.NET Memory Leak: Byte arrays rooted in System.Security.Policy.Evidence

Chris — Tue, 01 Jul 2008 00:41:57 GMT

Tess,

Thanks for post from my email but our solution ended up being a little different. First, we were already running SP1. And second, Our 4.5MB assembly was hosting a lot of our code, and all of our [WebMethod]s. We did a little Reflecting and found out that the "Executing Assembly" will be copied into memory by the Evidence class as part of CAS on every web service request, and remain in memory for the length of the request.

We moved our WebMethods out to a new assembly and changed our .asmx files to point to this new assembly. Our new WebMethods only assembly is only 300K and every method just calls the same old code in the big assembly and everything is working normally now. Hope this makes sense and is a valid solution.

Thanks for the help,

Chris

re: ASP.NET Memory Leak: Byte arrays rooted in System.Security.Policy.Evidence

John — Fri, 01 Aug 2008 18:13:28 GMT

I've found that with sp1 (on our local machines and our servers) whenever a web service request is made, the application will store the same assembly 4 times in the manged heap as byte arrays. This is very confusing.

To rule out any faults in the application, I created a new web app. Added a single web service. Used the "hello world" example that gets generated automatically when creating a new web service. To make it easier for me to differentiate the byte arrays, I changed the "hello world" string to a string builder containing a long lorem ipsum. I then just returned the toString() of the string builder. Built the application, ran it. Did an dump right before I ran the webservice(just used GET) and another right after. WinDbg showed 4 identical byte arrays containing the webservice assembly. I guess my question is, have you or anyone else seen this behavior before? Any idea what could be causing it.

At first I thought it was an awfully big coincidence that there are Soap, Soap 1.2, Get, and Post(4 total). After shutting off Soap and Soap 1.2 in the web config, it still stored 4 assemblies. I'm out of ideas. This has caused me many hours of headache on our production boxes as our web service assembly was well over 300kb. Our application hosts many templated sites which all will cause 4 of these assemblies to be build. So, 300kb x 4 x 1000 sites = out of memory.

I have modified the structure and split out some of the related web services into separate assemblies. This has dropped most of them down to below the LOH threshold. The application is constantly under development and I could see a developer adding more code to some of those assemblies potentially bringing them back into the LOH. I guess I'm just venting, but I would appreciate it if some of you could try to reproduce this. Maybe it's just all our boxes, maybe it's a misconfiguration, maybe it's a framework issue that could just as easily be fixed.

Anyways, thanks for your help.

John

re: ASP.NET Memory Leak: Byte arrays rooted in System.Security.Policy.Evidence

Tess — Mon, 04 Aug 2008 23:06:27 GMT

interesting... I dot recognize the problem though, sorry

re: ASP.NET Memory Leak: Byte arrays rooted in System.Security.Policy.Evidence

Michael Schwarz — Wed, 11 Feb 2009 13:43:13 GMT

Hi John, hi Tess,

I have the same issue here that I can see the content of the DLLs in \bin in memory. Maybe Tess has some time to have a look on this problem.

Regards,

Michael

Best Practices for CRM Memory Usage

Microsoft Dynamics CRM Team Blog — Fri, 13 Mar 2009 19:54:33 GMT

Are you trying to improve the memory usage of your .net application? I’ve spent some time recently trying