55

I have discovered a running process with PID 26376 listening on port 9001 and 9002 as when I try to run my program(as a service) which binds to that port it fails.

But when I try to kill it using taskkill /PID it says that the process 26376 is not found. Similarly when I try to find the process in task manager with "Show processes from all users" selected, I couldn't find it anywhere.

Can anyone explain this? Is it a defunct zombie process? I suspect that the process listening on that port is a previous instance of my program running but what could have caused this?

EDIT: Sysinternals TCPView shows the process as non-existent. Sysinternals Process Explorer does not show the process. Tasklist does not show the process.

shawn
  • 3,713
  • 6
  • 32
  • 53
  • 4
    This post seems to solve your problem: [http://superuser.com/questions/191416/pid-number-in-task-manager-cant-be-found][1] [1]: http://superuser.com/questions/191416/pid-number-in-task-manager-cant-be-found – zzk Mar 05 '13 at 06:07
  • 1
    Process explorer does not show it and neither does Tasklist, only TCPView shows that the process is non-existent but the port is still tied up – shawn Mar 05 '13 at 07:20
  • How long is it tied-up for? It could be the linger socket option. – cdarke Mar 05 '13 at 08:23
  • Many days, I did not specifically set the linger option, it is not on by default I suppose? – shawn Mar 05 '13 at 08:39
  • It seems to me, Linger is not going to last for days. If I understand you correctly, the program that would normally use the ports is yours (not a commercial program or malware). Does some other program perhaps have a reference to the process's handle? For example, if your service can also be launched by another program of yours? – cardiff space man Mar 05 '13 at 10:06
  • yes, the same program is running on another machine and starts it up by the SCM RMI – shawn Mar 05 '13 at 10:22
  • Linger is usually set by default, but it won't be linger, it should only be a few minutes (typically 10). Justa thought. – cdarke Mar 05 '13 at 11:02
  • Best guess is that a previous process has a stuck kernel thread. Unfortunately, the only resolution I know of is to reboot. – Harry Johnston Mar 05 '13 at 21:03
  • @shawn John I also facing same issue.please let me know how resolved the issue.My app also create child process to compress and decompress file using 7za.child donot use socket as such but they inherit the socket since CreateProcess bInheritHandles=TRUE.Do I need to make this flag FALSE.PLease suggest. – Chris_vr Sep 15 '14 at 13:57
  • It may show in your details tab on task manager ( For me it shows on the Details tab other than Services) – Prasad Gayan Jan 04 '21 at 06:06

4 Answers4

5

You don't need Task Manager for tracking this. Just run netstat -b which will display the exe associated with the PID..

Parth Mody
  • 428
  • 1
  • 4
  • 16
4

Well, in my case killing all the conhost.exe instances owned by the same user as the initial process released the port.

mfck
  • 41
  • 1
  • 1
    Didn't work for me! Port is still in use and PID is reported by netstat, but it's not shown up in task manager and it's not possible to kill it with taskkill and tskill. – Alireza Mirian Jun 14 '18 at 09:37
0

(improved from @mfck's answer)

  1. kill all processes named cmd.exe
  2. kill all processes named conhost.exe
ch271828n
  • 5,683
  • 3
  • 24
  • 44
0

Another option is to bounce the NIC associated with the connection. Be careful if you are doing this over RDP, you'll want to script it so the NIC will come back online or you'll lock yourself out and will need console access.

This link explains how to do it with CMD and powershell:

https://www.windowscentral.com/how-enable-or-disable-wi-fi-and-ethernet-network-adapters-windows-10

Blaise Brignac
  • 1
  • This won't work for LISTENING sockets on the wildcard address (0.0.0.0). They aren't associated with a specific network interface. – cdhowie Oct 20 '19 at 03:24