Reputation: 18743
I have a Windows service that - when it starts - opens some WCF services to listen on the 8000 port. It happens that this service crashes sometimes. When it does, the TCP connection is not released, thus causing my service to throw an exception if I try to start it again:
AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:8000
Some observations:
When running CurrPorts or netstat -ano
, I can see that the 8000 port is still in use (in LISTENING
state) and is owned by the Process ID XXX
that corresponded to my service process ID. But my service has already crashed, and does not appear in the Task Manager anymore. Thus I can't kill the process to free the port! Of course, running taskkill /PID XXX
returns:
ERROR: The process "XXX" not found.
When running CurrPorts or netstat -b
, I can see that the process name involved in creating the listening port is System
, and not as MyService.exe
(whereas it is MyService.exe
when my service is running).
I tried to use CurrPorts to close the connection, but I always get the following error message:
Failed to close one or more TCP connections. Be aware that you must run this tool as admin in order to close TCP connections.
(Useless to say, I do run CurrPorts as Administrator...)
TCPView is not much help either: the process name associated to the 8000 port is <non-existent>
, and doing "End process" or "Close connection" has no effect.
I tried to see if there was not a child process associated with the PID XXX
using Process Explorer, but no luck here.
If I close my service properly (before it crashes), the TCP connection is correctly released. This is normal, as I close the WCF service hosts in the OnStop()
event of my service.
The only way I found to release the connection is to restart the server (which is not convenient in a production environment as you can guess). Waiting does not help, the TCP connection is never released.
How can I close the connection without restarting the Windows server?
PS: found some questions extremely similar to mine.
Upvotes: 8
Views: 4390
Reputation: 167
I had the same problem and eventually figured out that the port was being held open by a child process that had been sublaunched by my process. Not sure why none of the system tools could tell me that. Ending the child process frees up the port.
Upvotes: 2
Reputation: 11
I suggest you trying socket.ExclusiveAddressUse=false; Althought isn't usually intended to solve this kind of probelms.
Another work-around - locate the other service process and kill it manually in your very first code lines.
Upvotes: 0