StackOverflowException inside SimpleInjector in MVC WebApi project - asp.net-mvc-5

Question

We are building a website with UI and API, both hosted within single ASP.NET MVC project ("usual" MVC + MVC WebApi under one hood). We are using SimpleInjector (the latest version, 2.8 as of now) for dependency injection. We have single composition root class to construct containers for both UI and API parts.
Since recently (noticed a couple of weeks ago) we are receiving connection reset errors (ERR_CONNECTION_RESET) when we try accessing any API method in QA. The same code in UAT works just fine.
Locally, the same code errors out with StackOverflowException if run under IIS, but works fine under IIS Express and under IIS if we run it with debugger attached.
Our current code gives the following stack trace when we attach to iis worker process after the exception occurs:
SimpleInjector.Compiled!DynamicInstanceProducer3.GetInstance(object[] constants)
SimpleInjector.dll!SimpleInjector.CompilationHelpers.CompileInDynamicAssemblyAsClosure<System.__Canon>.AnonymousMethod__1a()
SimpleInjector.dll!SimpleInjector.InstanceProducer.GetInstance()
SimpleInjector.dll!SimpleInjector.Container.GetInstance(System.Type serviceType)
System.Web.Http.dll!System.Web.Http.Dispatcher.DefaultHttpControllerActivator.GetInstanceOrActivator(System.Net.Http.HttpRequestMessage request, System.Type controllerType, out System.Func<System.Web.Http.Controllers.IHttpController> activator)
System.Web.Http.dll!System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(System.Net.Http.HttpRequestMessage request, System.Web.Http.Controllers.HttpControllerDescriptor controllerDescriptor, System.Type controllerType)
System.Web.Http.dll!System.Web.Http.Controllers.HttpControllerDescriptor.CreateController(System.Net.Http.HttpRequestMessage request)
System.Web.Http.dll!System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync()
mscorlib.dll!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync>(ref System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync stateMachine)
System.Web.Http.dll!System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Net.Http.dll!System.Net.Http.HttpMessageInvoker.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Web.Http.dll!System.Web.Http.Dispatcher.HttpRoutingDispatcher.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Web.Http.dll!System.Web.Http.HttpServer.SendAsync()
mscorlib.dll!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Web.Http.HttpServer.SendAsync>(ref System.Web.Http.HttpServer.SendAsync stateMachine)
System.Web.Http.dll!System.Web.Http.HttpServer.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Net.Http.dll!System.Net.Http.HttpMessageInvoker.SendAsync(System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
System.Web.Http.WebHost.dll!System.Web.Http.WebHost.HttpControllerHandler.ProcessRequestAsyncCore()
mscorlib.dll!System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Web.Http.WebHost.HttpControllerHandler.ProcessRequestAsyncCore>(ref System.Web.Http.WebHost.HttpControllerHandler.ProcessRequestAsyncCore stateMachine)
System.Web.Http.WebHost.dll!System.Web.Http.WebHost.HttpControllerHandler.ProcessRequestAsyncCore(System.Web.HttpContextBase contextBase)
System.Web.dll!System.Web.TaskAsyncHelper.BeginTask(System.Func<System.Threading.Tasks.Task> taskFunc, System.AsyncCallback callback, object state)
System.Web.dll!System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep step, ref bool completedSynchronously)
System.Web.dll!System.Web.HttpApplication.PipelineStepManager.ResumeSteps(System.Exception error)
System.Web.dll!System.Web.HttpApplication.BeginProcessRequestNotification(System.Web.HttpContext context, System.AsyncCallback cb)
System.Web.dll!System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest wr, System.Web.HttpContext context)
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags)
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags)
[Native to Managed Transition]
[Managed to Native Transition]
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags)
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags)
[AppDomain Transition]
I.e., looks like nothing bad happens inside our code.
When we take some old code (one that is currently in production, for instance, and is working fine), we also have StackOverflowException, but in static constructor of our EntityFramework DB context (code first) on line
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContextType, Configuration>());
Funny thing is that it no longer suggests to attach to the process with old code, so I cannot provide the stack trace - I will update the question, if I manage to grab it.
Note that usual MVC works normally still (while using the same Composition Root class with slight natural differences for WebApi and MVC creation modes).
I can provide further code snippets, if it is reasonable, but the project is quite big, so I am not sure small snippets will help here.
Any ideas what this might be? Can it be because of the number of dependencies?
UPDATE: The issue does not appear after in one of the services which depends on four other services I removed the dependencies from the constructor, injected the container there, and resolved the dependencies manually in the constructor. I.e., it was:
public MyDependentService(IDependency1 dependency1, IDependency2 dependency2, IDependency3 dependency3, IDependency4 dependency4)
{
this.dependency1 = dependency1;
this.dependency2 = dependency2;
this.dependency3 = dependency3;
this.dependency4 = dependency4;
}
and it became
public MyDependentService(Container container)
{
this.dependency1 = container.GetInstance<IDependency1>();
this.dependency2 = container.GetInstance<IDependency2>();
this.dependency3 = container.GetInstance<IDependency3>();
this.dependency4 = container.GetInstance<IDependency4>();
}
So now everything works, but of course this is not the right way to deal with dependencies. This is actually not IoC anymore. What's going on?