如何在退出拥有进程后释放"守护进程"TCP端口侦听器？

Question

背景

我有一个.net 4.0 WCF应用程序,它在net.tcp端口667上进行侦听.(Windows 7机器)
某些时候,应用程序会以非正常方式退出(例如,用户会终止该进程).
现在发生一件奇怪的事情:港口仍然开放.当用户重新启动应用程序时,它无法侦听该端口,因为它已在使用中.

奇怪的是,即使拥有进程被杀死,操作系统也不会关闭端口,即使在几个小时后也没有.

以下是一些观察结果:

• 在TcpView上进程是<non-existent>,PID属于旧的(被杀死的)进程,状态是LISTENING.本地地址是我的机器,该端口上有两个IPV4和IPV6监听器.
• TcpView上的"关闭连接"和"结束进程"操作对该端口没有影响.
• Process Explorer不显示旧(已终止)进程.我试图搜索PID或端口但没有找到任何东西.
• 运行netstat -a -b -n -o所涉及的可执行文件时显示为System 和本地地址0.0.0.0.其他信息与TcpView相同.

我发现关闭该端口的唯一方法是系统重启...

问题

1. 有没有办法配置WCF net.tcp服务主机监听器,以避免在进程不正常后存在延迟？
2. 有没有办法以编程方式关闭该端口？如果有,我的应用程序可以先尝试关闭该端口,然后再尝试收听它.
3. 是否有可以关闭此类"守护程序"端口的实用程序？(因为TcpView无法做到这一点)
4. 这是操作系统错误吗？操作系统是否应该跟踪这些"守护程序"监听器并在进程存在后关闭它们？

Answer 1

有没有办法配置 WCF net.tcp 服务主机侦听器以避免进程不正常存在后出现延迟？

不，至少不应该使用，但是有一种方法可以告诉它在重新启动时重用套接字地址，这使得没有必要。

有没有办法以编程方式关闭该端口？如果有，我的应用程序可以先关闭该端口，然后再尝试监听它。

不可以。只有打开端口的应用程序才能关闭它。

是否有实用程序可以关闭此类“守护程序”端口？（因为 TcpView 无法做到这一点）

不，请参阅上文。

这是操作系统错误吗？操作系统不应该跟踪此类“守护进程”侦听器并在进程存在后关闭它们吗？

当进程退出时，应该释放进程的所有资源，包括 TCP 端口。TCP“ESTABLISHED”端口有一个例外，出于 TCP 安全原因，该端口会挂起几分钟。

听起来好像有一个子进程继承了仍然处于活动状态的套接字。