| Event Information | According to Microsoft:
CAUSE:
This problem occurs because Exchange Server tries to allocate more virtual memory than is available within the process.
The Microsoft Windows NT virtual memory address space is 4 gigabytes (GB) for each process. This implies that no matter how much physical memory is installed, a single process has access to only 4 GB of address space. In addition, Windows NT divides virtual memory into memory that is used by the kernel and memory that is accessible to user-mode (for the application). In standard Windows NT Server 4.0 or Windows 2000 Server, a user-mode application (like Store.exe) has access to 2 GB of virtual memory, and the kernel uses the other 2 GB. In Windows NT 4.0 Enterprise Edition and Windows 2000 Advanced Server, a user-mode application has access to 3 GB of virtual memory, and the kernel gets 1 GB.
All memory allocations for a process come out of the 2 or 3 GB available in the address space. The address space is not empty when a process loads; many elements take up space in it immediately. The code itself is loaded into virtual memory (Store.exe and all the DLLs); a system heap is allocated from this virtual memory; for every thread created, a 1 MB virtual memory allocation (typically) is created for the thread stack, and so on.
The net result is that for an individual process, the process will not be able to allocate a full 2 or 3 GB of virtual memory because some of the memory is in use.
The Exchange Server 5.5 Performance Wizard (Perfwiz) makes calculations about how much virtual memory will be used by using the amount of physical RAM as an indicator. When 2 GB of RAM is physically installed, Perfwiz will assume that it can allocate up to 2 GB of virtual memory for a process. This amount of virtual memory may not be free in a processs address space, so attempting to allocate this much virtual memory may fail.
RESOLUTION:
To resolve this problem, obtain the latest service pack for Exc |
