.NET Memory Leak: XmlSerializing your way to a Memory Leak

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

tzagotta — Thu, 16 Feb 2006 01:56:06 GMT

Is this issue the same or different in .NET 2.0?

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Don — Thu, 16 Feb 2006 02:11:24 GMT

Wow. Really frightening. I'm checking my code right now. Thanks.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Thu, 16 Feb 2006 11:52:04 GMT

I dont believe that this has changed in .NET 2.0, tracking assemblies with the gc and unloading them at garbage collection is a pretty large task given the implications it would have.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

john_grace — Thu, 16 Feb 2006 12:30:28 GMT

I believe the new way to do this type of work in .NET 2.0 is to use the SGEN utility to generate the necessary classes.
Then bring these classes into your solution so there is no need to generate a dynamic assembly.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Thu, 16 Feb 2006 12:49:47 GMT

Nice info about SGEN, definitely worth looking into

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Matt — Thu, 16 Feb 2006 12:52:56 GMT

So why doesn' t the documentation for the class explain this?

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Thu, 16 Feb 2006 13:09:03 GMT

My guess is that it is because it is close to impossible to document everything, and this is an internal implementation detail. When it was developed I don't believe that it was intended to be used this way (since we are talking about special cases in the constructor). This is why we create kb articles when we discover issues, and of course also why i blog about them:)

If you feel that it should be added to the original msdn content (which i think is a great idea) I would urge you to use the comment feature on the msdn topic so that the content developers can change it.

Interesting Finds

Jason Haley — Thu, 16 Feb 2006 14:16:46 GMT

Interesting Finds

Jason Haley — Thu, 16 Feb 2006 14:18:57 GMT

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Matt — Thu, 16 Feb 2006 14:19:19 GMT

Oh, I see it is documented in the 'about xmlserializer' topic.

(Incidentally, we were burned by the xsl transform script variant of this issue)

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Kerry Jenkins — Fri, 17 Feb 2006 21:29:54 GMT

Thank you for the great content you are sharing!

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Mark Wan — Fri, 17 Feb 2006 22:03:08 GMT

Very useful information. Thanks for writing this blog.

I suppose this is the same problem in BinarySerializer as well?

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Keith Hill — Sat, 18 Feb 2006 03:41:16 GMT

Awesome! Keep it coming.

How to create giant memory leaks with XmlSerializer

Dan Crevier's Blog — Sun, 19 Feb 2006 07:11:30 GMT

In this post, Tess describes how using repeatedly calling:
XmlSerializer serializer = new XmlSerializer(typeof(PurchaseOrder),...

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Eric Terrell — Wed, 01 Mar 2006 22:37:51 GMT

Very useful article. Can you tell me which forms of the Regex constructor cause this issue? Or does it just happen if you specify the "compiled" flavor of Regex?

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

dblack — Sat, 11 Mar 2006 20:36:29 GMT

I've found your posts about Memory debugging in .NET EXTREMELY useful! Thank you and keep posting away!

.NET Resources

mattonsoftware.com — Sat, 06 May 2006 11:30:29 GMT

The following links to .NET resources have been collated over time with the assistance of colleagues.&nbsp;...

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

jeremyp — Thu, 14 Sep 2006 22:50:36 GMT

Awesome post, as usual! :)

One more trick that can help is to use -MT on the dumpmodule, like !dumpmodule -MT <da_addr> and look at the referenced types for that assembly. This can sometimes be easier to view than the dc output... ;)

XmlSerializer : lenteur de la première initialisation et comment y remedier

CoqBlog — Sun, 25 Feb 2007 02:35:04 GMT

A la première initialisation d'une instance de XmlSerializer pour un type, le constructeur déclenche

Ännu ett projekt som XMLSeriliserar sig in i minnesläckor...

Shallow thoughts from a consultant @ Microsoft — Fri, 23 Mar 2007 14:38:38 GMT

Igår var jag inne och debuggade en dump från ett projekt där man hade problem med en w3wp process som

Ännu ett projekt som XMLSerialiserar sig till Out-Of-Memory...

RSS It All — Fri, 23 Mar 2007 15:33:19 GMT

Igår var jag inne och debuggade en dump från ett projekt där man hade problem med en w3wp process som

All in a days work…

All in a days work… — Sat, 14 Apr 2007 04:45:00 GMT

PingBack from http://billy-girlardo.com/delicious/2007/04/13/links-for-2007-04-14/

.NET Garbage Collector PopQuiz - Followup at Sanal Kiler

.NET Garbage Collector PopQuiz - Followup at Sanal Kiler — Sun, 15 Apr 2007 23:07:13 GMT

PingBack from http://sanal.org/?p=309

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Simon Gibbs — Wed, 18 Apr 2007 11:04:37 GMT

I would also be grateful for any additional detail on the Regex flavour of the problem.

.NET Memory Leak: XmlSerializing your way to a Memory Leak

n.code — Thu, 19 Apr 2007 11:57:29 GMT

Tess Ferrandez talks about a .NET memory leak , caused by using the default constructors other than,

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

ScrawnyBrawn — Thu, 19 Apr 2007 18:40:26 GMT

Nice article. It 'brings back good memories' of using adplus!

I have not gone through rest of your blog.. but I would say.. the title needs to be changed...

If broken it is, fix it you 'must' ... that sounds more yoda-ish :)

.NET Garbage Collector PopQuiz - Followup

If broken it is, fix it you should — Mon, 07 May 2007 09:19:29 GMT

It was really exciting to see that so many people answered the .NET GC PopQuiz , especially seeing that

top 10 windbg.exe usage articles

roy ashbrook — Mon, 25 Jun 2007 00:10:20 GMT

These are the articles (in no particular order) that I felt best showed a thorough use of the windbg

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Niels Tindbæk — Fri, 29 Jun 2007 12:48:48 GMT

Great article!

We do a lot of webservice calls, and we have the same issues. Mostly shown as OutOfMem exceptions in the internal code of the XmlSerializer.Deserialize.

But since it is called by the framework code of the webservice classes, I cant really do any caching.

Do you have a suggestion for our situation?

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Fri, 29 Jun 2007 13:37:03 GMT

Hi Nils,

I am not sure that you are looking at the same thing here as what is described in the article.

The article is about leaking dynamic assemblies when creating new xmlserializers, in the case of webservices you will only have one xmlserializer per type you are serializing so that should not amount to too many.

If you are seeing OOMs when you deserialize i see two reasons why this could happen

1. If each deserialization is only generating a small string/object your problem is that you have high overall memory consumption and you should investigate what is using up all the memory...

2. more likely, if it seems to happen frequently in Deserialize, you are sending a lot of data back and forth so that the data sent over or the deserialized data is huge and requires a new large object heap block that wont fit anywhere.

I would recommend that you run with GCFailFastOnOOM to see how much it is trying to allocate when it fails to see if this is some really big chunk, unless you fit into #1 where your memory consumption overall is big.

There are a couple of post on this blog on how to troubleshoot high memory issues that you might want to look into as well.

Thanks

Tess

关于.net内存泄露的问题，请高手指点

Tiny — Sat, 07 Jul 2007 09:28:30 GMT

一个.net开发的网站项目现在到了收尾阶段，但突然发现一个问题：网站访问量不高，占用内存却长地飞快，甚至2，3个小时内存使用就上涨到了1g多，非常郁闷。google了一下，查到了几篇相关文章。无法卸...

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

chen — Mon, 09 Jul 2007 19:15:38 GMT

Hi Tess,

I'm debugging a slightly different beast that happens only on certain m/cs in our environment. First a quick background on the environments:

- all m/cs are running on Windows Server 2003, SP1 (Std Edition) IIS 6.0

- 4 GB memory

- Both .NET 1.1 & 2.0 installed

- number of hotfixes applied

Initial investigation lead me to believe that a possible memory leak in "private bytes" was specific to our web service implementation. So we eventually stubbed out all app specific code & still saw the private bytes increase steadily until the worker process recycled because it reached the "Maximum used memory" limit for the App Pool config.

To confirm the theory that app related stuff wasn't the culprit, i then created a basic "HelloWorld" web service & set the app pool settings to recycle the worker process when the "Maximum used memory" reached 50MB. Ran the test... private bytes increased steadily and eventually the worker process recycled.

I re-ran this same test on a different m/c (same OS level, 2GB memory but a slightly different set of hotfixes applied to it). Here the HelloWorld app does NOT exhibit the leak (which is what i was expecting).

I've tried analysing by gathering minidumps, VA dumps, perf logs - the only thing that stands out between the leaking/non-leaking servers is the Heap size.

Here are some excerpts from the VADump for the leaking case (dumps were taken roughly 45secs apart):

Category Total Private Shareable Shared

Pages KBytes KBytes KBytes KBytes

Page Table Pages 84 336 336 0 0

Other System 39 156 156 0 0

Code/StaticData 3782 15128 1312 2736 11080

Heap 14184 56736 56736 0 0

Stack 79 316 316 0 0

Teb 33 132 132 0 0

Mapped Data 165 660 0 104 556

Other Data 3179 12716 12712 4 0

Total Modules 3782 15128 1312 2736 11080

Total Dynamic Data 17640 70560 69896 108 556

Total System 123 492 492 0 0

Grand Total Working Set 21545 86180 71700 2844 11636

Category Total Private Shareable Shared

Pages KBytes KBytes KBytes KBytes

Page Table Pages 97 388 388 0 0

Other System 51 204 204 0 0

Code/StaticData 3790 15160 1312 2756 11092

Heap 30298 121192 121192 0 0

Stack 79 316 316 0 0

Teb 33 132 132 0 0

Mapped Data 165 660 0 104 556

Other Data 3179 12716 12712 4 0

Total Modules 3790 15160 1312 2756 11092

Total Dynamic Data 33754 135016 134352 108 556

Total System 148 592 592 0 0

Grand Total Working Set 37692 150768 136256 2864 11648

Category Total Private Shareable Shared

Pages KBytes KBytes KBytes KBytes

Page Table Pages 106 424 424 0 0

Other System 60 240 240 0 0

Code/StaticData 3792 15168 1312 2756 11100

Heap 39342 157368 157368 0 0

Stack 80 320 320 0 0

Teb 34 136 136 0 0

Mapped Data 165 660 0 104 556

Other Data 3182 12728 12724 4 0

Total Modules 3792 15168 1312 2756 11100

Total Dynamic Data 42803 171212 170548 108 556

Total System 166 664 664 0 0

Grand Total Working Set 46761 187044 172524 2864 11656

The Heap pages show the increase while the GC Heap (Other Data) does not show any increase at all (this is what I see in the PerfMon logs as well). What/why is there a dramatic increase in the heap allocations (especially, private bytes)?

The other thing I see in the mini dumps is that the number of System.String objects & size is seemingly high in the m/c where the leak is happening whereas those values are much lower on the server where it isn’t leaking.

Can you shed some light on what else should I be looking at? Our production web servers are exhibiting this behavior and we've been unable to figure out why. Please help!

Thanks.

PS: btw, i've learned a lot from reading thru your blogs & without them, i wouldn't have gotten the faintest clue on what to look for.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

chen — Mon, 09 Jul 2007 22:01:49 GMT

Not sure if this is relevant (perhaps, it is) - the Windows Server 2003 m/cs use the /3GB switch in the boot.ini file.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Marty — Mon, 10 Sep 2007 21:37:35 GMT

This is a problem with WCF using the XmlSerializer!!!!!! [System.ServiceModel.XmlSerializerFormatAttribute()]

Using Process Explorer, we see the temp assemblies growing unless we declare the client proxy as static. Unfortunately a lot of developers will be hit by this problem if Microsoft does not get a fix. The solution is not to use the DataContractSerializer (which we assume does not have the problem). We would have to re-tool all our classes.

This is a huge problem for our application which runs out of memory by the end of the day with 100 or so users. This bug does not make moving to WebServices easier - Microsoft should release a patch for this immediately!!!!

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Tue, 11 Sep 2007 10:16:49 GMT

Hi Marty,

I haven't really worked a whole lot with WCF so I don't know the details regarding the problem you're talking about but before going to deep into it I just want to see if it is a real problem or a percieved problem.

When you call a webservice from ASP.NET for example you will also create dynamic assemblies for xml serialization of the parameters but you will only create one per type/method so after initially you will create a few but once they are all initialized they will be reused since they are created with the default constructors. Are you saying that with this construct you keep creating new ones throughout the life of the process? I.e. if you call the same web service twice, will you create new assemblies?

If you do continually create new ones for each call to the ws, please post some sample code and I will take a look if time permits or start a case with support. If the 2nd call to a web service does not generate new assemblies your memory problem lies elsewhere. You will need to generate at least one new assembly per type you serialize otherwise serialization will not work...

Thanks

Tess

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Marty — Tue, 11 Sep 2007 22:06:07 GMT

Hi Tess, thanks for the reply!!!

just a summary again of what we are experiencing... we are trying to get this to Microsoft.

We have experienced the documented XmlSerializer assembly leak problem reported by Microsoft as a problem with the .NET Framework 1.0, 1.1 and 2.0.

http://support.microsoft.com/kb/886385/en-us

Specifically, we use WCF to generate client proxies to WebServices and we also instruct WCF to use the XmlSerializerFormatter and not the DataContractFormatter.

Because we rely on the XmlSerializerFormatter, we have no control over the WCF code that deserializes xml data streams into managed objects. The call to Deserialize from the Service Model exhibits the problem. The call to deserialize uses a constructor of the XmlSerializer that does not cache assemblies based on the type. And it is very easy to duplicate by using Process/App Domain Viewer - Current and Total Assemblies counts grow.

See stack trace below.

We have a workaround whereby we cache the client proxy classes but we feel that this is not an ideal solution long term.

Ideally, we would like a patch to the Service Model framework (WCF) that addresses the problem when invoking the XmlSerializer by caching the serializer in the assembly (as described) or better yet, a path to the XmlSerializer that implements caching in ALL constructors.

Stack Trace (Crude cut and paste - please forgive me).

qtnaxaft!Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer1.Deserialize(System.Xml.Serialization.XmlSerializationReader reader = {Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderIPlanDesign}) + 0x40 bytes

System.Xml.dll!System.Xml.Serialization.XmlSerializer.Deserialize(System.Xml.XmlReader xmlReader = {Element, Name="a:OfferingCombination"}, string encodingStyle, System.Xml.Serialization.XmlDeserializationEvents events) + 0xa2 bytes

System.Xml.dll!System.Xml.Serialization.XmlSerializer.Deserialize(System.Xml.XmlReader xmlReader, string encodingStyle) + 0x21 bytes

System.ServiceModel.dll!System.ServiceModel.Dispatcher.XmlSerializerOperationFormatter.DeserializeBody(System.Xml.XmlDictionaryReader reader, System.ServiceModel.Channels.MessageVersion version, System.Xml.Serialization.XmlSerializer serializer, System.ServiceModel.Description.MessagePartDescription returnPart = Name={GetOfferingCombinationsResult}, Namespace="http://tempuri.org/", Type={System.Void}, Index=0}, System.ServiceModel.Description.MessagePartDescriptionCollection bodyParts = Count = 1, object[] parameters = {Dimensions:[1]}, bool isRequest = false) + 0x63 bytes

System.ServiceModel.dll!System.ServiceModel.Dispatcher.XmlSerializerOperationFormatter.DeserializeBody(System.Xml.XmlDictionaryReader reader, System.ServiceModel.Channels.MessageVersion version, string action, System.ServiceModel.Description.MessageDescription messageDescription, object[] parameters, bool isRequest) + 0x137 bytes

System.ServiceModel.dll!System.ServiceModel.Dispatcher.OperationFormatter.DeserializeBodyContents(System.ServiceModel.Channels.Message message, object[] parameters, bool isRequest) + 0x95 bytes

System.ServiceModel.dll!System.ServiceModel.Dispatcher.OperationFormatter.DeserializeReply(System.ServiceModel.Channels.Message message, object[] parameters) + 0x198 bytes

System.ServiceModel.dll!System.ServiceModel.Dispatcher.ProxyOperationRuntime.AfterReply(ref System.ServiceModel.Dispatcher.ProxyRpc rpc = {System.ServiceModel.Dispatcher.ProxyRpc}) + 0x33 bytes

System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannel.HandleReply(System.ServiceModel.Dispatcher.ProxyOperationRuntime operation = {System.ServiceModel.Dispatcher.ProxyOperationRuntime}, ref System.ServiceModel.Dispatcher.ProxyRpc rpc = {System.ServiceModel.Dispatcher.ProxyRpc}) + 0xd8 bytes

System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannel.EndCall(string action, object[] outs, System.IAsyncResult result) + 0xde bytes

System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannelProxy.InvokeEndService(System.Runtime.Remoting.Messaging.IMethodCallMessage methodCall = {System.Runtime.Remoting.Messaging.Message}, System.ServiceModel.Dispatcher.ProxyOperationRuntime operation = {System.ServiceModel.Dispatcher.ProxyOperationRuntime}) + 0x45 bytes

System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannelProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage message = {System.Runtime.Remoting.Messaging.Message}) + 0x81 bytes

mscorlib.dll!System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(ref System.Runtime.Remoting.Proxies.MessageData msgData, int type) + 0x273 bytes

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Chad — Tue, 02 Oct 2007 20:52:12 GMT

Can/does the same problem occur if you implement iXmlSerializable in an ASP.Net application.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Wed, 03 Oct 2007 09:35:45 GMT

Hi Chad,

The only reason it would make the same problem occurr would be if someone called new XmlSerializer with one of the constructors listed above... just implementing iXmlSerializable would not cause an issue...

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

GuillaumeB — Mon, 22 Oct 2007 12:45:32 GMT

Hi Tess,

I'm currently working on a big project involving several WCF services. We have big performance and memory consumption problems for 3 of them.

These 3 services are actually designed to act as gateways for external partners Java webservices.

We used svcutil to generate the client proxy to call these services and we saw that WCF runtime is generating an on-the-fly XMLSerializer assembly *for each call* to the remote WS. As you described, we saw that unfortunately a new assembly is generated each time we call the same method.

We tried many things to solve this problem : SGEN generation, we also tried to used different option of the svcutil generation to change the type of Formatter(DataContractFormatter, XmlSerializerFormatter),...

But - as marty explainded in his comment- we're also running out of memory during our load test with only 100 users.

We're exploring this problem with the MS premium support because we think that our perf and memory leak problem is coming from this strange WCF behaviour but we're running out of ideas and the problem is still there !

Do you have any news of Marty's problem?

Do you know if a fix has been published?

Thanks a lot!

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Mon, 22 Oct 2007 14:15:34 GMT

To be honest I haven't worked with WCF enough to be able to give you any answers off-hand. For "normal" webservices you would only create one per type, but perhaps WCF uses one of the non-standard constructors... One idea, in order to figure out if this is the case, would be to run a test in a controlled environment where you set a breakpoint with !bpmd -md <methoddesc> on the different XmlSerializer..ctor (constructors)

you can get the method descriptors by doing !dumpheap to find the methodtable for XmlSerializer and then doing !dumpmt -md on that methodtable.

At least that could tell you why you create new assemblies all the time.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Mike — Sat, 29 Dec 2007 02:49:56 GMT

We have the exact same issue... new assemblies getting created on every call. We have contracts for every object but am still seeing many references to:

[System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]

Is there any update on a solution?

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Mike — Mon, 31 Dec 2007 02:45:36 GMT

For us it appears the issue is solved with .NET 2.0 SP1 that was released on 12/27. We are confirming with more tests but it appears fixed. And performance appears 100 times faster.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

flyingchen — Wed, 09 Jan 2008 16:32:40 GMT

i'm not good at english :(

i happened Marty's problem and solved it ! we use wcf to call services ,and so of the service are .asmx . And the proxy of the .asmx service is the problem . It serializ and deserialize every time that we call it. so the cup and memory are very high.

just do :

we use a object pool that cache the client proxy.

code:

public interface IWcfClientPoolElement<TClient> where TClient : IWcfClientPoolElement<TClient>, new()

{

WcfClientPool<TClient> Pool

{

get;

set;

}

public class WcfClientPool<TClient> where TClient : IWcfClientPoolElement<TClient>, new()

{

private Stack<TClient> m_container;

private int m_currentCount;

private int m_capacity;

private object m_mutex;

public WcfClientPool() : this(20) { }

public WcfClientPool(int capacity)

{

this.m_capacity = capacity;

this.m_container = new Stack<TClient>();

this.m_mutex = new object();

this.m_currentCount = 0;

}

public TClient GetClient()

{

while (true)

{

lock (this.m_mutex)

{

if (this.m_container.Count > 0)

{

return this.m_container.Pop();

}

else if (this.m_currentCount < this.m_capacity)

{

this.m_currentCount++;

TClient client = new TClient();

client.Pool = this;

return client;

}

else

{

Thread.SpinWait(100);

}

public void Restore(TClient client)

{

lock (m_mutex)

{

this.m_container.Push(client);

}

and

client code like this :

[System.Diagnostics.DebuggerStepThroughAttribute()]

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]

public partial class I_UserSoapClient : System.ServiceModel.ClientBase<I_UserSoap>, I_UserSoap,System.IDisposable,

Temporary.IWcfClientPoolElement<I_UserSoapClient>

{

private Temporary.WcfClientPool<I_UserSoapClient> pool = null;

void System.IDisposable.Dispose()

{

Pool.Restore(this);

}

.....

if you have any question ,please add me msn : flyingchen@live.com

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

flyingchen — Wed, 09 Jan 2008 16:35:21 GMT

we can use below way to use the proxy :

using (I_UserSoapClient objClient = pool.GetClient())

Using Reflector to search through code and resolve .NET issues

If broken it is, fix it you should — Thu, 10 Jan 2008 16:20:20 GMT

As you already know, i spend my days analyzing dumps for customers, and more often than not I don't have

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Joel — Tue, 12 Feb 2008 09:07:10 GMT

First off, I'm so glad that I found this post. It makes complete sense as to what is happening with my code.

I've also run into the same behavior that Marty noted about WCF services creating temporary serialization assemblies. I created a Windows Service that runs a polling thread to pickup messages from a WCF service. The polling thread uses a WCF client to invoke the remote service to get a list of available messages. The WCF client is then used to download each message. Everytime the polling thread executes, it creates a WCF client instance. This results in a temporary assembly being generated each time for the types used by the client.

We are using the .NET 3.0 Framework. I have not tried using .NET 3.5 to see if the issue has been fixed, as 3.5 is not available in our production environment.

It seems my only solution is to either cache WCF client instance, which won't solve the problem if the client has to be closed. This will only minimize the problem, not solve it. The other solution is to create an AppDomain, load the WCF client into that and execute the client methods from there. The AppDomain can then be unloaded when necessary. This seems like a bit of a kludge to me.

I'm really glad I found this article though. I should be able to get some sleep now that I know what the problem is.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Tue, 12 Feb 2008 10:32:17 GMT

Hi Joel,

I have to say that i haven't played at all with WCF services and usually WCF issues are handled by a different support team which is why I haven't run into this before. Now you make me curious, I think I'll have to look into this and see how it works.

Tess

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Joel — Wed, 13 Feb 2008 04:20:35 GMT

The problem has me really confused because I'm not doing anything special with the WCF client instances.

The WCF client code was created with svcutil.exe and the resulting client code file (C#) imported into the project. I couldn't use "Add Service Reference" from the IDE because the VS2005 install that I'm using on the R&D box does not have the Orcas extensions. The WCF service interface was annotated with the XmlSerializerFormatAttribute class.

Anyhow, while debugging the Windows Service, everytime I instantiate the client, a temporary serialization assembly is loaded. It's as if the internal XmlSerializer is not caching the types as noted in your article. Eventually the memory footprint grows into the hundreds of megabytes and that is obviously not something the server administrators are going to like. :)

At first I thought this might be an issue with the way I had designed the program. Essentially, the Windows Service is downloading the XML documents from a WCF service that I created to interacts with an ebMS product called Hermes (which is an open-source Java-based ebMS application.) My Windows Service checks each configured partnership for messages by queuing up a command object using ThreadPool.QueueUserWorkItem. Therefore, the WCF client is instantiated and executed in thread-pool thread. I speculated that this might be the problem with the XmlSerializer not caching the types, but it turns out I was wrong. Even if I execute the command object on a non-threadpool thread, the program still exhibits the same behavior.

I'm in the process of recreating the code under VS2008 and .NET 3.0 on my own personal development machine, to see if, for whatever reason, there is an issue with the VS2005/.NET 2.0/3.0 install on the R&D box.

Thank you again for your interest.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Wed, 13 Feb 2008 11:26:42 GMT

Feel free to send me a repro offline if you want...

I can't promise that I will look at it or that I will have any insightful information if I look at it because of time constraints and because, as I mentioned, I've haven't played much with WCF.

Still I am very curious so feel free to send it and I'll take a look if time permits.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Riaz M — Wed, 19 Mar 2008 23:19:30 GMT

public class serv : System.Web.Services.WebService

{

public struct ee

{

public string[] foo;

public int bar;

}

[WebMethod]

public ee HelloWorld()

{

ee eee = new ee();

eee.foo = new string[] { "test1", "test2" };

eee.bar = 434;

return eee;

}

If i invoke with HTTP POST (/service.asmx/HelloWorld) it returns a XML as it should BUT it adds 100k to memory everytime it's called and in the dump there are eventually thousands of types of

xml.serialization.generatedassembly.arrayofstringserializer

which is adding up to 1.2gb of memory

How can i implement cache if i'm not actually calling XMLSerializer?

Thanks!

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Thu, 20 Mar 2008 13:27:26 GMT

typically a webservice call would only generate one dynamic assembly since it would be using the new xmlserializer(type) but perhaps there is something going on here with the struct.

I am on easter vacation at the moment so I dont have access to all my tools but it sounds very interesting so I will definitely look into it. If I find something I will probably post it as a separate post.

Thanks

Tess

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Jared — Thu, 24 Apr 2008 08:24:32 GMT

Would there be a way to configure the .NET sampling profiler to profile everytime an assembly is loaded? That way we could find out which calls are causing it to happen.

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Thu, 24 Apr 2008 09:22:34 GMT

I dont know if you can configure the .net sampling profiler, not exactly sure which tool you are referring to, but you can either a) use debug diag with leaktracking turned on, which will give you stacks for when you're allocating memory on the loaderheap, or b) you could potentially create an adplus script that broke on load module and capture the stacks...

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Asutosh — Fri, 18 Jul 2008 16:24:37 GMT

Hi Tess

This is a really nice article. Thanks for putting it online. We have a similar memory leak issue for which I am currently working with Microsoft engineers to get it resolved. On intilal investigation, they say there are lots of dynamic assemblies of XmlSerializer. As per MS, we should use XmlSerializer(type) constructor to avoid loading new assemblies. I searched on whole solution and the only constructor I see being used is XmlSerializer(type) and .NET still seems to load a new assembly for every instantiation. BTW, my application is in .NET 2.0. The MS engineer wants me to run sgen.exe on the project that contains entities which are serialized and then just put the xyz.XmlSerializer.dll in the bin directory of the web projects which using the XmlSerializer object. I am not really convince that this will fix the problem. Please recommend. Thanks

re: .NET Memory Leak: XmlSerializing your way to a Memory Leak

Tess — Mon, 04 Aug 2008 22:45:37 GMT

It's a bit hard to comment on that just with this information... if you are not doing anything with any other constructors than XmlSerializer(type) then the issue is probably the amount and complexity of the items being serialized and in that case using sgen is usually one of the recommended ways to reduce the memory used for the serialization assemblies