如何在退出拥有进程后释放“守护进程”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服务主机监听器，以避免在进程不正常后存在延迟？

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

  

有没有办法以编程方式关闭该端口？如果有，我的应用程序可以在尝试收听之前先关闭该端口。

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

  

是否有可以关闭此类守护进程的实用程序＆＃34;端口？ （因为TcpView不能这样做）

不，见上文。

  

这是操作系统错误吗？操作系统不应该跟踪这样的＆＃34;守护进程＆＃34;听众并在进程存在后将其关闭？

当进程退出时，应该重新启动包括TCP端口在内的所有进程资源。在TCP＆＃39; ESTABLISHED＆＃39;的情况下有一个例外。端口，出于TCP安全原因，它会挂起几分钟。

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

Answer 2

它也发生在我身上，实际上，我发现是那些持有端口的子进程。我的解决方案是使用Process Explorer搜索不存在的PID，并终止所有进程列表，然后该端口将是空闲的。