Wie töte ich einen Prozess, der tot ist, aber zuhört?

102728
Srekel

Ich entwickle eine App, die auf Port 3000 lauscht. Offenbar gibt es noch eine Instanz des Ports, denn wenn ich ihn starte, kann er keinen Listener erstellen (C #, TcpListener, aber das ist irrelevant), da der Port bereits vorhanden ist genommen

Da die App im Task-Manager nicht vorhanden ist, habe ich versucht, ihre PID zu finden und zu beenden, was zu diesem interessanten Ergebnis führte:

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. 

Ich habe dieses Verhalten noch nicht gesehen und dachte, es sei interessant genug, um zu sehen, ob jemand eine Lösung hat.

UPDATE: Ich habe den Process Explorer gestartet und nach 3000 gesucht und folgendes gefunden:

<Non-existent Process>(3000): 5552 

Ich habe mit der rechten Maustaste darauf geklickt und "Close Handle" ausgewählt. Es befindet sich nicht mehr im Process Explorer, wird aber weiterhin in netstat angezeigt und verhindert, dass die App den Listener startet.

UPDATE 2: TCPView für Windows gefunden, das den Prozess als anzeigt"<non-existent>" . Wie bei CurrPorts passiert nichts, wenn ich versuche, die Verbindung in diesem Tool zu schließen.

43
ein bisschen die Krankheit durch Töten des Patienten zu heilen, aber hört es auf, wenn Sie den Computer neu starten? Xantec vor 13 Jahren 0
Eigentlich war es genug, sich wieder anzumelden und wieder einzuloggen, aber jetzt habe ich es geschafft, es zu reproduzieren, also würde ich trotzdem gerne eine bessere Lösung finden ... Srekel vor 13 Jahren 2
Überprüfen Sie, ob eines der aufgeführten Programme [hier] (http://superuser.com/questions/66474/cannot-kill-process-in-vista-64) hilfreich ist Sathya vor 13 Jahren 0
Sathya, danke aber nicht. Ich befürchte mehr über Dateien als über Ports. Srekel vor 13 Jahren 0
@Srekel ok .. Ich habe eine Antwort gepostet, die dir vielleicht helfen könnte. Sathya vor 13 Jahren 0
Vielleicht sollten Sie genau prüfen, wie Sie Ihr Abhören am Port implementieren. Möglicherweise handelt es sich um einen Fehler in Ihrer Implementierung oder im Umgang mit C #. (Speicherverwaltung vielleicht?) Moshe vor 13 Jahren 0
@Moshe: Siehe meine Antwort. harrymc vor 13 Jahren 0
@srekel irgendwelche Updates? Sathya vor 13 Jahren 0
Ich habe genau das gleiche Problem ... verdammt keine Antwort hier! mmmmmmmm vor 11 Jahren 0
Sorry, ich glaube nicht, dass ich jemals eine Lösung für das Problem gefunden habe und seitdem das Unternehmen verlassen habe. : / Srekel vor 10 Jahren 0
Fügen Sie die Option `/ T` hinzu (` taskkill / F / T / PID 17888`), um auch Kinder zu töten, und der Fehler ändert sich auf interessante Weise: `ERROR Der Prozess mit PID 17888 (untergeordneter Prozess von PID 17880) konnte nicht beendet werden . Grund: Es gibt keine laufende Instanz der Task. "In diesem Fall läuft 17888, 17880 jedoch nicht. Ich habe also einen verwaisten Prozess, der von einem toten Elternteil gesperrt ist. Jesse Chisholm vor 8 Jahren 0

16 Antworten auf die Frage

13
harrymc

Um endlose Wartezeiten auf den Socket zu vermeiden, sollte Ihr Programm die Funktion setsockopt mit den Parametern SO_REUSEADDR und SO_RCVTIMEO verwenden:

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.  
Hat dies jemandem bei diesem speziellen Problem geholfen (Socket-Abhören durch einen toten Prozess)? rustyx vor 6 Jahren 1
11
David

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.

7
Sathya

Ich denke, Sie sollten CurrPorts ausprobieren

CurrPorts ist eine Netzwerküberwachungssoftware, die die Liste aller aktuell geöffneten TCP / IP- und UDP-Ports auf Ihrem lokalen Computer anzeigt. Für jeden Port in der Liste werden auch Informationen zu dem Prozess angezeigt, der den Port geöffnet hat, einschließlich Prozessname, vollständiger Pfad des Prozesses, Versionsinformationen des Prozesses (Produktname, Dateibeschreibung usw.) und der Uhrzeit Der Prozess wurde erstellt und der Benutzer, der ihn erstellt hat.

Darüber hinaus können Sie mit CurrPorts unerwünschte TCP-Verbindungen schließen, den Prozess beenden, der die Ports geöffnet hat, und die TCP / UDP-Ports-Informationen in HTML-Dateien, XML-Dateien oder in Tabulatoren getrennten Textdateien speichern.

In CurrPorts werden verdächtige TCP / UDP-Ports, die nicht identifizierten Anwendungen gehören, automatisch mit rosa Farbe gekennzeichnet (Anwendungen ohne Versionsinformationen und Symbole).

Alt-Text

Es erscheint in der Liste unter dem Prozessnamen "System". Ich habe versucht, mit der rechten Maustaste auf das Element zu klicken, um das Schließen des Ports zu erzwingen, aber es passiert nichts. Srekel vor 13 Jahren 4
5
Nick Westgate

Das wahrscheinliche Problem besteht darin, dass Ihr Prozess einen anderen (untergeordneten) Prozess gestartet hat, der das Socket-Handle geerbt hat und noch läuft.

Es gibt verschiedene Möglichkeiten, dies zu verhindern, zum Beispiel: ProcessStartInfo.UseShellExecute = true;

Danke, das war ein guter. Ich rief `subprocess.call (..., cwd = ..., shell = True)` als App-Launcher in einem Python-Webserver an, und es stellte sich heraus, dass ich all diese Kindprozesse beenden musste, um die Steckdose. Das Seltsame ist, dass ich shell = True verwende. Das hat mich seit Ewigkeiten geärgert. Daniel F vor 9 Jahren 1
Ich denke nicht, dass die Verwendung einer Shell zu diesem Verhalten führt. Wenn Sie alle untergeordneten Prozesse beenden möchten, wenn das übergeordnete Element stirbt, ist es meiner Meinung nach der richtige Weg, ein [Job-Objekt] zu erstellen (https://msdn.microsoft.com/de-de/library/windows/desktop/ms684161 (v = vs.85) .aspx) mit dem Flag [JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE] (https://msdn.microsoft.com/de-de/library/windows/desktop/ms684147 (v = vs.85) .aspx), fügen Sie jedes untergeordnete Element hinzu verarbeiten Sie mit [AssignProcessToJobObject] (https://msdn.microsoft.com/de-de/library/windows/desktop/ms681949 (v = vs.85) .aspx), und lassen Sie den Griff natürlich schließen, wenn der übergeordnete Prozess beendet wird . qris vor 6 Jahren 0
1
Jakub Konecki

Können Sie den Prozess in Process Explorer sehen ? Wenn ja, dann können Sie es von dort aus töten, aber erst nachdem Sie herausgefunden haben, was es tatsächlich ist (Sie können alle in den Prozess geladenen DLLs sehen)

1
Ge3ng

Versuchen Sie, ein '-b' Flag in Ihrem Befehl netstat zu werfen. Sie erhalten den Namen der ausführbaren Datei, die den Port verwendet. Dann finden Sie diese Prozedur im Task-Manager und beenden Sie sie dort. Wenn das nicht funktioniert, poste die ausführbare Datei, die den Port offen hält.

Ich kann es im Moment nicht reproduzieren, aber ich bin mir ziemlich sicher, dass netstat es nicht geschafft hätte, da bei jedem zweiten Versuch (und Werkzeug), den Namen des Prozesses zu finden, fehlgeschlagen ist. Srekel vor 13 Jahren 0
1
Andreas

Der Begriff Verweilen muss hier erwähnt werden.

Details finden Sie unter http://msdn.microsoft.com/en-us/library/ms739165.aspx

In Kürze: Es gibt eine Option, die das Socket-System anweist, einen Socket offen zu halten, auch wenn er geschlossen ist, wenn noch nicht gesendete Daten vorhanden sind.

In Ihrer C # -App können Sie über Socket.SetSocketOption alle zugehörigen Optionen angeben: http://msdn.microsoft.com/en-us/library/1011kecd.aspx

Da all das, was erwähnt wird, mit dem Senden und Clients zusammenhängt, wir jedoch ähnliche Probleme bei der Arbeit hatten, wurde es einigen Suchenden bewusst, dass man die Verweigerungsoption für Zuhörer angeben könnte, wie im Beispiel hier: http://msdn.microsoft.com /library/system.net.sockets.tcplistener.server.aspx

Einige Kollegen sprachen darüber, dass Ports nach dem Beenden / Schließen der Anwendung für ungefähr zwei Minuten vom Betriebssystem gehalten werden. In Anbetracht dessen wäre es interessant zu erfahren, ob der Port nach einer gewissen Zeit immer noch gehalten wird.

Die Ports wurden viel länger offen gehalten (nicht vergessen, wie lange es dauert, aber vielleicht bis zu einer Stunde, bevor ich aufgab und einen Neustart durchführte). Srekel vor 13 Jahren 0
Ich bin mir nicht sicher, ob die Option "Verweilen" für diesen speziellen Fall relevant ist. Sie gibt anscheinend nur an, was nach einem Aufruf von CloseSocket passieren soll. Da ich die Anwendung abschließe, bezweifle ich, dass die Funktion (?) Aufgerufen wird. Srekel vor 13 Jahren 0
1
lorry.lee

Ich stoße auch auf dieses Problem. Endlich fand ich meinen Grund. Ursache ist, dass der Hauptprozess einen untergeordneten Prozess von popen in c / c ++ aufgerufen hat. Aber der Hauptprozess stürzt ab, bevor das System aufgerufen wird. Dann wird der Port den Hauptprozess noch live abarbeiten und dabei noch zuhören.

Ich fand diese Antwort bei ServerFault hilfreich: http://serverfault.com/a/273727/8856 Harriv vor 11 Jahren 1
1
Christoforos

Ich hatte das gleiche Problem mit xdebug, es ließ Port 9000 offen.

Ich konnte es mit cmd schließen, indem "taskkill / pid xxxx" verwendet wurde.

Die PID des Prozesses, der den Port verwendet, kann mit "netstat -o" abgerufen werden.

Meine Konfiguration war 7 Home Premium.

1
eka808

Ich hatte das gleiche Problem und es wurde behoben durch:

  • Finden der PID mit netstat -o
  • Töte es mit dem Prozess XP

Es ist interessant zu wissen, dass netstat manchmal eine pid zurückgibt, aber nicht den entsprechenden Namen der ausführbaren Datei!