IIS runs out of work items and causes RPC failures when connecting to a remote UNC path
- IIS appears to stop responding. If you examine a process dump of Inetinfo.exe, you will see that a large number of worker threads are waiting to retrieve content from the remote file share. In a Performance Monitor log, IIS appears largely idle during this time, as the majority of the threads are in a wait state, waiting to access the remote server.
- On the local desktop of one of the IIS Web servers, if you attempt to use the client redirector to access the remote file share through Network Neighborhood or My Network Places, or through Windows Explorer, it appears to stop responding indefinitely. If a UNC path is mapped to a local drive letter in Windows Explorer, and Windows Explorer is open, it appears to stop responding as well. This can give the appearance that the entire operating system has stopped responding, when in fact it has not.
- The following error messages may occur when the maximum number of work contexts are exhausted on a particular server: RPC 1792 - The remote procedure call failed and did not execute.Netlogon 5719 - Unable to find domain controller.These error messages may occur when you attempt to make any additional RPC connections to a server when the maximum number of work contexts is reached.
- The network BIOS command limit has been reached.
- The following event ID message is logged:
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.
- If you are running Windows 2000, install the post-SP1 hotfix described in the following Microsoft Knowledge Base article to both the IIS servers and the file server: 271148 MaxMpxCt and MaxCmds limits in Windows 2000
- Increase the values of MaxCmds on the IIS Servers and MaxMpxCT on the File Server by using the following registry scripts:
- Save the following registry script as Client.reg, and then run it on the IIS servers: Windows Registry Editor Version 5.00
- Save the following registry script as Server.reg, and then run it on the file server: Windows Registry Editor Version 5.00
- Save the following registry script as Client.reg, and then run it on the IIS servers:
- Restart all of the IIS servers and the file server for these changes to take effect.
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:
Article ID: 221790 - Last Review: 07/03/2008 16:56:15 - Revision: 7.1
- kbhotfixserver kbqfe kbbug kbpending KB221790