Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
User32.dll or Kernel32.dll fails to initialize
Article ID: 184802 - View products that this article applies to.
This article was previously published under Q184802
Sometimes an application that is executed by either CreateProcess() or CreateProcessAsUser() fails and you receive one of the following error messages:
Initialization of the dynamic library <system>\system32\user32.dll failed. The process is terminating abnormally.
The failed process returns the exit code 128 or
Initialization of the dynamic library <system>\system32\kernel32.dll failed. The process is terminating abnormally.
The failure is caused by one of the following:
Cause 1The executed process does not have proper security access to the window station and desktop associated with the process.
The lpDesktop member of the STARTUPINFO structure passed to CreateProcess() or CreateProcessAsUser() specifies which window station and desktop is associated with the executed process. The executed process must have proper security access to the specified window station and desktop.
For more information about resolving security problems with window stations and desktops, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/165194/ )CreateProcessAsUser() windowstations and desktops
Cause 2The system has run out of desktop heap.
Every desktop object on the system has a desktop heap associated with it. The desktop object uses the heap to store menus, hooks, strings, and windows. The system allocates desktop heap from a system-wide 48-MB buffer. In addition to desktop heaps, printer, and font drivers also use this buffer.
Desktops are associated with window stations. A window station can contain zero or more desktops. The size of the desktop heap allocated for a desktop associated with a window station can be changed in the following registry value.
Note Microsoft does not recommend to use /3GB switch. The /3GB switch is specified in the boot.ini file.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\WindowsThe default data for this registry value will look something like the following (all on one line):
The numeric values following "SharedSection=" control how desktop heap is allocated. These SharedSection values are specified in kilobytes. There are separate settings for desktops associated with interactive and noninteractive window stations.
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16
Note If the SharedSection values in the registry are modified, the system must be restarted before the changes take effect.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/322756/ )How to back up and restore the registry in Windows
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. By default, there are three desktops created in Winsta0 by the system:
If only two SharedSection values are present, you can add ",512" as the third value to specify the size of the desktop heap for desktops created in noninteractive window stations.
Every service process executed under a user account will receive a new desktop in a noninteractive window station created by the Service Control Manager (SCM). Thus, each service executed under a user account will consume the number of kilobytes of desktop heap specified in the third SharedSection value. All services executed under the LocalSystem account with Allow Service to Interact with the Desktop not selected share the desktop heap of the "Default" desktop in the noninteractive service windows station (Service-0x0-3e7$).
The total desktop heap being used in the interactive and noninteractive window stations must fit into the 48-MB system-wide buffer.
Decreasing the second or third SharedSection values will increase the number of desktops that can be created in the corresponding window stations. Smaller values will limit the number of hooks, menus, strings, and windows that can be created within a desktop. On the other hand, increasing the second or third SharedSection values will decrease 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 a desktop.
Because the SCM creates a new desktop in the noninteractive window station for every service process that is running under a user account, a larger desktop value for the third SharedSection value will reduce the number of user account services that can run successfully on the system. The minimum value that can be specified for the second or third SharedSection value is 128. Any attempt to use a smaller value will default to 128.
Desktop heap is allocated by User32.dll when a process is in need of user objects. If an application is not dependent on User32.dll, it will not consume desktop heap.
Note In Windows Server 2003, the specific event is logged in the system event log when one of the following conditions is true:
Article ID: 184802 - Last Review: February 26, 2008 - Revision: 11.3