How do I kill a process that is dead but listening?
Solution 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.
Solution 2
We had the same problem and used Process Explorer from Microsoft Sysinternals to look up the process ID that no longer existed.
It turns out that the process was referenced by several DrWatson processes. Killing those processes released the port. DrWatson is used to send memory dumps to Microsoft and this was taking several hours because the process that crashed held several tens of GBs of memory at the time.
Solution 3
The likely problem is that your process has started another (child) process which inherited the socket handle, and it is still running.
There are various ways to prevent this, for instance: ProcessStartInfo.UseShellExecute = true;
Solution 4
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)
Solution 5
I've tried all solutions commented above and not one worked for me. I've kept researching and I got this answer, which is a combination using @Michael comment and this link https://serverfault.com/questions/181015/how-do-you-free-up-a-port-being-held-open-by-dead-process
-
In the first place, you must find the process that is causing the issue using the port number:
netstat -abno | findstr /i "listening"| find ":3000" TCP 0.0.0.0:3000 0.0.0.0:0 LISTENING 3116
-
secondly, you must find the parent process id (ppid) using code from @Michael
wmic process get processid,parentprocessid | findstr/i 3116 3116 23828
-
Next, you must find the child process ids using the next code
wmic process where (ParentProcessId=23828) get Caption,ProcessId Caption ProcessId wireguard.exe 27400
-
Kill all process starting from the child processes to the parent process
taskkill /f /pid 27400 taskkill /f /pid 3116 taskkill /f /pid 23828
That solved the issue for me.
Related videos on Youtube
Srekel
Updated on September 17, 2022Comments
-
Srekel almost 2 years
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 its 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:
<Non-existent Process>(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 which show the process as
"<non-existent>"
. Like with CurrPorts, nothing happens when I try to close the connection in this tool.-
Xantec over 13 yearsa bit of curing the disease by killing the patient, but does it stop if you restart the computer?
-
Srekel over 13 yearsIn fact, logging out and back in again was enough, but I've now managed to reproduce it so I'd still like to find a better solution...
-
100rabh over 13 yearsCheck if any of the programs listed here help
-
Srekel over 13 yearsSathya, thanks but they didn't. More about files than ports I'm afraid.
-
100rabh over 13 years@Srekel ok.. I've posted an answer, that might help you.
-
harrymc over 13 years@Moshe: See my answer.
-
100rabh over 13 years@srekel any updates ?
-
mmmmmmmm about 11 yearsI have the exact same problem...damn no answer here!
-
Srekel about 11 yearsSorry, I don't think I ever found a solution to the problem and have since left the company. :/
-
Jesse Chisholm about 9 yearsAdd the
/T
option (taskkill /F /T /PID 17888
) to also kill children and the error changes in an interesting way:ERROR The process with PID 17888 (child process of PID 17880) could not be terminated. Reason: There is no running instance of the task.
In this case 17888 is running but 17880 is not. So I have an orphaned process locked by a dead parent. -
Ventzy Kunev about 5 yearsWith current version of TCPView 3.05 "Close connection" from context menu of <non-exsitent> process successfully closed the connection in my case and freed the port.
-
rogerdpack about 5 yearsSee also serverfault.com/questions/181015/…
-
-
Srekel over 13 yearsNot really an option unfortunately, as I don't have control of the firewall on my computer.
-
Srekel over 13 yearsThe ports were held open for much longer than that (don't remember how long but maybe up to an hour before I gave up and rebooted).
-
Srekel over 13 yearsI'm not sure if the linger option is relevant to this particular case, as it seems it only specifies what's supposed to happen after a call to CloseSocket. Since I'm killing the application, I doubt that function gets called(?).
-
Srekel over 13 yearsI can't reproduce it at the moment, but I'm pretty sure that since every other attempt (and tool) at trying to find the name of the process failed, netstat wouldn't have been able to do it either.
-
William Hilsum over 13 years@Srekel - what firewall is it? As you are having problems, I would personally think it is that causing the problems.
-
Harriv over 11 yearsI found this answer at ServerFault helpful: serverfault.com/a/273727/8856
-
Daniel F almost 10 yearsThanks, this was a good one. I was calling
subprocess.call(..., cwd=..., shell=True)
as an app-launcher in a python web server, and it turned out that I had to kill all those child processes to free the socket. The odd thing is that I'm using shell=True. This had me annoyed for ages. -
rustyx almost 7 yearsDid this help anyone with this particular issue (socket listening by a dead process)?
-
qris almost 7 yearsI don't think that using a shell results in this behaviour. If you want to terminate all child processes when the parent dies, I think the correct way is to create a Job Object with the JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE flag, add each child process with AssignProcessToJobObject, and allow the handle to close naturally when the parent process exits.