6

背景

我有一个 .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. 这是操作系统错误吗？操作系统不应该跟踪此类“守护程序”侦听器并在进程存在后关闭它们吗？
4

2 回答 2

2

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

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

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

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

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

不，见上文。

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

进程退出时，应释放包括 TCP 端口在内的所有进程资源。TCP 'ESTABLISHED' 端口有一个例外，出于 TCP 安全原因，它会停留几分钟。

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

于 2012-09-11T09:44:52.350 回答
0

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.

于 2013-01-17T01:15:42.237 回答