Using the TCP/IP Tab in Process Explorer
Learn how to inspect a process's active TCP and UDP endpoints, connection states, local and remote ports, and hostname resolution in Process Explorer.
The TCP/IP tab in Process Explorer shows the active network endpoints associated with a selected Windows process. It helps you connect a process to its TCP connections, listening services, and UDP activity.
Use the tab for troubleshooting application network behavior, checking local listeners, and investigating unexpected outbound connections. Endpoint information is evidence to evaluate with the process identity, executable path, configuration, and expected role—not proof of a problem by itself.
What the TCP/IP Tab Shows
The TCP/IP tab is one of the tabs in a process's Process Properties window. It associates network sockets with the process that owns them and displays currently active TCP and UDP endpoints.
An endpoint is a network socket identified by a protocol, address, and port. A socket is an operating-system networking object that a process uses to send or receive traffic.
- A TCP connection can show a local endpoint, a remote endpoint, and a connection state.
- A TCP listening endpoint waits for inbound connection requests.
- A UDP endpoint can send or receive datagrams without creating a TCP-style connection.
- One process can have many rows because it communicates with multiple services or listens on multiple ports.
Open the TCP/IP Tab
- Find the target process in the main Process Explorer list.
- Select the process.
- Open its Process Properties window, such as by double-clicking the process or using the process properties command.
- Choose the TCP/IP tab.
The tab only has useful rows when the process currently owns relevant active endpoints. A process may have no entries because it does not use the network, because its connection ended, or because the activity is too short-lived to observe.
Network Endpoint Rows
Each row represents an active socket or connection owned by the selected process. A TCP row in LISTENING state represents a local service waiting for clients. A TCP row in ESTABLISHED state represents an active peer-to-peer connection. UDP rows describe datagram endpoints and may not have a meaningful remote peer.
A listener is not the same as an established session. A listener may have no remote address because no client has connected yet. After a client connects, a separate established connection can appear with both local and remote endpoint details.
TCP and UDP
TCP, or Transmission Control Protocol, is a reliable, connection-oriented transport protocol. It creates a connection between two endpoints and uses states such as LISTENING and ESTABLISHED.
UDP, or User Datagram Protocol, is a connectionless transport protocol. It sends individual datagrams without the TCP connection setup and teardown process. A UDP entry may show only a local address and port, or it may show peer information when the application uses a specific destination.
Connection-state interpretation primarily applies to TCP. Do not expect every UDP row to have an equivalent TCP-style state or a permanent remote endpoint.
TCP/IP Tab Fields and Their Meaning
| Field | What It Shows | How to Interpret It |
|---|---|---|
| Protocol | TCP or UDP | TCP normally has connection states; UDP is connectionless and can display peer information differently. |
| State | The current TCP lifecycle state | Use it to determine whether the process is listening, connecting, exchanging data, or closing a connection. It is mainly meaningful for TCP. |
| Local Address | The local IP address or interface used by the endpoint | Shows which address on the Windows computer is involved. A wildcard address can mean all local interfaces. |
| Local Port | The port used by the selected process on the local computer | May be a well-known service port for a listener or an automatically assigned ephemeral port for a client connection. |
| Remote Address | The peer IP address or resolved hostname | Identifies the other system for a connection. It may be absent or uninformative for a listener or some UDP endpoints. |
| Remote Port | The port used by the remote peer | Helps identify the remote service and complete the local-to-remote endpoint pair. |
Understanding TCP Connection States
| State | Meaning | Typical Troubleshooting Interpretation |
|---|---|---|
| LISTENING | A local TCP endpoint is waiting for inbound connection requests. | Check whether the process should provide a service and which local address and port it exposes. |
| SYN_SENT | The process has started a TCP connection attempt and is waiting for a response. | The remote host may be unreachable, filtering the port, or slow to respond. |
| SYN_RECEIVED | A connection request has been received and the local system is waiting to complete the handshake. | Shows an inbound connection attempt that is not yet fully established. |
| ESTABLISHED | The TCP connection has been created and can exchange data. | Use the local and remote endpoint pair to identify the active session. |
| CLOSE_WAIT | The remote peer has closed its side, but the local application has not fully closed its socket. | A brief occurrence can be normal; persistent entries may indicate an application cleanup problem. |
| TIME_WAIT | A recently closed TCP connection is being retained temporarily to handle delayed packets. | Short-lived entries are normal after connections close; many entries can be relevant during high connection churn. |
ESTABLISHED is the state most often used to identify active data exchanges. However, a process can be working correctly while a connection is in a transitional state, and a connection can disappear between refreshes.
Local Address and Local Port
The local address identifies the IP address or interface on the Windows computer used by the endpoint. A specific address indicates a particular interface. A wildcard or all-interface binding means the process is prepared to accept traffic through multiple local interfaces, subject to firewall and application rules.
The local port identifies the application-side port. Server applications commonly use recognizable service ports, while outbound clients usually receive an ephemeral port—a temporary port assigned automatically for a connection.
For example, a browser might use local address 192.0.2.25 and local port 51432. The high-numbered port is likely a temporary client port rather than the web service port.
Remote Address and Remote Port
The remote address identifies the peer system for a connection. The remote port identifies the service or peer-side application port. Together, the local and remote endpoint pairs show the direction and likely purpose of a TCP session.
For example, a row with local port 51432 and remote port 443 commonly represents a local client connecting to an HTTPS service. The local port belongs to the client process; the remote port belongs to the server-side service.
A listening endpoint generally has no connected remote peer. UDP may also have no meaningful remote address or port because it can receive datagrams from multiple sources.
Resolved Hostnames and Numeric IP Addresses
Process Explorer resolves IP addresses to DNS names by default. Resolved names are easier to read and can make a destination recognizable. However, reverse DNS results can be incomplete, slow, outdated, or misleading. A hostname may represent a cloud provider, content-delivery network, proxy, or shared service rather than the final application organization.
To display literal IP addresses, clear the Resolve addresses check box in the TCP/IP tab. Numeric addresses are useful when documenting an incident, comparing observations, checking firewall rules, or independently verifying a destination.
| Display Choice | Advantages | Limitations | Best Use |
|---|---|---|---|
| Resolved DNS names | Readable and easier to associate with familiar infrastructure. | May be slow, missing, outdated, generic, or misleading. | Quickly understanding normal application activity. |
| Numeric IP addresses | Precise and stable for logs, comparisons, and network verification. | Less readable and may not identify the organization or service by themselves. | Detailed troubleshooting and security investigation. |
Practical Examples
Inspecting a Browser Connection
- Select the browser process and open its TCP/IP tab.
- Look for TCP rows in the ESTABLISHED state.
- Interpret the local address and temporary local port as the computer's client endpoint.
- Interpret the remote address and remote port as the web service endpoint. Port
443is commonly used for HTTPS. - Clear Resolve addresses to verify and record the numeric remote IP address.
Checking Whether a Local Service Is Listening
- Select the service, server, or development-tool process.
- Look for a TCP row in the LISTENING state.
- Record the local address and port.
- Determine whether the address is restricted to the local computer or bound broadly to available interfaces.
- Remember that the listener is waiting for clients; it does not necessarily represent an established remote session.
Investigating an Unfamiliar Outbound Connection
- Identify the process with the unexpected ESTABLISHED connection.
- Compare the process identity and expected function with the remote address, remote port, and protocol.
- Clear Resolve addresses and capture the numeric remote IP.
- Check the executable path, publisher, process hierarchy, and application configuration.
- Use all of these facts to decide whether further investigation is warranted.
Understanding UDP Activity
Applications use UDP for functions such as DNS, discovery, media, telemetry, and some real-time communications. Select the relevant process and identify UDP rows. Because UDP is connectionless, the row may not show a TCP-style state or a permanent remote peer. Relate the local port and any displayed peer information to the application's expected behavior.
Using the Tab for Troubleshooting and Security
Interpret the process name, protocol, state, addresses, and ports together. A familiar process can have legitimate connections to many destinations, and an unfamiliar hostname alone does not establish malicious activity.
- Unexpected listener: Check whether the process normally provides a service, update mechanism, debugging listener, or local interprocess communication feature.
- Unexpected outbound connection: Compare the destination and port with the process's normal role and current user action.
- Broad exposure: A listener bound to all interfaces deserves more attention than one restricted to the local computer, although firewall policy also matters.
- Multiple rows: Several connections may be normal for browsers, synchronization tools, security software, and cloud applications.
Troubleshooting Common Problems
No TCP/IP Entries Appear
Likely causes include no active TCP or UDP endpoints, a short-lived connection that ended before inspection, or a process that performs its work without network communication.
- Refresh or revisit the process while network activity is occurring.
- Confirm that you selected the expected executable or the correct child process.
- Do not treat an empty tab as a malfunction by itself.
A Destination Name Is Unfamiliar
The name may come from reverse DNS and may not match a familiar product or domain. The host may have no useful reverse record, or the application may use cloud, proxy, content-delivery, or shared infrastructure.
- Clear Resolve addresses to obtain the exact numeric IP.
- Evaluate the process, protocol, port, destination, and expected behavior together.
- Avoid classifying the activity as malicious solely because the hostname is unfamiliar.
An Expected Connection Is Not ESTABLISHED
The connection may still be starting, may be closing, may use UDP, or may have failed quickly.
- Check transitional states such as SYN_SENT or TIME_WAIT.
- Check whether the row uses UDP instead of TCP.
- Observe the tab during the action that initiates the traffic.
An Unexpected Port Is Listening
The application may intentionally provide a local service, update mechanism, debugging feature, or interprocess communication endpoint. A configuration change may also have enabled a service feature.
- Verify the executable path, publisher, process hierarchy, and normal application role.
- Determine whether the local address exposes the listener broadly or only locally.
- Compare the port and behavior with approved configuration and security policy.
Recommended Investigation Workflow
- Identify the exact process and verify its executable path.
- Open Process Properties and select the TCP/IP tab.
- Classify each row as TCP or UDP, listener or connection, and active or transitional.
- Record local and remote addresses and ports.
- Clear Resolve addresses when precise numeric verification is needed.
- Compare the observed activity with the application's expected role and the user's current action.
- Document unusual findings and validate them with configuration, firewall, DNS, and security records.
For broader process inspection, see the Process Properties guide and the Security tab guide. The Threads tab can help when network behavior needs to be related to thread activity.