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