There is a .Net (v4.6) WebAPI having legacy middleware written in VB6. Most of middleware are COM DLLs, in COM+ application. Often with very few users, HTTPrequest making call to any of these COM DLL, the IIS worker process crashes, now this is not consistence.
Event log has crash log Application pool 'MyAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
A condition has occurred that indicates this COM+ application is in an unstable state or is not functioning correctly. Assertion Failure: m_guidLogicalThread == GUID_NULL
Server Application ID: {56C23B4E-EF46-4C46-9ABA-8CFAA386745E} Server Application Instance ID: {02DC69D6-B20F-4FB6-B1F2-B61AE32D5D51} Server Application Name: GMT_PrimeSuite The serious nature of this error has caused the process to terminate. COM+ Services Internals Information: File: com\complus\src\comsvcs\jit\jit.cpp, Line: 31 Comsvcs.dll file version: ENU 2001.12.10530.18999 shp
Below is the sample code of how COM instance is created and its method called.
dynamic comInstance = Activator.CreateInstance("Example.ISample");
comInstance.DoSomeWork();
After much investigation and test-harness found that late-binding i.e. runtime COM instance is the main culprit, made all COM DLLs direct reference with COM Interop Types embedded and replaced Activator.CreateInstance with Type's object creation (early binding) i.e our normal IEmployee ref = new ..... This has made significant improvement in resource consumption and management from COM. With ~7000 HTTP requests from fiddler, having COM call encapsulated, not seeing Complus exceptions as well as App-pool is not crashing anymore.