Я разрабатываю приложение, которое прослушивает порт 3000. Очевидно, есть экземпляр, который все еще слушает порт, потому что всякий раз, когда я запускаю его, он не может создать прослушиватель (C #, TcpListener, но это не имеет значения), потому что порт уже приняты.
Теперь приложение не существует в диспетчере задач, поэтому я попытался найти его PID и убить его, что привело к интересному результату:
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. Я не видел такого поведения раньше и подумал, что это достаточно интересно, чтобы увидеть, есть ли у кого-нибудь решение.
ОБНОВЛЕНИЕ: я запустил Process Explorer, выполнил поиск 3000 и нашел это:
<Non-existent Process>(3000): 5552 Я щелкнул правой кнопкой мыши по нему и выбрал «Закрыть ручку». Его больше нет в Process Explorer, но он все еще отображается в netstat и все еще не позволяет приложению запустить слушатель.
ОБНОВЛЕНИЕ 2: Найден TCPView для Windows, который показывает процесс как "<non-existent>". Как и в случае с CurrPorts, ничего не происходит, когда я пытаюсь закрыть соединение в этом инструменте.
Чтобы избежать бесконечного ожидания в сокете, ваша программа должна использовать функцию setsockopt с параметрами SO_REUSEADDR и SO_RCVTIMEO:
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. 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.
Я думаю, вы должны попробовать CurrPorts
CurrPorts - это программное обеспечение для мониторинга сети, которое отображает список всех открытых на данный момент портов TCP / IP и UDP на вашем локальном компьютере. Для каждого порта в списке также отображается информация о процессе, открывшем порт, включая имя процесса, полный путь процесса, информацию о версии процесса (название продукта, описание файла и т. Д.), Время, в течение которого процесс был создан, и пользователь, который создал его.
Кроме того, CurrPorts позволяет закрывать нежелательные TCP-соединения, завершать процесс, который открыл порты, и сохранять информацию о портах TCP / UDP в файл HTML, файл XML или текстовый файл с разделителями табуляции.
CurrPorts также автоматически помечает розовым цветом подозрительные порты TCP / UDP, принадлежащие неопознанным приложениям (приложения без информации о версии и значков)
Вероятная проблема состоит в том, что ваш процесс запустил другой (дочерний) процесс, который унаследовал дескриптор сокета, и он все еще выполняется.
Существует несколько способов предотвратить это, например: ProcessStartInfo.UseShellExecute = true;
Можете ли вы увидеть процесс в Process Explorer ? Если да, то вы можете убить его оттуда, но только после того, как вы исследуете, что это на самом деле (вы можете увидеть все dll, загруженные в процесс)
Попробуйте добавить флаг -b в команду netstat. Он скажет вам имя исполняемого файла, который использует порт. Затем найдите этот процесс в диспетчере задач и убейте его там. Если это не сработает, напишите, какой исполняемый файл удерживает порт открытым.
Нужно упомянуть термин задержаться здесь.
Подробности можно найти на http://msdn.microsoft.com/en-us/library/ms739165.aspx
Вкратце: есть опция, которая сообщает системе сокетов держать сокет открытым даже после его закрытия, если присутствуют неотправленные данные.
В вашем приложении C # вы можете указать любые связанные параметры через Socket.SetSocketOption: http://msdn.microsoft.com/en-us/library/1011kecd.aspx
Поскольку все упомянутое относится к отправке и клиентам, но у нас были похожие проблемы в работе, некоторые дальнейшие поиски показали, что можно указать опцию linger для слушателей, как показано в примере здесь: http://msdn.microsoft.com /library/system.net.sockets.tcplistener.server.aspx
Некоторые коллеги говорили о том, что порты удерживаются ОС после завершения / закрытия приложения в течение примерно двух минут. Учитывая это, было бы интересно узнать, удерживается ли порт по прошествии определенного времени.
Я также сталкиваюсь с этой проблемой. Наконец я нашел причину. Это вызвано тем, что основной процесс вызывает дочерний процесс с помощью popen в c / c ++. Но основной процесс сбоя / выключения перед вызовом pclose. Тогда порт будет обрабатывать основной процесс еще живым и все равно слушать его.
I had the same problem with xdebug, it left port 9000 open.
I managed to close with cmd using "taskkill /pid xxxx".
The pid of the process using the port can be retrieved with "netstat -o".
My configuration was win 7 home premium.
I had the same problem and fixed it by :
netstat -oInteresting to note that netstat can sometimes return a pid but not the corresponding executable name !