We implemented the Autofac to work with Sitecore default DI implementation by following the guide below: https://doc.sitecore.net/sitecore_experience_platform/developing/developing_with_sitecore/dependency_injection


And here's the code snippet:

public class AutofacServiceProviderBuilder
  : BaseServiceProviderBuilder
        protected override IServiceProvider BuildServiceProvider(IServiceCollection serviceCollection)
            var builder = new ContainerBuilder();


            // Register our custom services via a module.

            // Register all MVC controllers in the current assembly.
            IContainer container = builder.Build();
            return container.Resolve<IServiceProvider>();

While doing a load testing, we are seeing a steady increase of memory usage for our asp.net mvc application hosted in azure web app. Once memory hits 90% site become unresponsive and crashes.

Looking at memory dump we noticed a top large objects are related to autofac. enter image description here enter image description here

By analyzing the memory dump we found that ALL of our Controllers are referencing to the Root scope hence they never get garbage collected and eventually fills up the memory.

Would be good if I can get any suggestions on what we are doing very wrong that makes all our controllers hanging off Root.

  • 1
    I think you might be reading the memory dump incorrectly. Inclusive Size (Bytes) includes the sizes of referenced objects (see here). So the Autofac entities don't really take up much memory, it's the objects they reference that might be the issue. Could you show us the same table, but sorted by Size (Bytes) instead? This would show which objects take up the most memory. Commented Jun 7, 2017 at 13:48
  • 1
    And might I add; a single snapshot of memory does not indicate a memory leak. For it to be a memory leak, the number would have to be growing continuously over time - never coming back down again.
    – Mark Cassidy
    Commented Jun 7, 2017 at 15:36
  • Just to add onto what @MarkCassidy said, monitoring that data overtime is very important to understanding what the data is actually telling you. For example, if you experience instances where the memory use builds up and then takes steep drops, this could be a sign that your application is making heavy use of caching and responsively (and correctly) evicting caches when short on machine resources. When executing any load testing, it is important to spend some of your time running heavy, unrelated processes on the server to see how the application reacts to system resource usage. Commented Jun 8, 2017 at 16:22
  • Its definitely a bug. I am waiting for patch
    – Nil Pun
    Commented Jun 8, 2017 at 21:04

3 Answers 3


We managed to identify the root cause of our memory leak. With help of MS and Sitecore, memory dump had lots of our controller and services hanging off of Root scope.

By design the sitecore disposes the objects on request end. Given that the controllers injected by Autofac were not compatible with Sitecore controllers, the objects didn't get disposed. As a result our controllers built over time, reached 100% memory limit and app pool got restarted. As a result 500 error.

How to fix? Ask support to provide the patch applicable to your DI.

  • did sitecore provide you with a knowledge base page link or something similar. We are running in exactly the same issue.
    – marto
    Commented Oct 11, 2017 at 15:56
  • Has anyone got solution for this problem? we are facing the exact same issue. Or is below article help in resolving this? kb.sitecore.net/articles/535948
    – PaRsH
    Commented Oct 17, 2017 at 17:39

There was a bug fix for this in Sitecore 8.2:


It didn't make it into Sitecore 9.0, so ask support for the new fix if you experience similar memory leak issues in v9.


The problem is in not registered ISitecoreServiceLocatorScope service when you inherit from the BaseServiceProviderBuilder class.

Try to inherit from the DefaultServiceProviderBuilder class. It launches ServicesScopeConfigurator. I did so, and there were no controller instances in memory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.