Microsoft KB Archive/126346

{|
 * width="100%"|

-

The information in this article applies to:


 * Microsoft Win32 Device Driver Kit (DDK) for Windows NT, version 3.5

-

SYMPTOMS
Packets between the TCP, UDP, and IP layers are lost.

CAUSE
There appears to be a problem with a race condition between two threads that share a socket where one is closing a socket while the other tries to call recvfrom on the same socket. This causes problems the next time a socket is bound to the same UDP port.

RESOLUTION
The vendor should implement a workaround within the application so that this race condition does not occur.

STATUS
Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

MORE INFORMATION
This Sockets/UDP problem was discovered while testing the TX1000 NCPI driver for Windows NT. Here are some notes showing what appears to be happening:

Thread 1                       Thread 2 - Create DGRAM socket x Bind socket x to: IPADDR = ANY PORT = 1571 Create thread 2 -> RecvFrom on socket x                               ... Packet received on x (recvfrom completes) <---signal main thread Process rec'd packet           wait for main thread to consume buffer Signal buffer available-> RecvFrom on socket x                               ... { repeats many times }

Normal Shutdown Sequence (on Last Packet) -

Packet received on x (recvfrom completes) <---signal main thread Process rec'd packet           wait for main thread to consume buffer Signal buffer available-> Application done               (1) RecvFrom on socket x (2) close socket x                                (3) RecvFrom fails with expected error Thread terminates Usually, events occur in sequence (1, 2, then 3). In this normal case, the socket is cleared correctly, and everything works the next time the application runs.

Shutdown Sequence that Causes Problems (on Last Packet)
                               Packet received on x (recvfrom completes) <---signal main thread Process rec'd packet           wait for main thread to consume buffer Signal buffer available-> Application done (1) close socket x             (2) RecvFrom on socket x                                (3) RecvFrom fails with expected error Thread terminates In this case, the sequence is slightly different. The closesocket function from main thread starts, but does not complete, before thread 2 runs. While thread 1 is suspended awaiting completion of closesocket, thread 2 runs and posts next recvfrom on same socket. The closesocket function completes successfully, and recvfrom fails as in normal case. But the next time the application runs and binds to the same UDP port, the following occurs:  All socket calls (bind, recvfrom) are successful  All incoming packets to that UDP port are discarded before reaching the application -- recvfrom never completes. The following command shows that the "receive errors" count has been incremented once for each incoming packet that was lost: "netstat -s -p udp"

The conclusion is that in this case the socket was not cleaned up properly due to the race condition between the closesocket and the recvfrom functions. Additional query words:

Keywords : kbnetwork kbIP kbNTOS350 kbSDKPlatform kbWinsock kbGrpNet

Version : winnt:3.5

Platform : winnt

Issue type : kbbug
 * }