Unexpected WSANOTINITIALISED

[Roman Ryl...]

Hi,

A rather simple stress application receives 10093 (WSANOTINITIALISED)
"Successful WSAStartup not yet performed" and then
ERROR_OUT_OF_MEMORY errors on server side which I believe this to be a
winsock bug. There is source code and description at
http://alax.info/blog/130

The question is: Is there a simple way to report this to Microsoft?
Maybe there is something easier than described here
http://weblog.timaltman.com/node/834 I spend 10 minutes looking for a
submission method on MS website and I failed.

Roman

[Michael K. O'Neill]

Post by Roman Ryl...
Hi,
A rather simple stress application receives 10093 (WSANOTINITIALISED)
"Successful WSAStartup not yet performed" and then
ERROR_OUT_OF_MEMORY errors on server side which I believe this to be a
winsock bug. There is source code and description at
http://alax.info/blog/130
The question is: Is there a simple way to report this to Microsoft?
Maybe there is something easier than described here
http://weblog.timaltman.com/node/834 I spend 10 minutes looking for a
submission method on MS website and I failed.
Roman

Your server code starts a new thread for each and every connection. Very
poor scalability. Your code is probably failing in the call to
CreateThread(), which is one of the few calls whose return value you don't
check.

At what number of connections do you see the errors? If you are getting
several hundred or up to a thousand or so, before errors, then you are
probably seeing the best performance you could possibly get with the
one-thread-per-connection architecture.

Mike

[Roman Ryl...]

Mike,

Post by Michael K. O'Neill

Post by Roman Ryl...
A rather simple stress application receives 10093 (WSANOTINITIALISED)
"Successful WSAStartup not yet performed" and then
ERROR_OUT_OF_MEMORY errors on server side which I believe this to be a
winsock bug. There is source code and description at
http://alax.info/blog/130
The question is: Is there a simple way to report this to Microsoft?
Maybe there is something easier than described here
http://weblog.timaltman.com/node/834I spend 10 minutes looking for a
submission method on MS website and I failed.
RomanYour server code starts a new thread for each and every connection. Very

poor scalability. Your code is probably failing in the call to
CreateThread(), which is one of the few calls whose return value you don't
check.
At what number of connections do you see the errors? If you are getting
several hundred or up to a thousand or so, before errors, then you are
probably seeing the best performance you could possibly get with the
one-thread-per-connection architecture.

Performance is out of question here: yes it is poor but the code shows
the problem. The problems comes sooner or later depending on a number
of threads and connection lifetime - with the values hardcoded in the
project I typically get:

1. Client - approximately 50 "10054 WSAECONNRESET" errors followed by
20 "10061 WSAECONNREFUSED" errors (server socket already inaccessible)
and a message

Summary: nElapsedTime 35969 ms, g_nConnectSuccessCount 3493

That is this happens in 36 seconds of execution. On the client it's all
right, quite expectedly.

2. Server - 2019 "10093 WSANOTINITIALISED" errors followed by messages

Error: Thread 9696, Error Code 0x8007276d (10093) // 2019 times for
different threads
Error: Thread 1864, Error Code 0x80070008 (8)
Summary: g_nAcceptSuccessCount 3481, g_nConnectionSuccessCount 1473,
g_nConnectionFailureCount 2019

This is where it goes unexpected. At some point server sockets
(starting in this run from 1474th or so) are not reported to be closed
and freeze until entire server side socket subsystems gives
WSANOTINITIALISED for all currently opened sockets and error 8 (out of
memory) is reported for listening socket. It looks like on server side
sockets crash, get memory corrupted or whatever. Sockets get
uninitialized by themselves.

Thus good or bad the performance is, server side sockets fail to serve
connections at some moment (looks like at the moment system runs out of
available anonymous sockets).

Roman

BTW CreateThread result is checked

[Arkady Frenkel]

Did you tried the opposite : zero-buffering instead increasing buffer size
( obviously appp buf have to be large enough ). Anycase pay attention on
Mike's proposition to improve scalability ( using IOCP ) .
BTW you can send bugs to ***@microsoft.com
Arkady

Post by Roman Ryl...
Mike,

Post by Michael K. O'Neill

Post by Roman Ryl...
A rather simple stress application receives 10093 (WSANOTINITIALISED)
"Successful WSAStartup not yet performed" and then
ERROR_OUT_OF_MEMORY errors on server side which I believe this to be a
winsock bug. There is source code and description at
http://alax.info/blog/130
The question is: Is there a simple way to report this to Microsoft?
Maybe there is something easier than described here
http://weblog.timaltman.com/node/834I spend 10 minutes looking for a
submission method on MS website and I failed.
RomanYour server code starts a new thread for each and every connection. Very

poor scalability. Your code is probably failing in the call to
CreateThread(), which is one of the few calls whose return value you don't
check.
At what number of connections do you see the errors? If you are getting
several hundred or up to a thousand or so, before errors, then you are
probably seeing the best performance you could possibly get with the
one-thread-per-connection architecture.

Performance is out of question here: yes it is poor but the code shows
the problem. The problems comes sooner or later depending on a number
of threads and connection lifetime - with the values hardcoded in the
1. Client - approximately 50 "10054 WSAECONNRESET" errors followed by
20 "10061 WSAECONNREFUSED" errors (server socket already inaccessible)
and a message
Summary: nElapsedTime 35969 ms, g_nConnectSuccessCount 3493
That is this happens in 36 seconds of execution. On the client it's all
right, quite expectedly.
2. Server - 2019 "10093 WSANOTINITIALISED" errors followed by messages
Error: Thread 9696, Error Code 0x8007276d (10093) // 2019 times for
different threads
Error: Thread 1864, Error Code 0x80070008 (8)
Summary: g_nAcceptSuccessCount 3481, g_nConnectionSuccessCount 1473,
g_nConnectionFailureCount 2019
This is where it goes unexpected. At some point server sockets
(starting in this run from 1474th or so) are not reported to be closed
and freeze until entire server side socket subsystems gives
WSANOTINITIALISED for all currently opened sockets and error 8 (out of
memory) is reported for listening socket. It looks like on server side
sockets crash, get memory corrupted or whatever. Sockets get
uninitialized by themselves.
Thus good or bad the performance is, server side sockets fail to serve
connections at some moment (looks like at the moment system runs out of
available anonymous sockets).
Roman
BTW CreateThread result is checked

[Roman Ryl...]

Arkady and Michael,

Thank you for you input, things are sorted out. The problem in this
test app is caused by running out of memory (non paged?) and inability
to create new thread on server side. The larger socket buffer is, the
faster the memory limit is hit.

This was a test, as for real application I am going to try the
suggestion of zero length socket buffer.

Roman

[Arkady Frenkel]

Roman , please post result after your experiments...
TIA
Arkady

Post by Roman Ryl...
Arkady and Michael,
Thank you for you input, things are sorted out. The problem in this
test app is caused by running out of memory (non paged?) and inability
to create new thread on server side. The larger socket buffer is, the
faster the memory limit is hit.
This was a test, as for real application I am going to try the
suggestion of zero length socket buffer.
Roman

[Roman Ryl...]

Arkady,

Post by Arkady Frenkel

Post by Roman Ryl...
Thank you for you input, things are sorted out. The problem in this
test app is caused by running out of memory (non paged?) and inability
to create new thread on server side. The larger socket buffer is, the
faster the memory limit is hit.

Roman , please post result after your experiments...

In the real application, the problem more looks like described in
parallel thread "10055 WSAENOBUFF error"
http://groups.google.com/group/microsoft.public.platformsdk.networking/browse_thread/thread/6e6007c4d64cd1a4

We have a few outgoing socket connections which send a lot of traffic
(receive just a bit) and we see non-paged memory consumption increase
(leak or not - it's outside of the scope of the application so I don't
know). Setting socket SO_SNDBUF buffer to zero seems to make things
better on XP Pro systems (we never saw this problem on server OS). This
is a preliminary result as the issue is very tricky and it may start
leaking on 2nd-3rd day after stable operation, but it already seems to
be better with SO_SNDBUF = 0.

However we also have a report from client's Win XP *Home* system which
suffers the same issue and SO_SNDBUF = 0 does not help there.

Roman

[Arkady Frenkel]

On the system when 10055 returned, the only way I see is kernel debugging
because that something specific for that h/w ( driver ) configuration.
Arkady

Post by Roman Ryl...
Arkady,

Post by Arkady Frenkel

Post by Roman Ryl...
Thank you for you input, things are sorted out. The problem in this
test app is caused by running out of memory (non paged?) and inability
to create new thread on server side. The larger socket buffer is, the
faster the memory limit is hit.

Roman , please post result after your experiments...

In the real application, the problem more looks like described in
parallel thread "10055 WSAENOBUFF error"
http://groups.google.com/group/microsoft.public.platformsdk.networking/browse_thread/thread/6e6007c4d64cd1a4
We have a few outgoing socket connections which send a lot of traffic
(receive just a bit) and we see non-paged memory consumption increase
(leak or not - it's outside of the scope of the application so I don't
know). Setting socket SO_SNDBUF buffer to zero seems to make things
better on XP Pro systems (we never saw this problem on server OS). This
is a preliminary result as the issue is very tricky and it may start
leaking on 2nd-3rd day after stable operation, but it already seems to
be better with SO_SNDBUF = 0.
However we also have a report from client's Win XP *Home* system which
suffers the same issue and SO_SNDBUF = 0 does not help there.
Roman