System.Xml Possible Memory Leak RRS feed

  • Question

  • We have a .Net Service that maps an input document into an XML file, that gets processed by another service. From the beginning of this year we have noticed that the site has been consuming memory but not really releasing memory and as a result when it tries to consume more memory than the server can handle it forces the server to restart.

    We believe the culprit is the .Net Framework's System.Xml.dll when dealing with the System.Xml.Xsl.XslCompiledTransform class.

    The framework version is version that’s installed on the host server is 4.6.2.

    Has anyone ran into an issue like this or know if there’s a solution like upgrading the .Net Framework version?

    Or should we be looking at putting in more object disposing in our code?


    Friday, July 19, 2019 5:22 PM

All replies

  • From the msdn docs

    Dynamically Generated Assemblies

    To increase performance, the XML serialization infrastructure dynamically generates assemblies to serialize and deserialize specified types. The infrastructure finds and reuses those assemblies. This behavior occurs only when using the following constructors:


    XmlSerializer.XmlSerializer(Type, String)

    If you use any of the other constructors, multiple versions of the same assembly are generated and never unloaded, which results in a memory leak and poor performance. The easiest solution is to use one of the previously mentioned two constructors. Otherwise, you must cache the assemblies in a Hashtable, as shown in the following example.

    Saturday, July 20, 2019 12:29 AM
  • Thanks, Ken.

    I'll take a look at your suggestion.

    Thursday, July 25, 2019 4:05 PM
  • Hi Ken,

    We've went through the code and we don't directly call the XmlSerializer constructors so we weren't able to apply any of the suggestions above. Thanks

    Tuesday, August 6, 2019 4:08 PM
  • Hi qm403,

    Thanks for your feedback.

    It seems that your problem has been solved. If so, please post "Mark as answer" to the appropriate answer, so that it will help other members to find the solution quickly if they face a similar issue.

    Best Regards,

    Xingyu Zhao

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Wednesday, August 7, 2019 9:08 AM
  • Hi Xingyu,

    We weren't able to apply Ken's suggestion but would like to keep this question open to see if anyone else can provide more feedback or another possible solution.


    Monday, August 12, 2019 5:09 PM