Hi there, We are seeing a recurrence of an issue regarding Complus errors in our event logs that manifests itself in our websites as HTTP/1.1 Server Too Busy errors, sporadically throughout the domains that we have on this server. Also, if the website is up, then we see that attempting to upload files to the website through our ASP.net upload component fails. In addition to this, our databases are dynamically generated and the database loses the lock file, I don't know the reason for this, killing the website in question. The errors that we are getting are: 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:\w7rtm\com\complus\src\comsvcs\threads\activityworkqueue.cpp(403), hr = 80070008: Failed to initialize object context. 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:\w7rtm\com\complus\src\comsvcs\threads\activityworkqueue.cpp(551), hr = 80070008: Failed to configure new context 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:\w7rtm\com\complus\src\comsvcs\threads\staactivity.cpp(812), hr = 8000ffff: CSTAActivity: Failed to enqueue work. 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:\w7rtm\com\complus\src\comsvcs\threads\activityworkqueue.cpp(364), hr = 8000ffff: CActivityWorkQueue: Failed to bind queue. I have only found one other example of this issue on the internet and that wasn't really much help resolving the issue. See below link. http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2008/Q_27030317.html

We do, as seen on similar search results on the internet, seem to be running into desktop heap problems. With a non-interactive desktop heap setting of 3072 KB we are seeing 65% usage after 40 minutes of uptime, and that usage figure is rising. The server is hosting ~400 domains containing Classic ASP sites with ASP.NET components bolted on.

Hi, According to my research, modify the desktop heap registry key might help. For your information, the following registry key can be tweaked to increase the amount of desktop heap. Please double the second and third numeric values, so the SharedSection numbers look like this: haredSection =1024,6144,1024 as a test. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows\ SharedSection=1024,3072,512 The first SharedSection value (1024) is the shared heap size common to all desktops. This includes the global handle table, which holds handles to windows, menus, icons, cursors, and so forth, and shared system settings. It is unlikely that you would ever need to change this value. The second SharedSection value (3072) is the size of the desktop heap for each desktop that is associated with the "interactive" window station <WinSta0>. User objects like hooks, menus, strings, and windows consume memory in this desktop heap. It is unlikely that you would ever need to change this second SharedSection value. Each desktop that is created in the interactive window station uses the default 3072-KB desktop heap. The third SharedSection value (512) is the size of the desktop heap for each desktop that is associated with a "noninteractive" window station. If this value is not present, the size of the desktop heap for noninteractive window stations will be same as the size specified for interactive window stations (the second SharedSection value). If the issue persists, I recommend you submit a new question in the ASP.NET Forums for further assistance to narrow down the root cause. Please refer to: ASP.NET Forums http://forums.asp.net/ Thanks for your understanding. Best Regards, Nina Forum Support Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Okay, so, with the help of my hosting company I think that we have gotten to the bottom of this. Our server is a Server 2008 R2 so our default values are HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows\ SharedSection=1024,20480,768 We had changed this from 768 for the non-interactive desktop pool to 3072. However, to identify the issue we needed to view the desktop heap which is a little more complex on Win 2k8r2 servers. Install the kernel debugging tools from http://msdn.microsoft.com/en-us/windows/hardware/gg463012 Run at the command line: bcdedit /debug on You will now need to reboot Then you need to set the symbols path (there are a few differing ways to do this so you'll have internet search this for your preferred method) You then need to run the following command from the command line to display the desktop heap (note that you will have to change your symbols directory to wherever you saved it to, and also, yes include the double quotations): "C:\Program Files\Debugging Tools for Windows (x64)\kd.exe" -y c:\symbols -kl -c "!dskheap;q" You will now get a run down of your desktop heap pools and usage. We found that our 3072 for the single heap running all our websites was too small, so we changed the value back to the default of 768 and changed the following value in in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WAS\Parameters\UseSharedWPDesktop = 1 We changed this value to 0 and rebooted. This had the effect of giving every website that we had a desktop heap of its own, and the largest usage that we have seen of this is about 7% of the 768 allocation. We now have 400 happy domains.

Hi, Glad to hear that the issue has been resolved. Thanks for your feedback and sharing. Your time and efforts are appreciated. By the way, the value I have listed 1024,3072,512 are for Windows Server 2003, sorry for the inaccuracy, meanwhile, the solution is similar in Windows Server 2008. Best Regards, NinaPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.