COM+ The run-time environment has detected an inconsistency in its internal state.

DeskTop Heap Exhaustion 


Ran into another mine field the other day – blew my foot right off before I could even realize what was happening.


The client received this error:


The run-time environment has detected an inconsistency in its internal state. This indicates a potential instability in the process that could be caused by the custom components running in the COM+ application, the components they make use of, or other factors. Error in d:\nt\com\complus\src\comsvcs\threads\stathread.cpp(284), hr = 80070000: CSTAThread: CoGetApartmentID failed


The run-time environment has detected an inconsistency in its internal state. This indicates a potential instability in the process that could be caused by the custom components running in the COM+ application, the components they make use of, or other factors. Error in d:\nt\com\complus\src\comsvcs\threads\stathread.cpp(271), hr = 80070057: CSTAThread: CoInitializeEx failed


The run-time environment has detected an inconsistency in its internal state. This indicates a potential instability in the process that could be caused by the custom components running in the COM+ application, the components they make use of, or other factors. Error in d:\nt\com\complus\src\comsvcs\threads\stathreadpool.cpp(1230), hr = 8000ffff: CSTAThreadPool: Unable to get bind thread.


The run-time environment has detected an inconsistency in its internal state. This indicates a potential instability in the process that could be caused by the custom components running in the COM+ application, the components they make use of, or other factors. Couldn’t get ApartmentID from STAPool


The COM+ component was configured to use a large number of threads on startup but this was working fine for several years in production. The workaround was to reduce the number of pre-allocated threads, but why was this issue surfacing?


As it turns out, the desktop heap size was the root cause. Each process running on the desktop is treated differently for “Interactive User” vs “Non-interactive User”. Windows reads a registry key to determine how to treat these groups of users:


HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows –> SharedSection = 1024,3072,512

You can read up more on this here http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx


In the settings above, you can see that the heap is set to 3072 KB for Interactive user and just 512 KB for non-interactive users. This heap is used for system resource (e.g. thread handles). The small size prevents dllhost.exe from creating more threads.


By increasing the heap allocated for non-interactive users (from 512 –>1024) the problem was solved.

Leave a Reply

Your email address will not be published. Required fields are marked *