The 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:
- Summary Info:
- Error macro: manifest constant, as defined in WINSOCK.H
- Error value: as defined in v1.1 WINSOCK.H
- Short description
-
Berkeley description: text describing the equivalent BSD
4.3 error value (with some input from other Unix errno values as well).
Most of the text comes from the output from the "man errno"
command on Unix.
-
WinSock description: a quick comparison to the Berkeley
counterpart, and a long description of WinSock error.
-
WinSock functions: the list of functions that explicitly
list this error in the v1.1 Windows Sockets specification.
Other information varies between different errors. Some of the
types of things you will find under some errors are:
- Microsoft C description: the first few WinSock errors are
carry-overs from the standard 'C' runtime library. Typically their
descriptions are similar.
- Detailed descriptions: the specific meanings that some
WinSock functions have for some errors.
- TCP/IP scenario: description of the TCP/IP protocol suite
network traffic (i.e. TCP, UDP, ICMP, ARP, DNS) that typically causes
the error.
- Developer suggestions: Things an application developer can
do to avoid the error.
- User suggestions: Things an application user can do to
diagnose the error condition further, and/or remedy it.
- Additional functions: a generic description of the type of
functions that can return this error, which may include functions other
than those listed by the WinSock specification. It may also make
explicit mention of other functions that can fail with this error.
- See also: These point to other errors that are similar.
Developers should consider handling the referenced errors similarly.
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).
- the byte-order functions, htonl(),
htons(), ntohl and ntohl(), cannot fail.
- WSAGetLastError()
and WSAIsBlocking()
cannot fail.
- The address manipulation functions, inet_ntoa() andinet_addr(),
can fail. However, they don't need to set the WinSock error
value, because there's only one reason for their failure: the input
parameter was invalid. For inet_addr(),
this could mean the content of the buffer passed or the buffer itself is
invalid.
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.
- Ping the remote host you were connected to. If it doesn't respond,
it might be off-line or there may be a network problem along the way. If
it does respond, then this problem might have been a transient one (so
you can reconnect now), or the server application you were connected to
might have terminated (so you might not be able to connect again).
- Ping a local host to verify that your local network is still
functioning (if on a serial connection, see next step)
- Ping your local router address. If you're on a serial connection,
your local router is the IP address of the host you initially logged
onto with SLIP or PPP.
- Ping a host on the same subnet as the host you were connected to
(if you know one). This will verify that the destination network is
functioning.
- Try a "traceroute" to the host you were connected to.
This won't reveal too much unless you know the router addresses at the
remote end, but it might help to identify if the problem is somewhere
along the way.
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:
- you tried to connect to the wrong port. This is a common
problem. You need to call htons() to
translate a constant value to network byte order before assigning it to
the sin_port field in the sockaddr structure.
- you tried to connect to the wrong destination host address
- the server application isn't running on the destination host
- the server application isn't listening on the right port.
The server application might need to call htons()
to translate the port to network byte order in the sockaddr structure.
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:
- Check that the WINSOCK.DLL file is in the current path
- Check that the WINSOCK.DLL file is from the same vendor as your
underlying protocol stack. You cannot mix and match (WINSOCK DLLs must
be supplied by the same vendor that provided your underlying protocol
stack).
- You cannot use more than one WinSock implementation simultaneously.
If you have more than one WINSOCK DLL on your system, be sure the first
one in the path is appropriate for the network subsystem currently
loaded.
- Check your WinSock implementation documentation to be sure all
necessary components are currently installed and configured correctly.
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().
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)
[Go to Top]