Process Explorer course

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

  1. Find the target process in the main Process Explorer list.
  2. Select the process.
  3. Open its Process Properties window, such as by double-clicking the process or using the process properties command.
  4. 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

FieldWhat It ShowsHow to Interpret It
ProtocolTCP or UDPTCP normally has connection states; UDP is connectionless and can display peer information differently.
StateThe current TCP lifecycle stateUse it to determine whether the process is listening, connecting, exchanging data, or closing a connection. It is mainly meaningful for TCP.
Local AddressThe local IP address or interface used by the endpointShows which address on the Windows computer is involved. A wildcard address can mean all local interfaces.
Local PortThe port used by the selected process on the local computerMay be a well-known service port for a listener or an automatically assigned ephemeral port for a client connection.
Remote AddressThe peer IP address or resolved hostnameIdentifies the other system for a connection. It may be absent or uninformative for a listener or some UDP endpoints.
Remote PortThe port used by the remote peerHelps identify the remote service and complete the local-to-remote endpoint pair.

Understanding TCP Connection States

StateMeaningTypical Troubleshooting Interpretation
LISTENINGA 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_SENTThe 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_RECEIVEDA 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.
ESTABLISHEDThe TCP connection has been created and can exchange data.Use the local and remote endpoint pair to identify the active session.
CLOSE_WAITThe 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_WAITA 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 ChoiceAdvantagesLimitationsBest Use
Resolved DNS namesReadable and easier to associate with familiar infrastructure.May be slow, missing, outdated, generic, or misleading.Quickly understanding normal application activity.
Numeric IP addressesPrecise 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

  1. Select the browser process and open its TCP/IP tab.
  2. Look for TCP rows in the ESTABLISHED state.
  3. Interpret the local address and temporary local port as the computer's client endpoint.
  4. Interpret the remote address and remote port as the web service endpoint. Port 443 is commonly used for HTTPS.
  5. Clear Resolve addresses to verify and record the numeric remote IP address.

Checking Whether a Local Service Is Listening

  1. Select the service, server, or development-tool process.
  2. Look for a TCP row in the LISTENING state.
  3. Record the local address and port.
  4. Determine whether the address is restricted to the local computer or bound broadly to available interfaces.
  5. Remember that the listener is waiting for clients; it does not necessarily represent an established remote session.

Investigating an Unfamiliar Outbound Connection

  1. Identify the process with the unexpected ESTABLISHED connection.
  2. Compare the process identity and expected function with the remote address, remote port, and protocol.
  3. Clear Resolve addresses and capture the numeric remote IP.
  4. Check the executable path, publisher, process hierarchy, and application configuration.
  5. 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

  1. Identify the exact process and verify its executable path.
  2. Open Process Properties and select the TCP/IP tab.
  3. Classify each row as TCP or UDP, listener or connection, and active or transitional.
  4. Record local and remote addresses and ports.
  5. Clear Resolve addresses when precise numeric verification is needed.
  6. Compare the observed activity with the application's expected role and the user's current action.
  7. 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.