87

A colleague of mine recently ran into a problem where a process that had supposedly died was still bound to a network port, preventing other processes from binding to that port. Specifically, netstat -a -b was reporting that a process named System with PID 4476 had port 60001 open, except no process with PID 4476 existed, at least as far as I could tell.

Process Explorer and Task Manager did not list PID 4476 (though there was another process named System with PID 4, which had its own set of TCP connections that did not include 60001). taskkill /PID 4476 also reported that PID 4476 could not be found.

Is there a way to kill this mysterious System process to free up the port to which it's currently bound? What can cause this to happen? How can there be processes that none of Task Manager, Process Explorer, and taskkill don't know about? Rebooting managed to fix the problem, but I'd like to know if there's a way to fix this without rebooting.

Adam Rosenfield
  • 970
  • 1
  • 6
  • 6
  • How long did you wait to see if the port was released? What state was the connection (port) in? Established, Closed, Time_Wait? – joeqwerty Sep 14 '10 at 14:45
  • @joeqwerty: We waited at least 15-20 minutes. Unfortunately I forget what state the connection was in =/. – Adam Rosenfield Sep 14 '10 at 14:46
  • 20 minues sounds like a problem. The next time it occurs run netstat and check the state of the connection, that will give you a clue as to what's happening. As you commented to mfinni's answer though, it may be a result of your software\service crashing. – joeqwerty Sep 14 '10 at 15:06

6 Answers6

73

I know this is an old thread, but in case anyone else is having the same issue, I had...

What may be happening is that your process had a TCP port open when it crashed or otherwise exited without explicitly closing it. Normally the OS cleans up these sorts of things, but only when the process record goes away. While the process may not appear to be running any more, there is at least one thing that can keep a record of it around, in order to prevent reuse of its PID. This is the existence of a child process that is not detached from the parent.

If your program spawned any processes while it was running, try killing them. That should cause its process record to be freed and the TCP port to be cleaned up. Apparently windows does this when the record is released not when the process exits as I would have expected.

Ogapo
  • 831
  • 6
  • 2
  • 1
    Thank you, good sir. I can't believe this answer is so low, especially since the google query is filled with answers "use TCPView/use netstat & taskkill" that do not help in this case. In my case what helped was running ProcessExplorer and looking for any process that had been orphaned. Shutting them down solved the problem. – gwiazdorrr Jun 18 '12 at 09:13
  • 3
    Thanks for your hint!! Killing orphand process really solved the problem. – Darkthread May 22 '13 at 03:34
  • Thanks!! This was exactly what had happened to me. I killed the orphaned process and the port was released. I'm not sure how to search for orphaned processes using process explorer, but I knew the names of the processes that were spawned so it was easy to find. – Grezzo Jul 16 '14 at 14:50
  • 1
    We had this same issue -- and using Process Explorer saw that Dr. Watson was holding onto the old PID. We searched (Find) for the port that the service was attempting to open, and then saw 3-4 entries for Dr. Watson and the PID it was using. Strangely enough, we didn't have to implicitly KILL anything. Seems like that process 'woke it up' and it disappeared. Next time we tried to restart the service, it came up fine. – tresstylez Nov 20 '14 at 20:47
  • Similar issue can happens during debugging with VS. I'm attach VS to process, and after some cycles - described situation happens, but no my processes (including childs) leaves. But killing "vsjitdebugger" helps. – Dmitry Azaraev Jul 10 '17 at 03:05
13

Open command prompt as admin

  1. C:\WINDOWS\system32>netstat -ano | findstr :7895

*** Repeat step 2 until there are no more child process

  1. C:\WINDOWS\system32>wmic process where (ParentProcessId=1091 ) get Caption,ProcessId

    Caption ProcessId

    cmd.exe 1328

2.a. C:\WINDOWS\system32>wmic process where (ParentProcessId=1328) get Caption,ProcessId

  Caption  ProcessId

  conhost.exe  1128

2.b. repeat this until no further child processes found

-- Then kill all child processes

  1. C:\WINDOWS\system32>taskkill /F /PID 1128 SUCCESS: The process with PID 9500 has been terminated.
Srinivas
  • 131
  • 1
  • 2
  • The wmic command was the only way we managed to identify the child process actually keeping our ports open. Many thanks. – K Erlandsson Nov 30 '18 at 10:24
  • This was also the only way I found to fix my issue. The main process was gone and child process was on a suspended state, but was still holding the TCP port with a "Listening" state. Thank you. – Gui Mar 27 '19 at 16:06
7

Did you try using TCPView and closing the connection? I don't know if it will show the connection in the scenario you're describing, because I've never had that happen to me. But it's the only thing I can think of if this happens again.

What was the process - was it commercial software, or something homegrown? It appears that port 60001 is used by some Trojans - I wonder if it could have been a rootkit or something that could hide itself from the OS? Might want to give that machine a good once-over with AV, maybe something from bootable media.

mfinni
  • 35,711
  • 3
  • 50
  • 86
  • No, we didn't try TCPView; I'll keep that in mind for the future if it ever happens again. The software is our in-house software that uses port 60001 -- I'm almost certain that the process holding the port open was a previous instance of our software that somehow didn't quite fully die. That prevented another copy of the software from launching. – Adam Rosenfield Sep 14 '10 at 14:51
  • Your application can set the SO_REUSEADDR option of the socket to true before binding it. That should solve your problem (it's even more or less mandatory on *nix) – Stephane Sep 14 '10 at 15:06
1

I have faced the same issue earlier, netstat -a -n windows command gave me the list of open ports with process ID. From that i have picked up the port number which i wanted to close the connection and then i closed that connection using TCPView software. This worked for me.

Elavarasi
  • 11
  • 1
-4

If you are windows user then follow below steps Step1: Go to this path: Control Panel\All Control Panel Items\Administrative Tools

Step2: Click on services

Step3: Stop unwanted services running on desired port.

user314053
  • 1
-5

ps -ef | grep processname

kill the related processes

kill -9 pid pid

Worked in my case

java geek
  • 1
  • 3