Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
IIS runs out of work items and causes RPC failures when connecting to a remote UNC path
Article ID: 221790 - View products that this article applies to.
This article was previously published under Q221790
We strongly recommend that all users upgrade to Microsoft Internet Information Services (IIS) version 7.0 running on Microsoft Windows Server 2008. IIS 7.0 significantly increases Web infrastructure security. For more information about IIS security-related topics, visit the following Microsoft Web site:
http://www.microsoft.com/technet/security/prodtech/IIS.mspxFor more information about IIS 7.0, visit the following Microsoft Web site:
In a Web farm environment, where one or more IIS Web servers are using a remote Windows NT or Windows 2000 file server to hold the content for the Web site (for example, the home directory or the virtual directories for the Web site are mapped to a UNC path), the IIS Web servers may run out of available work contexts at the redirector level. When this happens, the following symptoms can occur on your IIS Web servers:
Event ID 101 on IIS server:
The server was unable to add the virtual root '/<virtual dir name>' for the directory '\\<servername>\<share>\' due to the following error: The network BIOS command limit has been reached. The data is the error code. For additional information specific to this message please visit the Microsoft Online Support site located at: http://search.support.microsoft.com/search/?adv=1.
The server is running out of work contexts for a particular client. In Windows 2000, there is a hard-coded upper limit of 125 work contexts for all types of clients (Windows NT, Windows 95, and Windows 98).
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
(http://support.microsoft.com/kb/294418/ )Comparison of 32-bit and 64-bit memory architecture for 64-bit editions of Windows XP and Windows Server 2003
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
After you apply the hotfix described in Q271148, the upper limit for MaxMpxCt (the server setting) changes from 125 to 65,535, and on the client, the upper limit for MaxCmds (the client setting) changes from 255 to 65,535.
Additionally, the maximum number of concurrent SMB sessions that can be opened between the client and the server is the lower of MaxCmds and MaxMpxCT . However, if the connecting client is a Windows 95 or Windows 98 client, then the effective value of MaxMpxCt for that client is limited to 125.
These limits become important when you use IIS in a Web-farm scenario where the content for the Web sites is stored on a remote UNC share, because IIS uses the ReadDirectoryChangesW API to receive file change notifications. This is done so that if files change, IIS can un-cache the old files, and then re-read the new files from the disk or share. When you use a UNC path as the home directory, a persistent SMB connection remains open between the IIS server and the file server, which consumes a work context. If the directory structure is large enough, it is possible to run out of work contexts and encounter the symptoms listed previously.
A computer running IIS can have multiple virtual directories or Web sites pointing to shares on another Windows NT Server computer. The ASP Directory Monitor uses the ReadDirectoryChangesW API to monitor for any changes to those directories on the other server. Each pending ReadDirectoryChangesW requires a work context on the server, and there is only a limited number of work contexts available.
The number of work contexts is passed from the server to the client when the SMB level is negotiated. The redirector on the client keeps an internal count of the number of work contexts that it is using on the server. The default number of work contexts is 50.
The number of work contexts is limited to keep the server process from consuming all non-paged pool memory. This can be raised, but then there is a limit to how many work contexts a particular client can consume.
This problem is not limited to IIS. Windows NT Explorer uses the same mechanism to monitor for directory changes.
Note This issue does not occur on computers that are running an x64 version of Windows Server 2003. For more information about the MaxWorkItems and MaxMpxCT settings, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/232476/ )Terminal Server client connections and logon limited by MaxWorkItem and MaxMpxCt values
(http://support.microsoft.com/kb/271148/ )MaxMpxCt and MaxCmds limits in Windows 2000
Article ID: 221790 - Last Review: July 3, 2008 - Revision: 7.1