When two or more applications try to acquire exclusive access to a network port, they can run into trouble. Just like when two applications try to acquire exclusive access to a local file or a shared file. Sometimes this can happen when an application doesn’t properly cleanup or close its network resources when it shuts down.
A typical symptom of this issue is when you have an application that runs as a Windows Service and you try to stop that service. The service either times out while stopping or even worse it, reports that it stopped successfully, but in either case you still see the process running in the Processes list in Task Manager. When you try to start another instance of the service, the new instance fails to start. Then thirty to sixty seconds after you originally stopped the service, it quietly disappears from the Processes list.
While every application – and every bug – is unique, some times this situation can point to a bug in the application and its use of network resources. The application might not be properly cleaning up its network resources and thus the process simply lingers in the background, desperately clinging to the network socket(s) it opened until Windows decides a timeout has been reached, and the operating system closes the socket, thus letting the app finally exit.
Again, every situation is unique, but here is a technique that can be handy if you get an explicit error message like “System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted”, or if you just have that gut feeling that your application has a bug related to networking and is not closing its port/socket when asked to.
Simply fire up a command prompt and run “netstat -bona”:
Run “netstat -?” for more information on the command line options. The “-bona” set of options is just what I remember the best; it reminds of the “netstat -tuna” command line from my Unix days. 🙂
As you can see in the screenshot, this command will show you a listing of all processes that are using open network ports on the machine including the executable name and the process ID (PID). Unfortunately as you can see here, the output is not very well formed. The executable name is on the line after the port and PID information which makes simple grep’ing or findstr’ing difficult (you can do some context control with grep but that’s not important right now). You still have to do a bit of leg work to see what process(es) are using the port(s) in question.
So if you suspect some sort of network port collision or network resource cleanup issue is affecting your application, use netstat to remove the guesswork.