We are sometimes asked about limitations as to the number of concurrent services that can be run under FireDaemon Pro. FireDaemon Pro imposes no limit on the number of services installed; however CPU, RAM and non-interactive window station desktop heap play important roles in determining the actual limit as to the number of interactive processes that can be run under FireDaemon Pro control that can be run on a single machine on Session 0.
If you are running a large number of interactive/non-interactive services under FireDaemon Pro, you may experience various errors where services fail to start. You might see errors similar to "FireDaemon.exe - Application Error: The application failed to initialize properly (0xc0000142)" in the Windows Event Log or the service just starts and then stops with the error "Not enough quota is available to process this command" in the FireDaemon Pro debug log.
Other symptoms include:
You try to open an application but it refuses to load or it starts to load and then it disappears
You try to open or use an application but you get an "Out Of Memory" error message
One of your running applications inexplicably quits
When you right-click on your application, nothing happens! The command menu refuses to pop-up
Your web browser simply refuses to load any more windows or tabs
Your application is missing some menus or toolbars
You get the following error messages :
Initialization of the dynamic library <system>\system32\user32.dll failed. The process is terminating abnormally. Initialization of the dynamic library <system>\system32\kernel32.dll failed. The process is terminating abnormally.
Whilst at first this might seem like a problem with FireDaemon Pro, it is actually because the default size of the non-interactive window station desktop heap is too small.
The desktop heap is a section of memory reserved for the storage of menus, hooks, strings and windows. This heap is allocated memory from a fixed 48MB system buffer that is also used to store printer data and font drivers.
By default, Windows allocates a total of 4.5MB of memory for the desktop heap. But if the system ever runs out of space in the desktop heap, it won't be able to load new windows. It's as simple as that!
In order to fix this you need to increase the size of the desktop heap for each desktop that is associated with a "noninteractive" window station. Please note that this fix requires a direct modification to the Windows Registry. If you are not familiar with the Registry, Registry editors and editing keys and values then you should probably not attempt this. For a complete technical discussion of this registry modification and its ramifications please refer to this these two articles:
Desktop Heap Part 1
Desktop Heap Part 2
Before making ANY changes ensure you completely backup your machine. Further, you should definitely read and understand those articles prior to making these modifications:
- Start the registry editor: Start/Run/regedt32
- Find the value: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows
- Modify the third value of the SharedSection to 4096 (nb. you might find the first two values differ on later versions of Windows):
- Reboot the machine
The first value of the SharedSection is the shared heap size, common to all desktops. It's used to store the global handle table and shared system settings. By default, it's set to 1024KB. You generally do not need to modify this value.
The second value is the desktop heap size for each desktop associated with the "interactive" window station. It's used to store user objects like hooks, menus, strings and windows. By default, it's set to 3072KB. The more users log into the system, the more desktops are created. Consequently, the total "interactive" desktop heap size will increase to reflect the number of desktops created. But each desktop will only have an "interactive" desktop heap of 3072KB. Note that one more recent versions of Windows (eg. Windows 10), this value is now 20480KB.
The third value is the desktop heap size for each desktop associated with the "non-interactive" window station. By default, it's set to 512KB (or 768KB on Windows 10). If this value is not present, the size of the "non-interactive" window station will be the same as that of the "interactive" window station.
Every service process created under a user account will be given a new desktop in a "non-interactive" window station created by the Service Control Manager (SCM). Therefore, each of these services will consume the amount of desktop heap, as specified in the third SharedSection value.
The total desktop heap used in both interactive and non-interactive window stations must fit into the 48MB system-wide buffer.
Consequently, decreasing the second or third SharedSection values will increase the number of desktops that can be created. But it will reduce the number of hooks, menus, strings and windows that can be created within each desktop.
On the other hand, increasing the second of third SharedSection values will reduce the number of desktops that can be created. But it will increase the number of hooks, menus, strings and windows that can be created within each desktop.
In addition, increasing the third SharedSection value will reduce the number of user account services that can run successfully on the system. To solve the problem we are facing, just increase the desktop heap for "interactive" window stations, which is the second SharedSection value. By default, it's set to 3072KB. Try increasing it to 4096KB or to a higher value that addresses your problem. But please note that increasing this value will reduce the number of desktops that can be created.
Reboot the system for the changes to take effect. Some experimentation will be required to fine tune the values to your installation.
Microsoft also supplies a Desktop Heap Monitoring Tool. Use it to determine whether your desktop heap is exhausted.
If you are running the tool remotely, ensure you connect to the shadow console or switch to Session 0 FIRST before running the tool.
Related but dated Microsoft Knowledgebase article here.