How to kill process that is dead but listening?

Question

I'm developing an app that listens on port 3000. Apparently there's an instance of it still listening to the port because whenever I start it, it can't create a listener (C#, TcpListener, but that's irrelevant) because the port is already taken.

Now, the app doesn't exist in the Task manager, so I tried to find it's PID and kill it... which led to this interesting result:

C:\Users\username>netstat -o -n -a | findstr 0.0:3000
   TCP    0.0.0.0:3000           0.0.0.0:0              LISTENING       3116

C:\Users\username>taskkill /F /PID 3116
ERROR: The process "3116" not found.

I haven't seen this behaviour before.. and figured it was interesting enough to see if anyone has a solution :)

UPDATE: I started up Process explorer and did a search for 3000 and found this: (3000): 5552

I right clicked on it and chose "Close Handle". It's no longer in Process Explorer, but still shows up in netstat and still stops the app from starting the listener.

UPDATE 2: Found TCPView for Windows ( http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx ) which show the process as "". Like with CurrPorts, nothing happens when I try to close the connection in this tool.

Answer 1

To avoid endless waits on the socket, your program should use the setsockopt function with the SO_REUSEADDR and SO_RCVTIMEO parameters :

SO_REUSEADDR : Allows the socket to be bound to an address that is already in use.
SO_RCVTIMEO : Sets the timeout, in milliseconds, for blocking receive calls. 

Answer 2

I think you ought to give CurrPorts a try

CurrPorts is network monitoring software that displays the list of all currently opened TCP/IP and UDP ports on your local computer. For each port in the list, information about the process that opened the port is also displayed, including the process name, full path of the process, version information of the process (product name, file description, and so on), the time that the process was created, and the user that created it.

In addition, CurrPorts allows you to close unwanted TCP connections, kill the process that opened the ports, and save the TCP/UDP ports information to HTML file , XML file, or to tab-delimited text file.

CurrPorts also automatically mark with pink color suspicious TCP/UDP ports owned by unidentified applications (Applications without version information and icons)

Answer 3

Can you see the process in Process Explorer? If yes than you can kill it from there, but only after you investigate what it actually is (you can see all the dlls loaded into the process)

Answer 4

Try throwing a '-b' flag on your netstat command. It will tell you the name of the executable that is using the port. Then find that proc in task manager and kill it there. If that doesn't work post what the executable is that is holding the port open.

Answer 5

Need to mention the term linger here.

Details can be found at http://msdn.microsoft.com/en-us/library/ms739165.aspx

In brief: There's an option that tells the socket system to keep a socket open even after it has been closed if unsent data is present.

In your C# app you may specify any related options via Socket.SetSocketOption: http://msdn.microsoft.com/en-us/library/1011kecd.aspx

Since all the stuff mentioned is related to sending and clients, but we had similar issues at work, some further searching reveled that one could specify the linger option for listeners as shown in the example over here: http://msdn.microsoft.com/library/system.net.sockets.tcplistener.server.aspx

Some colleagues talked about ports being held by the OS after application termination/closing for about two minutes. Given that, it would be interesting to hear whether the port is still held after a certain amount of time.

Answer 6

I don't suppose you have a firewall installed (or tried any Windows networking tweeks)?

Some firewalls exhibit this sort of behaviour and can keep ports open.

If you do have one, try disabling it and then launching your program and closing it and seeing what happens.

Answer 7

Since your process is listed as System, most likely you can kill it on a "System" command prompt. The System account has more privileges than a regular administrator.

You can a get "System" cmd.exe by scheduling a task for cmd.exe (the scheduler runs as System):

at 15:23 /interactive "cmd.exe" 

Change that time for something in the near future. Make sure as well you're on the machine console (if you are on a regular terminal server session, you won't see the new cmd.exe. Make mstsc login to the console). I guess there other ways to do that, but this worked for me in the past.

Answer 8

The likely problem is that your process has started another (child) process that wasn't terminated before your new instance started.

In this situation some resources - including the bound port - are retained in system tables and not released until all child processes have exited.