Consultor Eletrônico

Status: Verified

SYMPTOM(s):

Numerous errors occur when nth user attempts to connect to database

GPF: _mprosrv.exe this program failed to inistailised properly 0xc0000142 Click on OK to terminate the application

user32.dll initialization failure due to out of memory

Initialization of the dynamic link library USER32.dll failed. The process is terminating abnormally

Error 1157 when nth user tries to connect

Broker could not spawn a server. (1157)

Error 1890 when nth user tries to connect

BROKER: Could not spawn a server. (1890)

Remote connections refused after some clients are able to connect

Machine can't spawn any more Progress processes

Setting "Allow Service to Interact With Desktop" in the Services > ProService tab, results in one window for each remote connection appearing on the Server which is not acceptable to System Administrator.

Using ProControl or Progress Explorer on Server to start databases

Task Manager shows ample free memory UNTIL client connection's accumulate

FACT(s) (Environment):

Windows 2000
Windows 2003
Progress 9.x
OpenEdge 10.x

CAUSE:

In the shared memory networking model of PROGRESS, the broker was trying to spawn a server and the spawned process died before it had a chance to notify the broker that it was alive. This can happen for any number of reasons - the host machine could be out of available processes, or available ports or network connection points, or the shared memory versions between broker and server don't match, or there are not enough semaphores for the new server.

In this case, it is a resource issue. It occurs because there are differences in the way heap allocation occurs when you run Service as a background Service as opposed to running it as an interactive Service.

A background Service dynamically allocates memory so that memory-hungry processes can be handled. It is possible however, that the system will run out of memory because of the processes taking up available memory. This value can be re-set to a certain size (explained later in this solution).

By default, the interactive Service runs with a heap size of 1024, which is a fixed number set in the Windows Registry.

Heap allocation is handled by the Session Manager (the manager of the different subsystems) which is configured in the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\
SubSystems\Windows

This key has a very long string value, including the section:

SharedSection=1024,3072

Where:

The first value is the heap size for interactive service processes and is used when "Allow interact with desktop" is enabled. This includes the global handle table. It defines the heap size common to all desktops. It is unlikely that this value would ever need to be changed.

The second value, is the system-wide heap size. It controls the size of the desktop heap. It is a static value that is used to prevent memory hungry applications from consuming too many resources. Setting this value too high would decrease performance, it should only be increased to allow all the needed applications to run successfully (if required).

The third number (hidden on NT) is the dynamically changeable heap size that the non-interactive desktop services (background processes) will use. Adding or amending this value is what this solution is primarily concerned with, to assist in addressing an environment where there are many databases and/or AppServers launched through ProControl or Progress Explorer.

By default, this value is not set in Windows NT. When this value is not specified, it will use the same desktop heap size as the system-wide heap size which is defined by the second SharedSection value. This means that Windows NT will assign a heap size as required. Since the Windows 2000 release (and later Windows 2003), this is set value to 512 by default, because 3072K was considered too high for non-interactive processes and 512 was deemed to handle the majority of situations by Microsoft.

However, it is possible that this Windows feature can cause services to generate an error on startup and affect performance while running as more client sessions connect. This is because one of the services needs more heap than currently allocated (say 512Kb) which is typical of services that spawn processes as each process running in the service's Windowstation has a heap overhead. Typically, the error displays the message:

'user32.dll initialization failure due to out of memory'

or

the 0xC0000142 message, which means 'DLL Initialisation Failure' and is raised when DllMain() returns false (?) - referring to user32.dll in this case.

FIX:

Microsoft recommends fixing the size of the hidden desktop heap (see Microsoft Knowledge Base Q142676). The Microsoft fix suggests the value of 512, however it has been found that this value may not be sufficient for Windows 2000/2003 servers that run a large number of databases or AppServers. For Appservers, or a large number of databases, set the dynamic heap size to 1024 (or greater, through tuning).

To set dynamically changeable heap size (third value mentioned above), edit the following string in the Server registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\SubSystems\Windows

SharedSection=1024,3072,1532

Then restart the Server to make the registry change take effect and watch the Task Manager performance to gauge the impact.

The non-interactive desktop (third parameter) can be increased to any value provided that:
(number_of_services_not_localsystem + 1) * third_parameter + second_parameter + first_parameter ~< 49152.

If you have for example Service1 running as domX/userY and Service2 running as domX/userY, this counts as TWO number_of_services_not_localsystem.

** As always, when changing registry settings, backup the registry first. **