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.
Nice article – port # problems are almost always hard to find unless you know to look for them.
There is a SysInternals tools that provides a nice graphical look at the ports and gives a bit more info than you can easily digest: TCPView – http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx
This updates in real-time which can be helpful.connected/disconnected.
For this job I like use TcpView:
http://technet.microsoft.com/en-us/sysinternals/bb897437
Awesome, thanks guys! It’s funny, I’ve been a big fan of the SysInternals tools for a long time but never noticed TCPView before. I’ll definitely have to integrate that into my toolbelt. Thanks again!
Another plug for TcpView. It’s also nice in that it allows you to forcefully exit the process or close an open connection. (Oddly came up last week with respect to a badly behaving application)
Well, I have installed and run the TcpView, but could not find out what/who is using my com port 4. How to identify it??
Hi Radi, sorry, but I’m not sure how to determine what’s using a COM port (the tools we’re discussing here are specific to network ports).
Hi Russ,
Thanks for the reply. I will have to search somewhere else as I see my COM4 active and have no application using it opened!
Best regards,
Radi