How can I free a “daemon” TCP port listener, after its owning process exited?

Question

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 k

Answer 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.

Answer 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.