Article ID: 184998 - View products that this article applies to.
This article was previously published under Q184998
This article has been archived. It is offered "as is" and will no longer be updated.
An application may write data to or read data from the wrong file if a client has the file open and an error occurs causing the network connection to close.
NOTE: This problem can occur only if the file is a memory-mapped file.
When the connection is closed, the RDR does not check the status of a memory-mapped file.
To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/152734/EN-US/ )How to Obtain the Latest Windows NT 4.0 Service Pack
Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.
The Windows NT Rdr.sys logs on to the server using your user name/password and receives a UID number to reference the session in future requests. The same is true for files. When a file is opened, the server will return a FID to reference the file in future requests. The UID/FID pair is used to establish logon privileges and file permissions in RDR requests. These UIDs and FIDs get recycled each connection. On a new connection, the numbers assigned start at the beginning. The issue is that, when the connection is closed, the RDR is notified and will set a status in the file object so no further I/O can be done on the file. However, the status is not checked in the case of a memory-mapped file. This causes the RDR to use an old UID/FID pair. If the UID/FID pair were in use, the wrong file would be accessed.
Article ID: 184998 - Last Review: October 7, 2013 - Revision: 2.2