"The run-time environment has detected an inconsistency in its internal state." Over time, on a number of web servers (Windows Server 2003, IIS 6.0) with many running application pools, I noticed many - at first inexplicable - COM+ error messages. This may be caused by something known as desktop heap exhaustion.
With many application pools, every w3wp.exe worker process takes a piece of the desktop heap for non-interactive users, 512 KB by default. When it is full, no more threads can be started and COM+ throws inconsistency errors. Doubling the third value of SharedSection in the registry to 1024 and rebooting solved it.
I originally wrote this post in 2008 for Windows Server 2003 and IIS 6.0, both long out of support. The registry values below are the Windows Server 2003 defaults.
The COM+ error messages I found all started with "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." and ended with one of these errors:
Error in d:\nt\com\complus\src\comsvcs\threads\stathread.cpp(285), hr = 80070008: CSTAThread: CoGetApartmentID failed
Error in d:\nt\com\complus\src\comsvcs\threads\staactivity.cpp(805), hr = 8000ffff: CSTAActivity: Failed to enqueue work.
Error in d:\nt\com\complus\src\comsvcs\threads\activityworkqueue.cpp(364), hr = 8000ffff: CActivityWorkQueue: Failed to bind queue.
Error in d:\nt\com\complus\src\comsvcs\threads\stathreadpool.cpp(1081), hr = 8000ffff: CSTAThreadPool: Unable to get bind thread.
Error in d:\nt\com\complus\src\comsvcs\threads\stathread.cpp(272), hr = 80070057: CSTAThread: CoInitializeEx failedDesktop Heap Exhaustion
A quick Google search brought me to "Vapor Blog" (Wayback Machine), an MVP blog, where he described the same issue. It turns out that the desktop heap size is the cause. By default, it is set to 512 KB and is used for all non-interactive users, including the w3wp.exe worker processes. This value is set in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows -> SharedSection = 1024,3072,512You can read more in the Desktop Heap Overview on the Ntdebugging Blog.
Desktop heap size
The fix is to increase the desktop heap size for non-interactive users.
As you can see, 3072 KB is available for the interactive user and 512 KB for non-interactive users, in which thread handles and the like are stored. When many application pools are running, and therefore many non-interactive users are logged on, the 512 KB heap fills up and no more threads can be started.
After doubling the heap for non-interactive users (512 -> 1024) the problem was solved. This registry change only becomes active after a reboot.
Still managing IIS 6.0 application pools? See how to stop, start or recycle application pools in IIS 6.0 and how to start all stopped application pools in IIS 6.0.