Part of a very large project we're working on stopped working oh-so-suddenly for one of my colleagues. An exception would be thrown on initializing .NET Remoting - specifically when instantiating a TCP port. Here's part of the exception content:

System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted

at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.StartListening(Object data)
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.SetupChannel()
at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider)
at System.Runtime.Remoting.Channels.Tcp.TcpChannel..ctor(IDictionary properties, IClientChannelSinkProvider clientSinkProvider, IServerChannelSinkProvider serverSinkProvider)

... (deleted)

Running netstat -b proved that some process or another was indeed listening on that particular port, however it failed to say which process is responsible (just said "System".) Running the excellent SysInternals utility TCPView also proved futile, as it displayed a prominent <non-existent process> in the Process column.

As usual, at this point I turned to the 'net; a quick search provided a hypothesis that IIS was somehow responsible for hogging the port; this didn't seem to make sense because IIS was not involved (the channel was not hosted in IIS, nor was it an HTTP channel to begin with) and shutting the IIS services down didn't help any either. Listing the active services via tasklist /svc proved useless as well, as did a reboot.

After some serious searching I picked up this thread in the pgsql.hackers newsgroup; apparently they had similar issues with broken security (AV, firewall) software not uninstalling properly; a lot of security-related software products (called Layered Service Providers, or LSPs) install their own TCP/IP handlers into an appropriate chain in the Windows TCP/IP stack. Although that wasn't the case here, we figured it can't hurt to try the solution pointed to by the newsgroup participants; LSP-Fix is a utility that rebuilds the appropriate registry entries in an effort to restore the handler chain to a working condition. One reboot later and everything was back to normal.

I'm still not clear on the cause of the issue, but this information might prove useful up ahead...