web-dev-qa-db-fra.com

Le PID existe dans netstat mais n'existe pas dans le gestionnaire de tâches

J'ai découvert un processus en cours avec le PID 26376 à l'écoute sur les ports 9001 et 9002 lorsque je tente d'exécuter mon programme (en tant que service) qui se lie à ce port, il échoue.

Mais lorsque j'essaie de le tuer à l'aide de taskkill/PID, il indique que le processus 26376 n'est pas trouvé. De même, lorsque j'essaie de trouver le processus dans le gestionnaire de tâches avec l'option "Afficher les processus de tous les utilisateurs" sélectionnée, je ne le trouve nulle part.

Quelqu'un peut-il expliquer cela? Est-ce un processus de zombie défunt? Je soupçonne que le processus d'écoute sur ce port est une instance antérieure de mon programme en cours d'exécution, mais qu'est-ce qui pourrait en être la cause?

EDIT: Sysinternals TCPView affiche le processus comme inexistant . Sysinternals Process Explorer n’affiche pas le processus . La liste des tâches n’affiche pas le processus.

windowsservicenetwork-programming
43
shawn

Vous n'avez pas besoin du gestionnaire de tâches pour suivre cela. Il suffit d’exécuter netstat -b qui affichera le fichier exe associé au PID.

4
Parth Mody

Eh bien, dans mon cas, toutes les instances conhost.exe appartenant au même utilisateur que le processus initial ont été libérées.

4
mfck

Une autre option consiste à faire rebondir le NIC associé à la connexion. Soyez prudent si vous faites cela sur RDP, vous voudrez le script pour que la NIC revienne en ligne ou vous allez vous verrouiller et avoir besoin d'un accès à la console.

Ce lien explique comment procéder avec CMD et powershell:

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

0
Blaise Brignac

(amélioré de la réponse de @ mfck)

  1. tuer tous les processus nommés cmd.exe
  2. tuer tous les processus nommés conhost.exe
0
fzyzcjy