A Windows server’s outbound traffic spikes every few minutes and the firewall shows connections to an address in a cloud provider’s range. One admin reaches for Wireshark and starts a capture; another opens TCPView and watches for a green row to flash. Both are reasonable first moves, but they answer different questions. TCPView tells you which process opened the connection and to where, in seconds. Wireshark tells you what was said on the wire, down to each packet, but on its own it doesn’t know which process sent it. Picking the wrong one first isn’t a disaster — it just costs time.
At a glance
| Wireshark | TCPView | |
|---|---|---|
| Publisher | Wireshark Foundation (open source) | Microsoft Sysinternals |
| Licence | GPLv2, no cost | Freeware, no cost |
| Current version at time of writing | 4.6.9 | Sysinternals release published April 2023 (v4 line) |
| Platforms | Windows (x64, Arm64), macOS, Linux/Unix | Windows 8.1+ / Server 2012+ |
| What you see | Individual packets, decoded across thousands of protocols | Live table of TCP/UDP endpoints with owning process and state |
| Process attribution | Not in a standard capture | Yes — process name, PID, service name |
| Payload / headers | Yes, full decode | No |
| Historical data | Capture files (pcapng) you can save, filter and share | Snapshot only; Save writes the current table |
| Needs a driver | Yes on Windows (Npcap) | No, runs as a single executable |
| Command-line companion | TShark, dumpcap | Tcpvcon (-a, -c CSV, -n) |
| Can act on connections | No | Close ESTABLISHED TCP connections, end process |
| Learning curve | Steep: capture and display filter syntax, protocol knowledge | Minimal |
| Footprint on a server | Driver plus capture overhead, disk for files | Very light |
Where they genuinely differ
The question each one answers
TCPView is a better-looking, live-updating netstat. Every TCP and UDP endpoint appears with its local and remote address, state, and the process behind it, refreshing every second by default, with new connections highlighted green and closing ones red. When the question is “what on this box is listening on 8080” or “what process keeps connecting to that IP”, TCPView answers it in under a minute. The step-by-step version is in our guide to finding which process owns a port.
Wireshark is a protocol analyser. It captures packets from an interface — on your own machine or from a mirror/SPAN port you’re authorised to use — and decodes them: TCP handshakes, retransmissions, TLS negotiation, DNS queries, SMB dialects, SIP signalling. When the question is “why does this connection stall after the TLS ClientHello” or “are these retransmits caused by loss or by a zero window”, only a capture will do.
Process attribution
This is the gap that makes the two tools complementary. A standard Wireshark capture has no idea which Windows process generated a packet. You can correlate by port — find the process and local port in TCPView, then filter Wireshark on tcp.port == 51234 — and that’s exactly the workflow many admins use. Going the other way, TCPView will never show you a single byte of payload.
Deployment and permissions
TCPView is one signed executable from Microsoft. No installation, no driver; run it elevated to see details for every process. That makes it acceptable on most production servers where installing software needs a change request.
Wireshark on Windows requires the Npcap capture driver, which is an installation on the host, and capturing on a busy server can produce large files quickly. On many servers it’s better to capture with dumpcap or pktmon (built into recent Windows) or from a SPAN port, then analyse on your workstation. Either way, capturing traffic is sensitive: packet data can contain credentials and personal data. Capture only on networks and systems you administer or have explicit authorisation to monitor, and handle capture files accordingly.
Evidence and sharing
A pcapng file is portable, replayable evidence. You can send it to a vendor’s support team, filter it later, or open it in other analysis tools. For disputes with an application vendor or a carrier, a trimmed capture is often the most convincing artefact you can produce.
TCPView’s evidence is thinner: a saved text table, or CSV from Tcpvcon (tcpvcon -a -c). That’s sufficient for “this process holds this port” or “this service connects to these addresses”, and much easier for a non-specialist to read.
Skill and time
TCPView needs no training. Wireshark rewards years of practice: display filters like tcp.analysis.retransmission, dns.flags.rcode != 0 or tls.handshake.type == 1, the Expert Info view, conversation and I/O graphs, following TCP streams. A newcomer can still get value quickly, but interpreting what they see takes protocol knowledge.
The verdict
Pick Wireshark if…
- you need to see what’s inside the traffic — handshakes, errors, retransmissions, protocol negotiation,
- the problem involves non-Windows hosts, network devices or a SPAN port,
- you need a file you can hand to a vendor or carrier,
- performance symptoms point at TCP behaviour (windows, retransmits, resets).
Pick TCPView if…
- the question is “which process” — a port conflict, an unknown connection, a chatty service,
- you’re on a Windows server where installing a capture driver isn’t allowed,
- you want an answer in a minute, not an analysis session,
- you need to close a stuck connection or end the owning process while testing.
In practice, the usual order is TCPView first to identify the process and ports, then Wireshark filtered on those ports if the conversation itself needs explaining. If the issue turns out to be raw capacity rather than protocol behaviour, measure it with iPerf3.
See the full Wireshark review and TCPView review, and other tools in Throughput & Packet Inspection. Get both from their official sites only — see where to get tools safely.