COM+ The run-time environment has detected an inconsistency in its internal state.
Posted
Mon, Apr 7 2008 13:52
by
vapordan@hotmail.com
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.