Appendix C: Error Reference Appendix C: Error ReferenceThe Windows Sockets specification describes error definitions for each function, but it does not provide any short error text for an application to use at runtime to describe a problem to a user. The Windows Sockets API does not have analogs for the Berkeley perror() and herror() functions that take the error value as input, and output the (short) text of each error value (we show the code for an alternative in Chapter 10, "Support Routines"). Since Windows Sockets is practically a clone of Berkeley Sockets, and the rule of thumb is "when in doubt, defer to Berkeley", we can adopt the Berkeley Software Distribution error text as our own.
Among other things, that is exactly what we've done here. We took the text of the errno manual page in BSD 4.3, filled in gaps and embellished, completing the information. The Windows Sockets errors are listed in alphabetical order below (they're cross-referenced in a list in numerical order further below). Every error description contains at least:
Other information varies between different errors. Some of the types of things you will find under some errors are:
Although most of this appendix is for application developers, the User suggestions contain information that end-users and application support personnel might also find useful when an application fails. We suggest local configuration changes that might remedy the problem, and network and server conditions that might be the cause. The errors that have User suggestions are all the same ones in the "User-fixable errors" list above.
The WinSock description and TCP/IP scenario contain detailed descriptions of the errors, which also describe possible cause and imply a possible remedy. For more information on debugging problems, see Chapter 13, "Debugging."
Eight of the forty-six functions in the Windows Sockets API are not referenced in any of the "WinSock function" lists in the following detailed descriptions. The v1.1 WinSock specification doesn't list any errors for these functions. Specifically, these error-less functions are the byte order functions ( htonl(), htons(), ntohl(), and ntohs()), the address manipulation functions (inet_addr(), and inet_ntoa), WSAGetLastError() and WSAIsBlocking().
Some of these functions cannot fail, which explains their absence from the error list below. Of the two that can fail, neither of them set an error value you can retrieve from WSAGetLastError() (refer to Chapter 10, "Support Routines" for more information on any of these error-less functions).
There are a total of fifty unique WinSock error values. The values for WSANO_DATA and WSANO_ADDRESS (11004) are duplicates, so we don't count one of them.
The v1.1 WinSock specification only ascribes thirty-three of the fifty errors to any of the WinSock functions in the v1.1 for Windows Sockets specification. Thirteen errors have "<none>" next to the list of WinSock functions that can produce them. That's about one-quarter of the error values that aren't even used!
Some of these neglected error values are among those mentioned earlier that provide "finer resolution" on different WinSock implementations. In some cases these errors are platform dependent. For instance, you might get WSAEBADF in place of WSAENOTSOCK on a system that provides some socket and file handle equivalency. But most of these function-less errors are simply out of place; they are inappropriate to the Windows Sockets API as it exists in the v1.1 specification. You are unlikely to encounter them. But that's not to say you shouldn't still be prepared.
As we pointed out earlier, your application should be ready to encounter any error at any time. Although the specification doesn't list an error for a function, it does allow for it. In fact, on occasion you can benefit if the WinSock implementation returns these other errors. The occurrence of an unlisted error can provide extra detail. This can help you (or your support staff) to zero-in on what's wrong when your application runs into a problem.
Some WinSock implementation use these errors inappropriately, but they have a particular meaning. They signal unusual error conditions for which there's no WinSock error equivalent. Unfortunately, to find out what these errors mean you need to contact that WinSock provider.
<no macro available> (0) No error
WSABASEERR (10000) No error
Berkeley Description: no equivalent.
WinSock description: No error.
Detailed description: There's at least one WinSock implementation that will occasionally fail a function and report this as the error value, even though the function succeeded. You should simply ignore this error when it occurs.
WinSock functions: <none>
WSAEACCES (10013) Permission denied.
Berkeley description: An attempt was made to access a file in a way forbidden by its file access permissions.
Microsoft C description: Permission denied. The file's permission setting does not allow the specified access. This error signifies that an attempt was made to access a file (or, in some cases, a directory) in a way that is incompatible with the file's attributes. For example, the error can occur when an attempt is made to read from a file that is not open, to open an existing read-only file for writing, or to open a directory instead of a file. Under MS-DOS versions 3.0 and later, EACCES may also indicate a locking or sharing violation. The error can also occur in an attempt to rename a file or directory or to remove an existing directory.
WinSock description: Same as Berkeley.
Detailed description:
send() & sendto(): the requested address is a broadcast address, but the appropriate
flag was not set (i.e. you didn't call setsockopt(SO_BROADCAST)).
WinSock functions: send(), sendto()
Additional functions: setsockopt() and any function that takes a socket (or file handle) as an input parameter.
WSAEADDRINUSE (10048) Address already in use.
Berkeley description: Only one usage of each address is normally permitted.
WinSock description: Same as Berkeley. The "address" they refer to, typically refers to the local "socket name", which is made up of the 3-tuple: protocol, port-number and IP address.
Developer suggestions: Don't call bind() in a client application. Instead, let the network system assign the local port (very few application protocols require a client to bind to a specific port number or port number range). Alternately, you could call setsockopt(SO_REUSEADDR) to allow duplicate local addresses in a single application, but this is a kludgy approach (i.e. we don't recommend it).
User suggestions: Don't try running two of the same types of server applications on the same machine. For instance, this error will occur if you try to run two applications that have FTP servers. In this case, the 2nd application will fail with WSAEADDRINUSE.
Winsock functions: bind(), connect(), listen(), FD_CONNECT
WSAEADDRNOTAVAIL (10049) Cannot assign requested address.
Berkeley description: Normally results from an attempt to create a socket with an address not on this machine.
WinSock description: Partly the same as Berkeley. The "address" it refers to is the remote socket name (protocol, port and address). This error occurs when the sin_port value is zero in a sockaddr_in structure for connect() or sendto().
In Berkeley, this error also occurs when you are trying to name the local socket (assign local address and port number) with bind(), but Windows Sockets doesn't ascribe this error to bind(), for some unknown reason.
Developer suggestions: Assume bind() will fail with this error. Let the network system assign the default local IP address by referencing INADDR_ANY in the sin_addr field of a sockaddr_in structure input to bind(). Alternately, you can get the local IP address by calling gethostname() followed by gethostbyname().
WinSock functions: connect(), sendto(), FD_CONNECT
Additional functions: It seems odd that the v1.1 specification doesn't ascribe this error to the function bind().
WSAEAFNOSUPPORT (10047) Address family not supported by protocol family.
Berkeley description: An address incompatible with the requested protocol was used. For example, you shouldn't necessarily expect to be able to use NS addresses with ARPA Internet protocols.
WinSock description: Same as Berkeley, and then some. The error occurs with the socket() function, which takes the socket type (protocol) and address family as input parameters.
It also occurs with functions that take a socket handle and a sockaddr structure as input parameters. A socket already has a type (a protocol), and each sockaddr structure has an address family field to define its format. A function fails with WSAEAFNOSUPPORT if the address family referenced in sockaddr is not compatible with the referenced socket's protocol.
This error apparently also takes the place of WSAEPFNOSUPPORT (which means "protocol family not supported"), since that error is not listed for socket() in the v1.1 WinSock specification.
WinSock functions: bind(), connect(), sendto(), socket(), FD_CONNECT
See also: WSAEPROTOTYPE
WSAEALREADY (10037) Operation already in progress.
Berkeley description: An operation was attempted on a non-blocking object that already had an operation in progress.
WinSock description: Unlike Berkeley Sockets, in WinSock WSAEALREADY means that the asynchronous operation you attempted to cancel has already been canceled. However, there's little distinction between WSAEALREADY and WSAEINVAL since a WinSock DLL cannot tell the difference between an asynchronous operation that has been cancelled and one that was never valid.
WinSock functions: WSACancelAsyncRequest()
Additional functions: Berkeley sockets connect() returns this error on subsequent calls, after an initial call on a non-blocking socket. However, some WinSocks fail with WSAEINVAL you call connect() a second time (or subsequent) on a non-blocking socket.
WSAEBADF (10009) Bad file descriptor.
Berkeley description: A file descriptor argument was out of range, referred to no open file, or a read (write) request was made to a file that was only open for writing (reading).
Microsoft C description: Bad file number. The specified file handle is not a valid file-handle value or does not refer to an open file; or an attempt was made to write to a file or device opened for read-only access (or vice versa).
WinSock description: No equivalent in WinSock. However, because a BSD socket is equivalent to a file handle, some Windows Sockets platforms provide some file handle and socket equivalency. In this case, the WSAEBADF error might mean the same as a WSAENOTSOCK error.
WinSock functions: <none>
Additional functions: any function that takes a socket (or file handle) as an input parameter
See also: WSAENOTSOCK
WSAECONNABORTED (10053) Software caused connection abort.
Berkeley description: A connection abort was caused internal to your host machine. The software caused a connection abort because there is no space on the socket's queue and the socket cannot receive further connections.
WinSock description: Partly the same as Berkeley. The error can occur when the local network system aborts a connection. This would occur if WinSock aborts an established connection after data retransmission fails (receiver never acknowledges data sent on a datastream socket).
TCP/IP scenario: A connection will timeout if the local system doesn't receive an (ACK)nowledgement for data sent. It would also timeout if a (FIN)ish TCP packet is not ACK'd (and even if the FIN is ACK'd, it will eventually timeout if a FIN is not returned).
User suggestions: There are a number of things to check, that might help to identify why the failure occurred. Basically, you want to identify where the problem occurred.
WinSock functions: recv(), recvfrom(), sendto(), FD_CLOSE
Additional functions: send() can also fail with WSAECONNABORTED. Any function that takes a socket as an input parameter--except close socket()--could potentially fail with this error.
See also: WSAECONNRESET, WSAENETRESET, WSAETIMEDOUT
WSAECONNREFUSED (10061) Connection refused.
Berkeley description: No connection could be made because the target machine actively refused it. This usually results from trying to connect to a service that is inactive on the foreign host.
WinSock description: Same as Berkeley
TCP/IP scenario: In TCP terms (datastream sockets), it means an attempt to connect (by sending a TCP SYN packet) caused the destination host to respond to the host by returning a reset (a TCP RST packet). If an application sends a UDP packet to a host/port that does not have a datagram socket "listening," the network system may respond by sending back an ICMP Port Unreachable packet
User suggestions: Either you went to the wrong host, or the server application you're trying to contact isn't executing. Check the destination address you are using. If you used a hostname, did it resolve to the correct address? If the hostname resolution uses a local hosttable, it's possible you resolved to an old obsolete address. It's also possible that the local services file has an incorrect port number (although it's unlikely).
You can verify that the remote system is rejecting your connection attempt by checking the network statistics locally. Check that your network system (WinSock implementation) has a utility that shows network statistics. You could use this to verify that you're receiving TCP resets or ICMP Port Unreachable packets each time you attempt to connect.
Developer suggestions: If you have a network analyzer available, you can quickly check if the destination port number and host address are what you expect. On the server end, you could use a network system utility similar to BSD's "netstat -a" command to check that your server is running, and listening on the right port number.
This is one of the most frequent errors and one of the best to encounter, since it's one of the least ambiguous. There are only a few possible causes for this error:
WinSock functions: With a datastream socket: connect() and FD_CONNECT WSAAsyncelect() notification message.
Additional functions: With a datagram socket: send() or sendto(), or FD_READ.
WSAECONNRESET (10054) Connection reset by peer.
Berkeley description: A connection was forcibly closed by a peer. This normally results from a loss of the connection on the remote socket due to a timeout or a reboot.
WinSock description: Same as Berkeley. On a datastream socket, the connection was reset. This reset could be generated locally by the network system when it detects a connection failure, or it might be received from the remote host (in TCP terms, the remote host sent a RST packet). This error is also possible on a datagram socket; for instance, this error could result if your application sends a UDP datagram to a host, which rejects it by responding with an ICMP Port Unreachable.
User suggestions: Some network systems have commands to report statistics. In this case, it might be possible to check the count of TCP RST packets received, or ICMP Port Unreachable packets. See other suggestions under WSAECONNABORTED.
WinSock functions: recv(), recvfrom(), send(), sendto(), FD_CLOSE
Additional functions: Any function that does I/O on the network could generate this error. Two functions that are conspicuously absent from the current function list above are shutdown() and close socket().
See also: WSAECONNABORTED, WSAENETRESET, WSAETIMEDOUT
WSAEDESTADDRREQ (10039) Destination address required.
Berkeley description: A required address was omitted from an operation on a socket.
WinSock description: Same as Berkeley. The explanation is simple and obvious: in order to connect to or send to a destination address, you need to provide the destination address. This error occurs if the sin_addr is INADDR_ANY (i.e. a long zero) in the sockaddr_in structure passed to sendto(). Note: Although connect() and FD_CONNECT also have this error listed, the documentation specifically states that WSAEADDRNOTAVAIL is appropriate if INADDR_ANY is passed as a destination address.
User suggestions: Did you enter a destination hostname? If so, then the application might have had a problem resolving the name (see suggestions at WSATRY_AGAIN for more information).
Developer suggestions: If you don't detect it beforehand (e.g. after failed calls to inet_addr() or gethostbyname()), then simply test your address value for zero before you pass it to sendto().
WinSock functions: connect(), sendto(), FD_CONNECT
WSAEDQUOT (10069) Disc quota exceeded.
Berkeley description: A write to an ordinary file, the creation of a directory or symbolic link, or the creation of a directory entry failed because the user's quota of disk blocks was exhausted, or the allocation of an inode for a newly created file failed because the user's quota of inodes was exhausted.
WinSock description: No equivalent. This has no network-relevant analog (although the "inode" reference could refer to a network file system entry).
WinSock functions: <none>
WSAEFAULT (10014) Bad address.
Berkeley description: The system detected an invalid address in attempting to use an argument of a call.
WinSock description: Same as Berkeley, and then some. Specifically, v1.1 WinSock spec notes that this error occurs if the length of the buffer is too small. For instance, if the length of a struct sockaddr is not equivalent to the sizeof(struct sockaddr). However, it also occurs when an application passes an invalid pointer value.
Developer suggestions: Always check the return value from a memory allocation to be sure it succeeded. Always be sure to allocate enough space.
WinSock functions: accept(), bind(), connect(), gethostname(), getpeername(), getsockname(), getsockopt(), recvfrom(), send(), sendto(), setsockopt() if buffer length is too small.
Additional functions: Any functions that takes a pointer as an input parameter: inet_addr(), inet_ntoa(), ioctlsocket(), gethostbyaddr(), gethostbyname(), getservbyname(), getservbyport(), WSAAsyncGetHostByName(), WSAAsyncGetHostByAddr(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber, WSAAsyncGetServByName(), WSAAsyncGetServByPort(), WSASetBlockingHook()
WSAEHOSTDOWN (10064) Host is down.
Berkeley description: A socket operation failed because the destination host was down. A socket operation encountered a dead host. Networking activity on the local host has not been initiated.
WinSock description: No equivalent. The only time a WinSock might use this error--at least with a TCP/IP implementation of WinSock--it fails a function with other errors (for example, WSAETIMEDOUT).
WinSock functions: <none>
See also: WSAECONNABORTED, WSAECONNRESET, WSAENETRESET, WSAETIMEDOUT
WSAEHOSTUNREACH (10065) No route to host.
Berkeley description: A socket operation was attempted to an unreachable host.
WinSock description: Same as Berkeley. Unlike Berkeley, however, WinSock v1.1 doesn't ascribe this error to any functions. In it's place, WinSock uses the error WSAENETUNREACH, exclusively.
TCP/IP scenario: In BSD-compatible implementations, the local network system generates this error if there isn't a default route configured. Typically, though, WinSock generates WSAENETUNREACH when it receives a "host unreachable" ICMP message from a router instead of WSAEHOSTUNREACH. The ICMP message means that the router can't forward the IP datagram, possibly because it didn't get a response to the ARP request (which might mean the destination host is down).
User suggestions: see WSAENETUNREACH for details
WinSock functions: <none>
Additional functions: Any function that does network I/O.
See also: WSAENETUNREACH
WSAEINPROGRESS (10036) Operation now in progress.
Berkeley description: An operation that takes a long time to complete (such as a connect()) was attempted on a non-blocking socket. (see ioctl()).
WinSock description: The Windows Sockets definition of this error is very different from Berkeley. WinSock only allows a single blocking operation to be outstanding per task (or thread), and if you make any other function call (whether or not it references that or any other socket) the function fails with the WSAEINPROGRESS error. It means that there is a blocking operation outstanding.
It is also possible that WinSock might return this error after an application calls connect() a second time on a non-blocking socket while the connection is pending (i.e. after the first failed with WSAEWOULDBLOCK). This is what occurs in Berkeley Sockets.
Developer suggestions: Handle this as a non-fatal error. Any application that uses a blocking socket or calls any blocking functions must handle this error. You can attempt to avoid the error by calling WSAIsBlocking() before making any WinSock function calls.
WinSock functions: accept(), bind(), closesocket(), connect(), gethostbyaddr(), gethostbyname(), gethostname(), getpeername(), getprotobyname(), getprotobynumber(), getservbyname(), getservbyport(), getsockname(), getsockopt(), ioctlsocket(), listen(), recv(), recvfrom(), select(), send(), sendto(), setsockopt(), shutdown(), socket(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort(), WSAAsyncSelect(), WSACancelAsyncRequest(), WSACleanup(), WSASetBlockingHook(),
Additional functions: Any WinSock function except WSACancelBlockingCall (in particular, WSAStartup() and WSAUnhookBlockingHook()).
WSAEINTR (10004) Interrupted function call.
Berkeley description: An asynchronous signal (such as SIGINTor SIGQUIT) was caught by the process during the execution of an interruptible function. If the signal handler performs a normal return, the interrupted function call will seem to have returned the error condition.
WinSock description: NOT same as Berkeley, but analogous. In WinSock it means a blocking operation was interrupted by a call to WSACancelBlockingCall.
Developer suggestions: You need to be prepared to handle this error on any functions that reference blocking sockets, or any calls to blocking functions, if you allow the user to cancel a blocking call. Whether to handle it as a fatal error or non-fatal error depends on the application and the context, so it's entirely up to you to decide.
WinSock functions: Any function capable of a blocking operation can return this error: accept(), close socket(), connect(),gethostbyname(), gethostbyaddr(), getprotobyname(), getprotobynumber(), getservbyname(), getservbyport(), recv(), recvfrom(), select(), send(), sendto()
Additional functions: Any of the WSAAsyncGetXByY() database functions may return this error in the asynchronous notification message to indicate that the previous call was cancelled with a call to WSACancelAsyncRequest().
WSAEINVAL (10022) Invalid argument.
Berkeley description: Some invalid argument was supplied (for example, specifying an invalid level to the setsockopt() function).
Microsoft C description: Invalid argument. An invalid value was given for one of the arguments to a function. For example, the value given for the origin when positioning a file pointer (by means of a call to fseek) is before the beginning of the file.
WinSock description: Similar to Berkeley & Microsoft C, the generic meaning is that an application passed invalid input parameter in a function call. The error refers to content as well as value (e.g. it may occur when a pointer to a structures is invalid or when a value in structure field is invalid). In some instances, it also refers to the current state of the socket input parameter.
Detailed descriptions (relevant to socket states):
accept(): listen() was not invoked prior to accept()
bind(): socket already bound to an address
getsockname(): socket not bound with bind()
listen(): socket not bound with bind() or already connected.
recv() & recvfrom(): socket not bound (for Dgram) or not yet connected (for Stream), or the requested length is zero (whether a length >32K
is acceptable as a non-negative value is unclear, so don't use them).
send() & sendto(): socket not bound (for Dgram) or not yet connected (for Stream)
The v1.1 specification also has a detailed description for the connect() function which says: "socket not already bound to an address." This text is a typo which makes no sense. Ignore it. The standard meaning for WSAEINVAL applies to connect() (invalid argument).
WinSock functions: accept(), bind(), getsockname(), ioctlsocket(), listen(), recv(), recvfrom(), select(), send(), setsockopt(), shutdown(), WSAStartup(), WSAAsyncSelect(), WSACancelAsyncRequest(), WSACancelBlockingCall, FD_CONNECT
Additional functions: Any WinSock function that takes input parameters that could be invalid (i.e. have bounds, or specific values) might return this error.
WSAEISCONN (10056) Socket is already connected.
Berkeley description: A connect request was made on an already connected socket; or, a sendto() or sendmsg() request on a connected socket specified a destination when already connected.
WinSock description: Same as Berkeley, except WinSock doesn't support the sendmsg() function, and some WinSock implementations are not so strict as to require an application with a datagram socket to "disconnect"--by calling connect() with a AF_INET NULL destination address: INADDR_ANY (0.0.0.0), and port 0--before redirecting datagrams with sendto() or connect(). On a datastream socket, some applications use this error with a non-blocking socket calling connect() to detect when a connection attempt has completed, although this is not recommended since some WinSocks fail with WSAEINVAL on subsequent connect() calls.
Developer suggestions: to make your application more portable: with datagram sockets don't use connect() and sendto() on the same datagram socket in an application, and always "disconnect" before calling connect() more than once. With datastream sockets, don't call connect() more than once (use select() or WSAAsyncSelect() to detect connection completion).
WinSock functions: listen(), FD_CONNECT
Additional functions: connect(), sendto()
WSAELOOP (10062) Too many levels of symbolic links.
Berkeley description: A pathname lookup involved more than 8 symbolic links. Too many links were encountered in translating a pathname.
WinSock description: No equivalent
WinSock functions: <none>
WSAEMFILE (10024) Too many open files.
Berkeley description: Too many open files. No process may have more than a system-defined number of file descriptors open at a time.
Microsoft C description: Too many open files. No more file handles are available, so no more files can be opened.
WinSock description: Similar to Berkeley & Microsoft C, but in reference to sockets rather than file handles (although the descriptions in the v1.1 specification say "no more file descriptors available"). Generically, the error means the network system has run out of socket handles.
User suggestions: It may indicate that there are too many WinSock applications running simultaneously, but this is unlikely since most network systems have many socket handles available. It could also occur if an application opens and closes sockets often, but doesn't properly close the sockets (so it leaves them open, as "orphans"). To recover the orphaned sockets, you can try closing the application and restarting it to recover the open sockets; you may have to end all WinSock applications (to force an unload of the WinSock DLL).
WinSock functions: Any function which allocates a new descriptor: accept(), listen(), & socket(). The v1.1 specification also lists connect(), although it does not allocate a descriptor.
WSAEMSGSIZE (10040) Message too long.
Berkeley description: A message sent on a socket was larger than the internal message buffer or some other network limit.
WinSock description: Similar to Berkeley.
Detailed description:
recv() and recvfrom(): if the datagram you read is larger than the buffer you supplied, then WinSock truncates the datagram (i.e. copies what it can into your buffer) and fails the function.
send() and sendto(): you cannot send a datagram as large as you've requested. Note that the v1.1 WinSock specification does not explicitly state that this error occurs if the value you request is larger than the WSAData.iMaxUdpDg returned from WSAStartup(). Since the buffering requirements for sending are less than for receiving datagrams, it's conceivable that you can send a datagram larger than you can receive.
WinSock functions: recv(), recvfrom(), send(), sendto()
WSAENAMETOOLONG (10063) File name too long.
Berkeley description: A component of a path name exceeded 255 (MAXNAMELEN) characters, or an entire path name exceeded 1023 (MAXPATHLEN-1) characters.
WinSock description: No equivalent.
WinSock functions: <none>
WSAENETDOWN (10050) Network is down.
Berkeley description: A socket operation encountered a dead network.
WinSock description: Same as Berkeley. As you can see from the comprehensive list of WinSock functions, this error is the catch-all. When it occurs, it could indicate a serious failure of your network system (i.e. the protocol stack that the WinSock DLL runs over).
User suggestions: Check your WinSock, protocol stack, network driver and network interface card configuration. Note that this error occurs rarely since a WinSock implementation cannot reliably detect hardware problems.
WinSock functions: accept(), bind(), closesocket(), connect(), gethostbyaddr(), gethostbyname(), gethostname(), getpeername(), getprotobyname(), getprotobynumber(), getservbyname(), getservbyport(), getsockname(), getsockopt(), ioctlsocket(), listen(), recv(), recvfrom(), select(), send(), sendto(), setsockopt(), shutdown(), socket(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort(), WSAAsyncSelect(), WSACancelAsyncRequest(), WSACancelBlockingCall, WSACleanup(), WSASetBlockingHook(), FD_ACCEPT, FD_CLOSE, FD_OOB, FD_READ, FD_WRITE
Additional functions: All functions capable of failing can fail with this error. A couple functions that the v1.1 specification missed are WSASetLastError() and WSAUnhookBlockingHook().
WSAENETRESET (10052) Network dropped connection on reset.
Berkeley description: The host you were connected to crashed and rebooted.
WinSock description: Same as Berkeley.
Detailed description:
setsockopt(): WinSock generates this error if you try to set SO_KEEPALIVE on a connection that's already timed out.
User suggestions: see WSAECONNABORTED for details.
WinSock functions: send(), sendto(), setsockopt()
Additional functions: Any function that does network I/O: recv(), recvfrom(), FD_READ, FD_WRITE
See also: WSAECONNABORTED, WSAECONNRESET, WSAETIMEDOUT
WSAENETUNREACH (10051) Network is unreachable.
Berkeley description: A socket operation was attempted to an unreachable network.
WinSock description: Almost same as Berkeley. For WinSock, this error is equivalent to Berkeley's EHOSTUNREACH error, the catch-all error for unreachable hosts. "You can't get there from here."
TCP/IP scenario: The local network system could generate this error if there isn't a default route configured. Typically, though, WinSock generates this error when it receives a "host unreachable" ICMP message from a router. The ICMP message means that a router can't forward the IP datagram, possibly because it didn't get a response to the ARP request (which might mean the destination host is down). Note: this error may also result if you are trying to send a multicast packet and the default gateway does not support multicast (check your interface configuration).
User suggestions: Try to ping the destination host, to see if you get the same results (chances are, you will). Check the destination address itself; is it the one you wanted to go to? Check whether you have a router configured in your network system (your WinSock implementation). Do a traceroute to try to determine where the failure occurs along the route between your host and the destination host.
WinSock functions: connect(), sendto(), FD_CONNECT
Additional functions: Any function that does network I/O: recv(), recvfrom(), send(), FD_READ, FD_WRITE
See also: WSAEHOSTUNREACH
WSAENOBUFS (10055) No buffer space available.
Berkeley description: An operation on a socket or pipe was not performed because the system lacked sufficient buffer space or because a queue was full.
WinSock description: Same as Berkeley. The WinSock implementation was unable to allocate additional memory to accommodate the function request.
User suggestions: This error indicates a shortage of resources on your system. It can occur if you're trying to run too many applications (of any kind) simultaneously on your machine. If this tends to occur after running certain applications for a while, it might be a symptom of an application that doesn't return system resources (like memory) properly. It may also indicate you are not closing the applications properly. If it persists, exit Windows or reboot your machine to remedy the problem. You can monitor available memory with Program Manager's "Help/About..." command.
WinSock functions: accept(), bind(), connect(), listen(), send(), sendto(), socket(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort(), FD_CONNECT
Additional functions: Any other functions that use network system buffer space, like the "database functions", setsockopt() with SO_RCVBUF or SO_SNDBUF options.
WSAENOPROTOOPT (10042) Bad protocol option.
Berkeley description: A bad option or level was specified in a getsockopt()(2) or setsockopt(2) call.
WinSock description: Same as Berkeley; the option is unknown or unsupported.
Detailed description:
SO_BROADCAST is not supported on sockets of type SOCK_STREAM.
SO_ACCEPTCONN, SO_DONTLINGER, SO_KEEPALIVE, SO_LINGER, SO_OOBINLINE and TCP_NODELAY are not supported on sockets of type SOCK_DGRAM.
SO_DEBUG, SO_DONTROUTE, SO_RCVBUF, SO_SNDBUF, TCP_NODELAY: optional socket options.
SO_ACCEPTCONN, SO_ERROR, SO_TYPE: are read-only options, so they work with getsockopt(), but not with setsockopt()
Developer suggestions: Check the parameters. Are you using an optional level or socket option that may not be supported on all WinSock implementations? If so, treat this as a non-fatal error and ignore it, if possible.
WinSock functions: getsockopt(), setsockopt()
Additional functions: Bad IP headers can cause routers and remote hosts to issue ICMP "parameter problem" messages, which result in a ENOPROTOOPT error on Berkeley-derived systems. These errors might be reported on any function that does network I/O (e.g. connect(), send(), recv(), et cetera).
See also: WSAEINVAL
WSAENOTCONN (10057) Socket is not connected.
Berkeley description: A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket) no address was supplied.
WinSock description: Same as Berkeley, and then some. An application attempted an input/output network function call before establishing an association with a remote socket (i.e. before calling connect() or accept()). It also has a specific meaning for setsockopt().
Detailed description:
setsockopt(): WinSock generates this error if you try to set SO_KEEPALIVE but the connection has already been aborted (e.g. a TCP reset received from remote host).
Developer suggestions: Chances are, that if you encounter this error, your application ignored the failure of some previous function. Although some WinSock implementations might not issue other errors if a connection fails, so you can handle this error as you would others that indicate connection failure.
WinSock functions: getpeername(), recv(), recvfrom(), send(), sendto(), setsockopt(), shutdown(), FD_CONNECT
See also: WSAECONNABORTED, WSAECONNRESET, WSAENETRESET, WSAETIMEDOUT
WSAENOTEMPTY (10066) Directory not empty.
Berkeley description: A directory with entries other than `.'and `..' was supplied to a remove directory or rename call.
WinSock description: No equivalent.
WinSock functions: <none>
WSAENOTSOCK (10038) Socket operation on non-socket.
Berkeley description: An operation was attempted on something that is not a socket. The specified socket parameter refers to a file, not a socket.
WinSock description: Same as Berkeley. The socket input parameter is not a valid socket handle (either it never was valid, it's a file handle (not a socket handle), or if it was a socket handle, it has been closed).
Detailed description:
select(): fails with WSAENOTSOCK if any socket in an fd_set is an invalid socket handle.
Developer suggestions: Did you close a socket inadvertently in one part of an application without keeping another part notified? Use socket state in an application and/or handle this error gracefully as a non-fatal error.
WinSock functions: Any function that takes a socket as an input parameter: accept(), bind(), closesocket(), connect(), getpeername(), getsockname(), getsockopt(), ioctl socket(), listen(), recv(), recvfrom(), select(), send(), sendto(), setsockopt(), shutdown(), FD_CONNECT
Additional functions: WSAAsyncSelect() should be in the list of functions (some applications might not register for or handle the FD_CONNECT message).
WSAEOPNOTSUPP (10045) Operation not supported.
Berkeley description: The attempted operation is not supported for the type of object referenced. Usually this occurs when a file descriptor refers to a file or socket that cannot support this operation, for example, trying to accept a connection on a datagram socket.
WinSock description: Same as Berkeley. "You can't make a silk purse from a sow's ear."
Detailed descriptions:
accept(), listen(): socket is not of type that supports connection-oriented service.
recv(), recvfrom(), send(), sendto(): MSG_OOB was specified, but the socket is not of type SOCK_STREAM
Developer suggestions: don't do that.
WinSock functions: accept(), listen(), recv(), recvfrom(), send(), sendto()
WSAEPFNOSUPPORT (10046) Protocol family not supported.
Berkeley description: The protocol family has not been configured into the system or no implementation for it exists.
WinSock description: Same as Berkeley. Apparently, the Windows Sockets specification left this out by oversight. The WSAEAFNOSUPPORT is the likely substitute error for this in WinSock, although its Berkeley meaning is slightly different. However, the WSAEPROTONOSUPPORT is another possible equivalent for WinSock to use in place of this error.
WinSock functions: <none>
Additional functions: For Berkeley compatibility, the socket() function should fail with this error if an unsupported address family is requested.
See also: WSAEAFNOSUPPORT
WSAEPROCLIM (10067) Too many processes.
Berkeley description: No equivalent in 4.3 BSD or compatible operating systems.
WinSock description: No equivalent.
WinSock functions: <none>
Additional functions: If a WinSock implementation has an upper limit to the number of simultaneous tasks it can handle, an application's initial call to WSAStartup() could fail with this error.
WSAEPROTONOSUPPORT (10043) Protocol not supported.
Berkeley description: The protocol has not been configured into the system, or no implementation for it exists.
WinSock description: Same as Berkeley. So, for example, if a WinSock implementation doesn't support SOCK_RAW with IPPROTO_IP (or any other protocol), then the socket() call would fail with WSAEPROTONOSUPPORT (however, if it doesn't support SOCK_RAW at all, you should expect WSAESOCKTNOSUPPORT).
Developer suggestion: are you trying to use an optional feature? Handle the request as a non-fatal error (if possible), since some WinSock's can legally fail the request.
WinSock functions: socket()
See also: WSAESOCKTNOSUPPORT
WSAEPROTOTYPE (10041) Protocol wrong type for socket.
Berkeley description: A protocol was specified that does not support the semantics of the socket type requested. For example, you cannot use the ARPA Internet UDP protocol with type SOCK_STREAM.
WinSock description: Same as Berkeley. This error occurs if you specifically reference a protocol that isn't part of the address family you also reference. The only function that takes these two explicit parameters is socket().
Developer suggestions: Since there're only one corresponding protocol for each of the datagram and datastream socket types in the Internet address family, you should simply leave the value in the protocol input parameter to socket(). Alternately, you could call getprotobyname() or WSAAsyncGetProtoByName() to get the appropriate protocol value from the network system.
WinSock functions: socket()
See also: WSAEAFNOSUPPORT, WSAEPFNOSUPPORT
WSAEREMOTE (10071) Too many levels of remote in path
Berkeley description: Item is not local to the host. A server has attempted to handle an NFS request by generating a request to another NFS server, which is not allowed.
WinSock description: No equivalent. The WinSock API does not provide access to the Network File System application protocol, so this error is irrelevant to WinSock.
WinSock functions: <none>
WSAESHUTDOWN (10058) Cannot send after socket shutdown.
Berkeley description: A request to send data was disallowed because the socket had already been shut down with a previous shutdown() call.
WinSock description: Same as Berkeley. By calling shutdown() you do a partial close of a socket, which means you have discontinued sending. The WinSock implementation will not allow you to send after this.
TCP/IP scenario: Calling shutdown() with how=1 or how=2 sends a TCP FIN packet to the remote address, which literally means "I'm done sending." If the local host sent any more data after that point, it would be in clear violation of the TCP specification (RFCs 793 and 1122).
Developer suggestion: The simple suggestion is "don't do that." No matter what value you use for the "how" parameter to the shutdown() function, you cannot send afterwards. You can avoid making the mistake of trying to send on a socket after you've initiated a close, by keeping track of the socket state in your application (and checking it before you attempt I/O).
WinSock functions: recv(), recvfrom(), send(), sendto(), with datastream sockets only.
WSAESOCKTNOSUPPORT (10044) Socket type not supported.
Berkeley description: The support for the socket type has not been configured into the system or no implementation for it exists.
WinSock description: Similar to Berkeley. The WinSock description for this error is "the specified socket type is not supported in this address family," which qualifies the error condition a bit more than the Berkeley explanation does. So, for example, you can expect this error if a WinSock implementation doesn't support socket type SOCK_RAW within the Internet address family (AF_INET).
Developer suggestion: are you trying to use an optional feature? Handle the request as a non-fatal error (if possible), since some WinSock's can legally fail the request.
WinSock functions: socket()
See also: WSAEPROTOTYPE, WSAEPROTONOSUPPORT
WSAESTALE (10070) Stale NFS file handle.
Berkeley description: An attempt was made to access an open file (on an NFS filesystem) which is now unavailable as referenced by the file descriptor. This may indicate the file was deleted on the NFS server or some other catastrophic event occurred.
WinSock description: No equivalent. NFS is "network-related" in the strictest sense, but the Network File System protocol is an application protocol (i.e. a "high-level" protocol). The Windows Sockets API provides access to "low-level" API's (like the transport protocols TCP and UDP), so this error is not relevant to WinSock.
WinSock functions: <none>
WSAETIMEDOUT (10060) Connection timed out.
Berkeley description: A connect or send request failed because the connected party did not properly respond after a period of time. (The timeout period is dependent on the communication protocol.)
WinSock description: Same as Berkeley, but less. This error is relevant to connect(), but not to send() or sendto() as it is in Berkeley Sockets.
User suggestions: Check the obvious first: check that the destination address is a valid IP address. If you used a hostname, did it resolve to the correct address? If the hostname resolution uses a local host table, it's possible you resolved to an obsolete address. Can you ping that hostname?
Do you have a router configured? Is the router up and running (check by pinging it, and then ping an address on the other side of it)? Try a traceroute to the destination address to check that all the routers are functioning.
Check your subnet mask. If you don't have the proper subnet mask, your network system may treat a local address as a remote address (so it forwards addresses on the local subnet to the router, rather than broadcasting an ARP request locally), or visa versa.
WinSock functions: connect(), FD_CONNECT
Additional functions: Any function that does I/O on the network could generate this error, and the WSAAsyncSelect() events FD_OOB, FD_READ, FD_WRITE.
See also: WSAECONNABORTED, WSAECONNRESET, WSAENETRESET
WSAETOOMANYREFS (10059) Too many references; can't splice
Berkeley description: too many references to some kernel-level object; the associated resource has run out.
WinSock description: No equivalent.
WinSock functions: <none>
WSAEUSERS (10068) Too many users.
Berkeley description: The quota system ran out of table entries.
WinSock description: No equivalent.
WinSock functions: <none>
WSAEWOULDBLOCK (10035) Resource temporarily unavailable.
Berkeley description: This is a temporary condition and later calls to the same routine may complete normally (also known as EAGAIN error in Berkeley Software Distribution version 4.3)
WinSock description: Same as Berkeley. The socket is marked as non-blocking (non-blocking operation mode), and the requested operation is not complete at this time.
Detailed descriptions:
connect(): the operation is underway, but as yet incomplete.
closesocket(): occurs on a non-blocking socket with non-zero timeout set with setsockopt() SO_LINGER. The behavior may vary: some WinSocks might complete in background, and others may require another call to closesocket to complete. Do not set non-zero timeout on non-blocking sockets to avoid this ambiguity (see Chapter 9 for more information).
send() or sendto(): out of buffer space, so try again later or wait until FD_WRITE
notification (WSAAsyncSelect()) or select() writefds is set.
all other functions: retry the operation again later since it cannot be satisfied at this time.
Developer suggestions: Every application that uses non-blocking sockets must be prepared for this error on any call to the functions mentioned below. For instance, even if you request to send() a few bytes of data on a newly created TCP connection, send() could fail with WSAEWOULDBLOCK (if, say, the network system has a TCP slow-start algorithm implemented). The WSAAsyncSelect() FD_WRITE event is specifically designed to notify an application after a WSAEWOULDBLOCK error when buffer space is available again so send() or sendto() should succeed.
WinSock functions: accept(), close socket(), connect(), recv(), recvfrom(), send(), sendto(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort()
WSAHOST_NOT_FOUND (11001) Host not found
Berkeley description: No such host is known. The name you have used is not an official hostname or alias. This is not a soft error, another type of name server request may be successful.
WinSock description: Same as Berkeley. Any of the WinSock name resolution functions can fail with this error. The WinSock API does not provide any way to select specific name resolution protocols, server address, or record type.
TCP/IP scenario: Most WinSock implementations use domain name system (DNS) protocol for hostname to address resolution, although a few use Network Information System (NIS). Assuming you have a name server configured instead of or as well as a host table, a hostname resolution request causes a WinSock DLL to send a DNS "A" record query (address query) to the configured DNS query. If you have more than one server configured, the hostname query fails only after the WinSock DLL has queried all servers.
User suggestions: Check that you have a name server(s) and/or host table configured. If you are using a name server(s), check whether the server host(s) are up (e.g. try to ping the server(s)). You could also try to resolve another hostname you know should work, to check that the name resolution server application is running.
If you are using a host table exclusively, you'll need to update it to add the destination hostname and address.
Developer suggestions: for protocols and services consider using a hard-coded value for the protocol number or service port number in case your resolution attempt fails, and you can have your cake and eat it too.
WinSock functions: gethostbyaddr(), gethostbyname(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort()
Additional functions: It is strange that the asynchronous protocol and services functions can fail with this error, but the synchronous cannot. The missing functions are getprotobyname(), getprotobynumber(), getservbyname(), and getservbyport().
See also: WSANO_DATA, WSANO_RECOVERY, WSATRY_AGAIN
WSANOTINITIALISED (10093) Successful WSAStartup() not yet performed
Berkeley description: No equivalent.
WinSock description: Either your application hasn't called WSAStartup(), or WSAStartup() failed, or--possibly--you are accessing a socket which the current active task does not own (i.e. you're trying to share a socket between tasks). Note the British spelling (with an 'S' instead of a 'Z').
User suggestions: Chances are the network subsystem is misconfigured or inactive. See WSASYSNOTREADY for details.
Developer suggestions: WSAStartup() failed, and you didn't detect it, or it wasn't called for the current task at all, or you called WSACleanup() too many times.
WinSock functions: accept(), bind(), closesocket(), connect(), gethostbyaddr(), gethostbyname(), gethostname(), getpeername(), getprotobyname(), getprotobynumber(), getservbyname(), getservbyport(), getsockname(), getsockopt(), ioctlsocket(), listen(), recv(), recvfrom(), select(), send(), sendto(), setsockopt(), shutdown(), socket(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort(), WSAAsyncSelect(), WSACancelAsyncRequest(), WSACancelBlockingCall, WSACleanup(), WSASetBlockingHook(), WSAUnhookBlockingHook()
Additional functions: The only function capable of failing with a WinSock error that doesn't list error is WSAUnhookBlockingHook(). Clearly, this oversight was not intentional.
WSANO_DATA (11004) Valid name, no data record of requested type
Berkeley description: The requested name is valid, but does not have an Internet IP address at the name server. This is not a temporary error. This means another type of request to the name server will result in an answer.
WinSock description: Same as Berkeley for host resolution. For protocol and services resolution, the name or number was not found in the respective database.
User suggestions: see WSAHOST_NOT_FOUND for details.
WinSock functions: gethostbyaddr(), gethostbyname(), getprotobyname(), getprotobynumber(), getservbyname(), getservbyport(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(),
See also: WSAHOST_NOT_FOUND, WSANO_RECOVERY, WSATRY_AGAIN
WSANO_RECOVERY (11003) This is a non-recoverable error
Berkeley description: This is a non-recoverable error.
WinSock description: Same as Berkeley. Specifically, the v1.1 Windows Sockets specification notes the domain name system (DNS) errors "FORMERR, REFUSED, and & NOTIMP. For protocols and services resolution, it means the respective database wasn't located.
Detailed description (from RFC 1035, "Domain Names", by P.Mockapetris):
Format error: name server was unable to interpret the query.
Request refused: name server refuses to satisfy your query for policy reasons.
Not implemented: name server does not perform specified operation.
User suggestions: see WSAHOST_NOT_FOUND for details.
WinSock functions: gethostbyaddr(), gethostbyname(), getprotobyname(), getprotobynumber(), getservbyname(), getservbyport(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort(),
See also: WSAHOST_NOT_FOUND, WSANO_DATA, WSATRY_AGAIN
WSASYSNOTREADY (10091) Network subsystem is unavailable
Berkeley description: No equivalent.
WinSock description: The WinSock implementation cannot function at this time, because the underlying system it uses to provide network services is currently unavailable.
User suggestions:
WinSock functions: WSAStartup()
WSATRY_AGAIN (11002) Non-authoritative host not found
Berkeley description: This is usually a temporary error and means that the local server did not receive a response from an authoritative server. A retry at some time later may be successful.
WinSock description: Same as Berkeley. Notice that asynchronous service and protocols functions are listed below, in addition to the hostname resolution functions.
User suggestions: see WSAHOST_NOT_FOUND for details.
WinSock function: gethostbyaddr(), gethostbyname(), WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(), WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(), WSAAsyncGetServByName(), WSAAsyncGetServByPort()
See also: WSANO_DATA, WSANO_RECOVERY, WSATRY_AGAIN
WSAVERNOTSUPPORTED (10092) WINSOCK.DLL version out of range
Berkeley description: No equivalent.
WinSock description: The current WinSock implementation does not support the Windows Sockets specification version requested by the application.
User suggestions: Do you have the WinSock DLL that supports the version of the WinSock specification required by the application? If so, is there an older DLL in a directory in the path ahead of the directory containing the newer DLL? If not, check with your WinSock vendor to see if they have a newer WinSock available.
Developer suggestion: Use the sample code fragment in the WSAStartup() documentation in the v1.1 specification, which demonstrates how an application negotiates a Windows Sockets specification version.
NOTE: The MAKEWORD macro referenced in the code fragment is not available in the WINSOCK.H header file or in any standard header files. Here is a useable macro:
#define MAKEWORD(low, high) ((WORD)(((BYTE)(low)) | (((WORD)((BYTE)(high))) << 8)))
WinSock functions: WSAStartup(). [Go to Top]
WSABASEERR (0) No Error
WSAEINTR (10004) Interrupted system call
WSAEBADF (10009) Bad file number
WSAEACCES (10013) Permission denied
WSAEFAULT (10014) Bad address
WSAEINVAL (10022) Invalid argument
WSAEMFILE (10024) Too many open files
WSAEWOULDBLOCK (10035) Operation would block
WSAEINPROGRESS (10036) Operation now in progress
WSAEALREADY (10037) Operation already in progress
WSAENOTSOCK (10038) Socket operation on non-socket
WSAEDESTADDRREQ (10039) Destination address required
WSAEMSGSIZE (10040) Message too long
WSAEPROTOTYPE (10041) Protocol wrong type for socket
WSAENOPROTOOPT (10042) Bad protocol option
WSAEPROTONOSUPPORT (10043) Protocol not supported
WSAESOCKTNOSUPPORT (10044) Socket type not supported
WSAEOPNOTSUPP (10045) Operation not supported on socket
WSAEPFNOSUPPORT (10046) Protocol family not supported
WSAEAFNOSUPPORT (10047) Address family not supported by protocol family
WSAEADDRINUSE (10048) Address already in use
WSAEADDRNOTAVAIL (10049) Can't assign requested address
WSAENETDOWN (10050) Network is down
WSAENETUNREACH (10051) Network is unreachable
WSAENETRESET (10052) Net dropped connection or reset
WSAECONNABORTED (10053) Software caused connection abort
WSAECONNRESET (10054) Connection reset by peer
WSAENOBUFS (10055) No buffer space available
WSAEISCONN (10056) Socket is already connected
WSAENOTCONN (10057) Socket is not connected
WSAESHUTDOWN (10058) Can't send after socket shutdown
WSAETOOMANYREFS (10059) Too many references, can't splice
WSAETIMEDOUT (10060) Connection timed out
WSAECONNREFUSED (10061) Connection refused
WSAELOOP (10062) Too many levels of symbolic links
WSAENAMETOOLONG (10063) File name too long
WSAEHOSTDOWN (10064) Host is down
WSAEHOSTUNREACH (10065) No Route to Host
WSAENOTEMPTY (10066) Directory not empty
WSAEPROCLIM (10067) Too many processes
WSAEUSERS (10068) Too many users
WSAEDQUOT (10069) Disc Quota Exceeded
WSAESTALE (10070) Stale NFS file handle
WSASYSNOTREADY (10091) Network SubSystem is unavailable
WSAVERNOTSUPPORTED (10092) WINSOCK DLL Version out of range
WSANOTINITIALISED (10093) Successful WSASTARTUP not yet performed
WSAEREMOTE (10071) Too many levels of remote in path
WSAHOST_NOT_FOUND (11001) Host not found
WSATRY_AGAIN (11002) Non-Authoritative Host not found
WSANO_RECOVERY (11003) Non-Recoverable errors: FORMERR, REFUSED, NOTIMP
WSANO_DATA (11004)* Valid name, no data record of requested type
WSANO_ADDRESS (11004)* No address, look for MX record
* Note that these are same value (typically, only WSANO_DATA is reported)