Windows 2000-Based Exchange Server May Run Out of Virtual Address Space (267056)
The information in this article applies to:
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Professional
This article was previously published under Q267056 IMPORTANT: This article contains information about modifying the registry. Before you
modify the registry, make sure to back it up and make sure that you understand how to restore
the registry if a problem occurs. For information about how to back up, restore, and edit the
registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows Registry
SYMPTOMS
When the Microsoft Exchange Store service that is running on your Windows 2000-based computer finds most of its threads blocked, it may start to create new threads, causing your computer to either fragment or run out of virtual address space.
CAUSE
This problem occurs because of excessive contention in NtLmUserContextLock, which is located outside of Remote Procedure Call (RPC). However, this contention causes the number of RPC threads to increase significantly for the computer to remain responsive.
RESOLUTIONWARNING: If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you can solve
problems that result from using Registry Editor incorrectly. Use Registry Editor at your own
risk.
To resolve this problem, obtain and install Service Pack 1 (SP1) for Windows 2000. Then, configure the three registry values listed later in this article to modify this behavior. NOTE: If you use values that are inappropriate for your computer, your computer may become unresponsive or seem to stop responding (hang). Also, incorrect values may cause your computer to return error messages under heavy load. Microsoft recommends that you contact Microsoft Product Support Services for assistance in configuring these values.
Use Registry Editor (Regedt32.exe) to view the following registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Image File Name\RpcThreadPoolThrottle
where Image File Name is the name of the program file. For example, in D:\Wmsg\Rtsvr.exe, the image file name is Rtsvr.exe.
Add the following registry values:
Value name: ProrateFactor
Value type: REG_DWORD
Value data:
Description: Additional delay in milliseconds that each new thread waits.
Value name: ProrateMax
Value type: REG_DWORD
Value data:
Description: Limit on how long the creation of a new thread is delayed.
Value name: ProrateStart
Value type: REG_DWORD
Value data:
Description: The number of RPC thread pool threads after which thread delay starts.
Note that there are no default values. If you do not configure these registry values, the RPC run-time uses the default behavior listed earlier in this article.
After you configure these registry values, RPC delays the creation of new threads after the limit is reached.
STATUSMicrosoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. MORE INFORMATION
In Windows 2000, requests that are received by an RPC server are serviced by a pool of threads. The RPC run-time monitors the state of these threads; if a thread becomes temporarily blocked and there are no available threads in the pool, it creates another thread to prevent the server from becoming unresponsive. Generally, this behavior is acceptable, but a virtual-address-space-intensive program such as the Exchange store that creates many threads can cause the virtual address space to become fragmented.
Sometimes, contention in NtLmUserContextLock can cause all RPC thread pool threads to become blocked, and RPC has to start new threads to keep the service responsive. Occasionally, even when RPC has hundreds of threads available in the thread pool, all of them can become blocked in NTLM, causing RPC to start even more threads. In such situations, it may be preferable to delay processing of new requests to create the opportunity for existing threads to come back quickly to process these new requests.
| Modification Type: | Minor | Last Reviewed: | 9/23/2005 |
|---|
| Keywords: | kbHotfixServer kbQFE kbbug kbenv kbfix KB267056 |
|---|
|