I bumped into this issue at one of my customers that use Python to control a machine through Beckhoff EtherCAT. The Python code communicates with the Beckhoff EtherCAT program using TCP/IP.
They use non blocking sockets like so;
s = select.select([self._socket], [], [], timeout)[0]
if not s:
  raise NoData
self._socket.recv(length)

They also found that the recv occasionally raises a 10035.
I changed the code in to;
s = select.select([self._socket], [], [], timeout)[0]
if not s:
  raise NoData
try:
  buffer_ = self._socket.recv(length)
except socket.error as inst:
  if (gaius.utils.Platform.WINDOWS and 10035 == inst.args[0]) or \
     (gaius.utils.Platform.LINUX and 11 == inst.args[0]):
    raise NoData

So this issue applies also to sockets without timeout, albeit it can be worked around easily. 

Also note that this also applies to Linux as the man page of select states in the BUG section;

Under Linux, select() may report a socket file descriptor as "ready for
reading",  while  nevertheless a subsequent read blocks. This could for
example happen when data has arrived but  upon  examination  has  wrong
checksum  and is discarded. There may be other circumstances in which a
file descriptor is spuriously reported as ready.  Thus it may be  safer
to use O_NONBLOCK on sockets that should not block.

Note that Linux select is not Posix compliant as Posix states;

A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully.

See https://lkml.org/lkml/2011/6/18/76

MSDN select says;

For other sockets, readability means that queued data is available for reading such that a call to recv, WSARecv, WSARecvFrom, or recvfrom is guaranteed not to block.

http://support.microsoft.com/kb/177346 says (for Windows 95);

The Winsock select() API might fail to block on a nonblocking socket and return WSAEWOULDBLOCK as an error code when either send() or recv() is subsequently called. For example, select() may return indicating there is data to read, yet a call to recv() returns with the error code WSAEWOULDBLOCK, indicating there is no data immediately available. Windows NT 4.0 does not exhibit this behavior.


Finally I have 2 questions;

Is this select behavior on Windows 'normal'? Noting that it is not documented. or does it behaves this way due to crippled NIC's or drivers (VMWare)?

Can this behavior be reproduced? I need this for automatic testing. Now these exceptional paths cannot be tested.