As a Windows administrator, you often need to monitor active TCP/IP ports to determine which network application server ports are active, ensure that ports aren't open unexpectedly, and find out which remote systems a computer is accessing. You can use Windows' built-in Netstat tool to obtain such information, but Netstat has several limitations. The version that comes with Windows 2000 and earlier doesn't report the process associated with an endpoint; the version that comes with Windows Server 2003 and Windows XP shows the owning process's process identifier (PID) but not the process's image name. These limitations make it difficult to determine which process owns an open network port. Furthermore, Netstat doesn't provide a convenient way to see changes in TCP/IP port use.
Sysinternals' TCPView—a free GUI application that runs on Windows NT 4.0 and later—displays a superset of the information that Netstat shows and gives you an easy way to monitor changes to port use over time. You can download TCPView and its command-line equivalent, TCPVCon, at http://www.sysinternals.com.
Endpoint Basics
When you run Netstat without any command-line arguments, it prints a list of TCP endpoints that are in a connected state, along with each connection's locally bound IP address and the IP address of the connection's remote side. (Because TCP is a connection-oriented protocol, TCP communication requires both sides of a data exchange to establish a connection for the duration of the exchange.)
Netstat's -a option lists all active TCP and UDP endpoints, including TCP endpoints in other states such as LISTENING (waiting for a connection) and TIME_WAIT (closed). UDP is a connectionless protocol, so UDP messages can be sent from a UDP endpoint to any remote IP address. Therefore, UDP endpoints have no state and no concept of a statically bound remote IP address.
The version of Netstat that ships with Windows 2003 and XP offers the -o option, which prints the PID of the process that opened each endpoint. However, when you use the -o option, you must use another tool, such as Task Manager, to map the PID to an image name.
XP Service Pack 2 (SP2) introduced another new Netstat switch—the -b switch—which will also be supported in Windows 2003 SP1. This switch displays the owning image name below an endpoint's output line. For endpoints opened by a svchost.exe or rundll.exe process, this switch also display the names of the DLLs that were on the stack of the thread that opened the endpoint. (Note that Netstat Help text refers to DLLs as components.) Because Svchost is a host process that loads Windows services that are implemented in DLLs, and Rundll32 is the Control Panel host process for Control Panel DLL plug-ins, DLL information can help you identify which service or Control Panel applet opened an endpoint. Unfortunately, a flaw in the way that Netstat examines stack data slows down its output so much that the -b switch is all but unusable.
TCPView
TCPView, which Figure 1 shows, displays all the basic endpoint information that Netstat does. But take a look at the Process column, which displays the icon, name, and PID of the process that owns each endpoint.
For cases in which an image name is ambiguous, TCPView offers more information about the process. To view this information, double-click an endpoint owned by the process, or select the endpoint and choose Process Properties from the Process menu to access the process's Properties dialog box, which Figure 2 shows. This dialog box displays the full path to the process image file, the command that was used to launch the process, and several pieces of information that TCPView pulls from the image's version data (if available): the image's description, vendor name, and version number.
To translate a DNS name (e.g., www.winntmag.com:http) to its underlying IP address and port number, simply press Ctrl+R, click the tool's address-translation toolbar button, or select Resolve Addresses from the Options menu. TCPView will switch to a numeric view for all addresses; you can use the same methods to toggle back to name resolution.
If you leave TCPView running, you might notice endpoint rows temporarily highlighted in red, green, or yellow. The tool uses these colors to call your attention to changes that occur. Newly opened endpoints will be highlighted in green, endpoints that have been closed will be highlighted in red, and TCP endpoints that have changed state will be highlighted in yellow. These colors remain in place for three refreshes of the display. TCPView's default refresh interval is 1 second, but you can change that interval or pause the refresh altogether by using the View, Update Speed option.
You can also use the tool to close an application's established TCP connection. To do so, select the connection's row and select File, Close Connections; alternately, you can right-click an entry and choose Close Connections from the context menu.
TCPVCon
TCPVCon is the command-line version of TCPView. Like Netstat, TCPVCon simply displays connected TCP endpoints when you run it without specifying any command-line arguments, or it displays all endpoints when you include the -a option. But unlike Netstat, TCPVCon formats its output in a standard 80-column command-prompt window, as Figure 3 shows, for easy reading. Another difference between Netstat and TCPVCon is that TCPVCon always prints the full path and PID of each endpoint's process, rather than just the image name. If you're interested in the TCP/IP endpoints of a particular process, you can specify the process name or PID on the TCPVCon command-line and the tool will dump the endpoints for that process only. You can use the tool's -c switch to produce output in comma-separated value (CSV) format. This capability lets you use TCPVCon as a simple auditing tool to generate data for storage in a database that you can query later.
Inside the Tools
When you use TCPView and TCPVCon on Windows 2003 or XP, the tools use undocumented functions (introduced in XP) to obtain TCP/IP endpoint information, including the PID of the process that opened each endpoint. The tools also use documented process-enumeration functions to obtain a list of processes so that they can convert PIDs to process names. To obtain detailed information about a process, you must run the tools from an account that has the Debug programs privilege.
In Win2K and NT, the tools rely on undocumented interfaces to query endpoint information. Because these earlier interfaces don't supply PID information, the tools use an embedded device driver that they install upon startup to map endpoints to processes. Therefore, to use the tools on Win2K or NT, the account must have both the Debug programs and Load drivers privileges.
A Clearer View
If you're tired of Netstat's limitations, TCPView and TCPVCon can be useful additions to your systems-administration toolkit. The tools' ability to show process image names and information, close connections, and highlight changes will save you time and give you a clearer view of your system's network use.
