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 aclient has the file open and an error occurs causing the network connectionto 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 amemory-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 theMicrosoft Knowledge Base:
152734 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/passwordand receives a UID number to reference the session in future requests. Thesame is true for files. When a file is opened, the server will return a FIDto reference the file in future requests. The UID/FID pair is used toestablish logon privileges and file permissions in RDR requests. These UIDsand FIDs get recycled each connection. On a new connection, the numbersassigned start at the beginning. The issue is that, when the connection isclosed, the RDR is notified and will set a status in the file object so nofurther I/O can be done on the file. However, the status is not checked inthe case of a memory-mapped file. This causes the RDR to use an old UID/FIDpair. If the UID/FID pair were in use, the wrong file would be accessed.