Windows 8 - .NET TCP AcceptAsync callback not firing (blocked by Console.ReadLine())

Question

I'm experiencing an issue specific to Windows 8 and VS2012.

I have a TCP socket server and client and am doing some testing on the local network. With sysinternals TCPView, I can see that packets are sent from the TCP client and arrive at the TCP Server (I see the packet counters increase).

However, it appears as if the data is not making it to the application stack? The very same build runs without issues on Windows 7.

I have the Windows 8 firewall turned off and run both process with elevated permissions on a domain admin users with UAC turned off.

When I connect the client to a an outside server (running on a separate machine), everything works fine. Is there anything else in Windows 8 that could prohibit TCP data communication between local processes?

Thanks,

EDIT

To make sure nothing in my server application is causing this issue, I built a quick TCP server in a console application, with the following code for the socket constructor:

listenerSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

and listen on the same local IP/Port as my server application. I'm experiencing the same issue, I can telnet to the port but listenerSocket.AcceptAsync is never hit.

EDIT 2

Upon further testing, it appers my issue has something to do with the use of the Async socket calls, i.e. if I use the synchronous calls like socket.Accept(), the test application is performing normally. However, when I use Async socket calls, i.e. socket.AcceptAsync(), I'm experiencing the issues mentioned. So far I couldn't find any mention of differences between win7 & 8 in regards to async socket calls.

Here's my quick sample app that shows that the async callback is never triggered. This snippet works fine in Windows 7 but does not work in Windows 8 (try to telnet to 127.0.0.1 : 7000).

    class Program
{
    private static SocketAsyncEventArgs socketAsyncEventArgs = new SocketAsyncEventArgs();

    static void Main(string[] args)
    {
        var listenerSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        listenerSocket.Bind(new IPEndPoint(IPAddress.Parse("127.0.0.1"), 7000));
        listenerSocket.Listen(100);

        socketAsyncEventArgs.Completed += AcceptEventArg_Completed;
        listenerSocket.AcceptAsync(socketAsyncEventArgs);

        Console.ReadLine();
    }

    private static void AcceptEventArg_Completed(object sender, SocketAsyncEventArgs e)
    {
        Console.WriteLine("AcceptEventArg_Completed");
    }
}

EDIT 3

I found 2 others reporting the same issue on Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/details/759913/socketasynceventargs-completed-doesnt-fire-in-net-framework-4-5 and http://connect.microsoft.com/VisualStudio/feedback/details/747218/saea-not-working-in-net-4-5-rp

Whereas the 2nd one is interesting as it seems to conclude there is a Windows bug in the Console.ReadLine() call and it is causing the issue and blocking the async callback. If I replace Console.ReadLine() in my snippet with:

            while (true)
        {
            System.Threading.Thread.Sleep(10);
        }

everything works fine.

Are you communicating on the machine's public IP or via localhost? — Joachim Isaksson, Sep 17 '12 at 17:27
Well, I'd strongly suspect a firewall issue, but since I can't test right now that's all I got, sorry. Did you try manually allowing the server app in Windows Firewall? — Joachim Isaksson, Sep 17 '12 at 17:38
It appears that you have the source for both server and client so I recommend that you try running the server in a debugger to see what is happening. Or add logs so that you can see the status of the various sockets. It really sounds like some kind of a TCP driver setting issue like maybe using IPv6 rather than IPv4 or vice versa. So check your device driver settings as well. http://windows.microsoft.com/en-US/windows7/Change-TCP-IP-settings — Richard Chambers, Sep 17 '12 at 17:40
I do and the odd thing is that I see TcpView registering the packets but in the application stack (when debugging) the TCP packets are not arriving, thus I'm suspecting some kind of security setting prohibiting the data to flow down to the application — TJF, Sep 17 '12 at 17:43
Does the connection actually open ok? I'd run "netstat -ban" and check the server starts off listening on the right port and that the connection gets established to the correct process. — Peter Wishart, Sep 17 '12 at 17:52
It does, and I can telnet to the port as well - but even via telnet, any packets I send (even though it connects to the port) don't register in the server application. However, I just tested to have the server listen on the loopback address instead and it works on the loopback address — TJF, Sep 17 '12 at 18:01
Very very weird result about the Console.ReadLine(). If you move the entire test to a backgroundworker does that also fix it (leaving Console.ReadLine() in)? — Peter Wishart, Sep 18 '12 at 16:40

score 4 · Accepted Answer · edited May 23 '17 at 12:33

4

See this: GetQueuedCompletionStatus can't dequeue IO from IOCP if the thread which originally issued the IO is blocking in ReadFile under windows 8

It's a bug in windows 8 and 2012 and affect all programs which used AcceptEx and ReadFile. As for now, only these two functions are known affected.

edited May 23 '17 at 12:33

Community

1
1

answered Sep 28 '12 at 07:47

czz

474
3
9

score 0 · Answer 2 · answered Sep 19 '12 at 14:05

I meet the same thing when I was developing Tcp server and client applications with SocketAsyncEventArgs

I suggest you try this first.

open Windows firewall with Advanced Security check the inbound / outbound rules to see if your application is blocked.
open AssemblyInfo.cs and change the

[assembly: Guid("06985fe3-80eb-48b4-940a-fd926e2f2053")]

to any other guid value.

By changing this, windows will think this is a new application and if there were any restrictions towards the old application, it wont be on the new one.

score 0 · Answer 3 · answered Sep 19 '12 at 15:16

Sounds like this windows bug relating to the IOCP processing (possibly just of AcceptEx) on Windows 8 while other blocking I/O is in progress on the same thread:

http://social.technet.microsoft.com/Forums/en-GB/winserver8gen/thread/5764cd0f-fda1-4cfa-ae35-808210bae77e

So the socket connection is accepted, but your app never recieves notification of it.

Maybe Windows 8 does some weird, slighly broken, voodoo to convert synchronous IO like Console.Read into async internally.

You could just move your server code into a different thread, other workarounds to try might be to perform Accept synchonously or to change the console processing to be asynchronous (I can't really try that as I don't have Windows 8).

Windows 8 - .NET TCP AcceptAsync callback not firing (blocked by Console.ReadLine())

3 Answers3

Linked