How can I free a “daemon” TCP port listener, after

问题:

Background

I have a .net 4.0 WCF application that listens on net.tcp port 667. (Windows 7 machine)
At some point the application exits ungracefully (the user kills the process, for example).
Now a strange thing happens: The port remains open. When the user re-starts the application, it fails to listen on that port since it's already in use.

The strange thing is that even though the owning process was killed, the OS does not close the port, not even after several hours.

Here are some observations:

• On TcpView the process is <non-existent>, the PID belongs to the old (killed) process, and state is LISTENING. Local address is my machine and there are both IPV4 and IPV6 listeners on that port.
• "Close Connection" and "End Process" operations on TcpView have no effect on that port.
• Process Explorer does not display the old (killed) process. I tried to search-handle for the PID or the port but found nothing.
• When running netstat -a -b -n -o the executable involved is displayed as System and local address is 0.0.0.0. Other info is the same as TcpView.

The only way I found to close that port was a system reboot...

Questions

1. Is there a way to configure the WCF net.tcp Service Host listener to avoid lingering after the process exists ungracefully?
2. Is there a way to programatically close that port? If there is, my application could first close that port before trying to listen to it.
3. Is there a utility that could close such "daemon" ports? (since TcpView cannot do that)
4. Is this an OS bug? Shouldn't the OS keep track of such "daemon" listeners and close them once the process exists?

回答1:

Is there a way to configure the WCF net.tcp Service Host listener to avoid lingering after the process exists ungracefully?

No, at least not that you should use, but there is a way to tell it to reuse the socket address when it restarts, which makes that unnecessary.

Is there a way to programatically close that port? If there is, my application could first close that port before trying to listen to it.

No. Only the application that opened a port can close it.

Is there a utility that could close such "daemon" ports? (since TcpView cannot do that)

No, see above.

Is this an OS bug? Shouldn't the OS keep track of such "daemon" listeners and close them once the process exists?

All the process's resources including TCP ports should be relased when the process exits. There is an exception in the case of TCP 'ESTABLISHED' ports, which hang around for a couple of minutes for TCP security reasons.

It sounds like there is a sub-process that inherited the socket that is still active.

回答2:

It happened to me as well, and actually, I found it is those sub-processes that holding the port. My solution is use Process Explorer to search for the Non-existing PID, and kill all the processes list, then the port will be free.