This article was previously published under Q189171
This article has been archived. It is offered "as is" and will no longer be updated.
When you run a WinSock application on a Windows NT computer, one or more ofthe following symptoms may occur:
If a WinSock 1.1 application sets the SO_OPENTYPE sockopt, or a WinSock 2.0 application does not specify WSA_FLAG_OVERLAPPED to WSASocket(), the socket handle returned by WSPSocket() is supposed to be non-overlapped, and usable by ReadFile/Writefile etc. If a layered service provider (LSP) is installed, the non-overlapped flag is ignored and all sockets created are overlapped. This causes any application that uses file I/O calls to hang or fail.
When sending a 4 KB packet over NetBEUI followed by a receive packet, the 4 KB send returns success, but does not make it to the remote end and the subsequent receive fails with c000013b or error code 1726 (RPC_S_CALL_FAILED). This happens with or without security, and only with buffers greater than or equal to 4 KB.
When running a script with the WinSock function AfdAllocateMdlChain, when WSASend bufferPointer is set to NULL and/or bufferLength is set to zero (0), WSARecv and WSARecvFrom return SUCCESS but report that they transferred zero bytes even though there is data available to be received. This call should not succeed with the amount of data available to be transferred. WSASend and WSASendTo return WSAEFAULT, which is correct behavior.
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.