Я сталкиваюсь с постоянной проблемой, когда TCP порт остается в состоянии LISTENING, но процесс, который его выделил, не удается найти. Это происходит даже тогда, когда приложение, изначально использовавшее порт, больше не работает. Перезагрузка компьютера решает проблему, но мне нужен способ, который не включает в себя перезапуск Windows.

Проблема:

• Запуск netstat -ano | findstr :1041 показывает, что порт находится в состоянии LISTENING с PID (например, 13536).

• Когда я пытаюсь завершить процесс с помощью taskkill /PID 13536 /F , я получаю ошибку:

  ERROR: Process "13536" not found.
  

• Повторный запуск команды netstat показывает, что порт все еще находится в состоянии LISTENING с тем же PID, даже если процесс якобы не существует.

Я попробовал следующие решения без успеха:

1. Проверить активные соединения:

   netstat -ano | findstr :1041
   

   Это только подтверждает, что порт открыт, но не показывает действительный процесс.

2. Завершить процесс по PID:

   taskkill /PID 13536 /F
   

   Но процесс не найден.

3. Перезагрузить стэк TCP/IP без перезагрузки:

   netsh int ip reset
   netsh winsock reset
   

   Это не помогло.

4. Перезапустить службу NDU (Network Data Usage Monitoring Driver):

   sc stop ndu
   sc start ndu
   

   Проблема сохраняется.

   Даже с привилегиями SYSTEM процесс не найден.

5. Проверить настройки проброса портов или прокси:

   netsh interface portproxy show all
   netsh interface portproxy reset
   

   Ничего не было настроено.

6. Попытаться удалить процесс через WMI:

   wmic process where "ProcessId=13536" delete
   

   Процесс не был найден.

7. Использовать TCPView и Process Explorer от Sysinternals:

   • Порт отображается как LISTENING, но к нему не привязан никакой процесс.

Эта проблема с призрачным процессом происходит случайным образом, обычно после падения моего приложения или принудительного завершения. Единственное решение, которое работает, это перезагрузка машины, что не является идеальным.

Вопрос:

• Как я могу принудительно освободить порт без перезапуска Windows?

• Есть ли способ сбросить или очистить порты, которые застряли в LISTENING без активного процесса?

Буду признателен за любые предложения или альтернативные подходы!

Редактировать:
Спасибо @Massimo за совет.

А также спасибо за ничего модераторам, которые закрыли тему с невероятной скоростью.

Ответ

1. Определите используемый порт и найдите соответствующий PID:

netstat -ano | findstr :1041

Пример вывода:

  TCP    0.0.0.0:1041           0.0.0.0:0              LISTENING       14392

В данном случае PID 14392.

2. Отследите родительский процесс для PID:

wmic process get processid,parentprocessid | findstr/i 14392

Пример вывода:

14392            9584

Здесь 9584 это родительский процесс для 14392.

3. Проверьте дочерние процессы под этим родительским процессом:

wmic process where (ParentProcessId=9584) get Caption,ProcessId

Пример вывода:

Caption      ProcessId
conhost.exe  38776

Это выявило процесс conhost.exe с PID 38776.

4. Завершите выявленный процесс:

taskkill /f /pid 38776

Пример вывода:

SUCCESS: The process with PID 38776 has been terminated.

После этого порт был освобожден, и я мог перезапустить приложение без перезагрузки системы.

Основной вывод:

В некоторых случаях процесс, занимающий порт, может не появляться напрямую в tasklist или через taskkill с начальным PID. Однако путем отслеживания родительского процесса и завершения его дочерних процессов (например, conhost.exe), проблема может быть решена без перезагрузки Windows.

Надеюсь, это поможет кому-то, кто сталкивается с подобной проблемой «призрачного процесса»!

Это может быть вызвано приложением, не закрывающим правильно слушающий сокет; см. например здесь:

https://superuser.com/questions/215351/how-do-i-kill-a-process-that-is-dead-but-listening
https://stackoverflow.com/questions/9024090/winsock-tcp-listener-stays-in-listening-state-after-successful-closesocket-cal

Поскольку вы упоминаете, что это происходит после падения моего приложения или принудительного завершения, это действительно похоже на то, что происходит.

Вам следует исследовать почему ваше приложение не может правильно освободить сокет при завершении работы.