Windows 7 stops responding to TCP request after random time

Question

Welcome everyone

I'm looking for some tips (perfectly a solution :)) to a problem we are facing for a long time now.

Basically: we have a client application which sits on a Windows Server 2012 and a server application which sits on a Windows 7.

Scenario looks like this:

1. Client connects to server via TCP
2. Server accepts connection and sends a welcome message
3. Client sends a message with some data
4. Server sends a response (a confirmation that it received teh message)
5. Client closes the connection

Notice:

1. Client opens a connection for every new message. I checked the Wireshark logs as well as client/server logs and every connection is closed properly.
2. Even if my app is not handling the connection in correct way, shouldn't Windows always answer to connection requests with some kind of ACK/RST?

Problem: After some random time (it could be 30 minutes or even a week or two) server application stops sending responses. Further investigation (Wireshark logs) shows that at some moment in time:

1. Server app do not respond with "acknowledgment" message (#4 in "scenario").
2. Server app do not respond to FIN from client (probably because server app does not actively close the connection)
3. Client sends RST after 2 minutes (FIN timed out)
4. Server stops responding to any TCP requests on that port (no ACKs/RSTs, anything...)

See the screenshot below: https://i.sstatic.net/kWC1x.png

Answer 1

It's not clear where the problem actually is. Is it the network? Is it the server application? Is it the server computer/hardware/firewall, etc.? Is it the client computer?

Some troubleshooting needs to take place to know where to even look.

Here is what I would do. When the application is working properly, on the server open an Administrative Command Prompt (right-click, run as administrator). Use the command netstat -abn | more and review the contents. You will be given a list of active and listening network connections sorted by protocol and port number. You should be able to identify your server application listening on the port in question and it should show the executable name. If any active connections are established, you will also see those "established" connections listed. Now you know what it looks like when it is working properly.

Now, I would also add the Telnet client for simple testing. The Telnet client is a windows feature you can add. It is great for testing simple TCP connections. When everything is working open a command prompt on the server and use the command telnet localhost <port> - replace with the port number your application listens on. You should get at least a blank screen indicating the connection was successful. If it is not successful, you will get a timeout after a bit. Obviously, it shouldn't timeout or you definitely have something blocking connections (even if clients appear to be working right now).

Now, when the problem occurs, you can use both the netstat command and telnet command to help determine where the problem is. First, use netstat to confirm the application is still listening on the port it is supposed to be listening on. If it isn't, the problem is in your application or how it interacts with the OS.

If the application is listening properly still, you can then use telnet from the localhost and from remote windows computers to see where the connection is blocked. i.e. If you can telnet to localhost on the server successfully you know the application and network stack is working good and something on the server or network is blocking the connection (firewall, security software, etc.). You can also try telnet <local ip> <port> rather than using localhost. If one works and the other doesn't, this is another indicator of something blocking the connection on the server, or the listener might be configured wrong.

I'd be on the lookout for security software that is installed on both the server or client. Especially the "heavy" ones like McAfee or Norton. Those products are the cause of many broken hopes and dreams. Don't just disable them and cross them off the list. Uninstall them - that's the only way to be sure, and even then sometimes they break things and need more clean up work.

Without further, in depth details about your network infrastructure and server/application, there are no further answers to give. It's all about troubleshooting and eliminating where the problem is.