Is This Content Helpful?
We're glad to know this article was helpful.
After making several connections to an ArcSDE service, the connection hangs and a gsrvr.exe crash appears on the ArcSDE server. Querying the arcsde service with sdemon -o status hangs. Existing connections continue to function and new connections made by way of direct connect work. Any new application server connections hang and more gsrvr.exe application errors may appear on the server.
"gsrvr.exe - Application Error: The application failed to initialize properly"
Windows has exhausted its 'non-interactive desktop heap'.
The ArcSDE application server, the giomgr, runs as a service on Windows and spawns windows child processes, called gsrvrs. All windows processes run within a desktop, a logical display and container for icons, windows, and threads.
There are two kinds of desktops: interactive and non-interactive. Desktops operate within window stations. Windows services, depending on how they start, usually allocate from the non-interactive desktop heap. The maximum amount of heap memory allocated to noninteractive desktops is limited by a Windows initialization parameter called SharedSection. If you receive the above error message, you may need to change the SharedSection parameter.
A service cannot use more memory than allocated from its non-interactive desktop. When a service exhausts its non-interactive desktop heap, it is unable to create new threads or processes.
When an ArcSDE client connects to an ArcSDE server, that server spawns a gsrvr.exe process. This gsrvr.exe process consumes a small amount of the desktop heap allocated to the ArcSDE service.
If the ArcSDE service starts as a domain account, the gsrvr.exe allocates from the desktop, a non-interactive desktop heap of 512 KB, created for the ArcSDE service.
If the ArcSDE service starts as the LocalSystem account, the gsrvr.exe allocates from the shared desktop, a non-interactive desktop heap of 512 KB, pertaining to all services running as LocalSystem.
If the ArcSDE service starts as the LocalSystem account with 'Allow service to interact with the desktop' enabled, gsrvr.exe allocates from the default desktop an interactive desktop heap of 3 MB.
The size of the interactive and non-interactive desktop heaps is determined by a registry setting under \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems.
Within the 'Windows' string value, there is a 'SharedSection' parameter that by default should read:
The second and third parameters represent the size of the interactive and non-interactive desktop heaps. If terminal services are enabled, a fourth value may be present in this string. Windows enforces a 48 MB maximum desktop memory limit for all desktops. Windows also uses some of this 48 MB pool for its default window station, screensaver, and logon screen. The size of either of these two parameters can be changed to influence the size of the interactive and non-interactive desktop heaps.
Boosting SharedSection’s third parameter limits the total number of desktops that Windows can create, as each non-interactive desktop is larger, thus using more of the global 48 MB pool. However, each service has more memory available to it. Decreasing SharedSection’s third parameter increases the number of desktops Windows can create but decreases the amount of memory each desktop can consume. For example, increasing the third parameter of SharedSection to 2 MB tells Windows to allocate 2 MB to each new non-interactive desktop. Each service that starts up as a domain account receives a new non-interactive desktop of 2 MB. Each service that starts up as the LocalSystem account allocates from the existing 2 MB system non-interactive desktop. In this case, if the server has more than 20 services configured to start up as a domain account, service startup problems may be experienced after the 20th service is initiated. When the 20th service starts, the global 48 MB limit is close to exhaustion.
Each ArcSDE gsrvr.exe consumes approximately 9 KB of memory from the desktop in which it starts. This figure, 9 KB, is only an approximation. It may differ by platform and load. If the default configuration of the ArcSDE instance and the ArcSDE Windows service has not been changed, approximately 55-64 gsrvrs (ArcSDE client connections) can be created before the error occurs. This number also differs if Windows authentication with ArcSDE for MS SQL Server is used.
The solution depends on the ArcSDE platform. Step 1 is applicable to all ArcSDE RDBMS types. Step 2 is applicable to SQL Server sites only. Step 3 is applicable to sites using terminal services on their sde server. All three of these steps pertain only to Windows platforms.
There is currently no method to determine how much memory is in use by a single desktop or how much is left within the global pool. Use oh.exe, a Windows resource kit tool, to monitor how many desktops are in use.