Packet Capture on Windows: WinDump, Pktmon, or TShark?

When a network request fails on Windows, a successful port test may tell you whether a connection can be made—but not what happened to the packets. For that, you need a packet capture.

There is no standard native Windows tcpdump command. The closest option depends on what you need: WinDump for a familiar tcpdump-style interface, Pktmon for Windows’ built-in capture tool, or TShark if you already use Wireshark.

Pick the tool for the job

• WinDump: A good fit for existing tcpdump commands and capture filters. It needs a compatible packet-capture driver; current setups commonly use Npcap.
• Pktmon: Useful when you want an in-box Windows tool and can work with its ETL output and conversion workflow.
• TShark: Wireshark’s command-line tool, handy for captures and analysis in the Wireshark ecosystem.

A port check is still useful when you only need to know whether a TCP connection succeeds. PowerShell’s Test-NetConnection does that, but it does not record packet contents.

Capture with WinDump

WinDump is a Windows port of tcpdump. Install a WinDump build and a compatible capture driver. If that build relies on the WinPcap API, Npcap’s WinPcap API-compatible mode may be required. WinPcap itself is legacy software, so check the requirements for the specific WinDump build you use.

Open Command Prompt or PowerShell with sufficient permissions and list the available interfaces:

windump -D

Choose the adapter that actually carries the traffic. A machine may list Ethernet, Wi-Fi, VPN, and virtual adapters; interface number 1 is not guaranteed to be the right one.

To capture TCP traffic on port 443 and save it to a file:

windump -i 1 -n -s 0 -w capture.pcap "tcp port 443"

Replace 1 with the adapter number shown on your machine. Here, -n avoids name lookups, -s 0 captures the full packet rather than a short snap length, and -w writes packets to a file instead of printing summaries in the terminal. Press Ctrl+C when you have enough data.

You can narrow the capture further. For example, to capture traffic involving one host on TCP port 443:

windump -i 1 -n -s 0 -w capture.pcap "host 192.0.2.25 and tcp port 443"

192.0.2.25 is an example address; replace it with the host you are investigating. Other filters include port 53 for traffic on port 53, icmp for ICMP, or tcp port 22 for SSH traffic.

To read a saved capture from the command line:

windump -n -r capture.pcap

You can also open the resulting PCAP file in Wireshark.

Use Pktmon without a tcpdump-style install

Pktmon is Microsoft’s built-in Packet Monitor command-line utility on supported Windows versions. Its options and output differ from WinDump: it typically saves an ETL trace, which you can convert to PCAPNG for Wireshark.

Start by checking what components it can monitor:

pktmon list

Add a filter for TCP port 443, then start and stop a capture:

pktmon filter add -p 443 -t TCP
pktmon start --capture --pkt-size 0 --file-name capture.etl
pktmon stop

If Windows reports that the operation requires elevation, run the terminal as administrator. The filter is configured separately from the capture command. Before starting a different capture, remove the existing filters and add the ones you need:

pktmon filter remove

Convert the stopped trace for Wireshark:

pktmon etl2pcap capture.etl --out capture.pcapng

Keep the original ETL file if you may need to revisit or reconvert the capture. Pktmon can observe events at multiple points in the Windows networking stack, so the output may show repeated packet observations. Check pktmon help for syntax supported by your Windows build.

TShark for Wireshark users

If Wireshark is installed, TShark provides a command-line capture workflow. List interfaces, then capture on the appropriate one:

tshark -D
tshark -i 1 -f "tcp port 443" -w capture.pcapng

Replace 1 with the interface identifier from the list. -f applies a capture filter, and -w writes packets to a file. Interface visibility can still depend on driver configuration and permissions.

If the capture is empty

Check these in order:

1. Is the adapter right? Confirm the traffic crosses the interface you selected. VPNs and virtual adapters can make this less obvious.
2. Is the filter too narrow? Try a short capture with a broader filter, then add conditions once you know packets are visible.
3. Does the capture tool have access? Some driver operations or Pktmon commands require an elevated terminal.
4. Is the capture driver available? For WinDump, verify that the installed driver is compatible with your build and that its required API mode is enabled.
5. Did Pktmon finish cleanly? Confirm the ETL file exists and the capture has stopped before converting it.

A listening port or a successful connection test answers a different question from a packet capture. If you’re checking Windows listeners, learn what netstat -ano can—and can’t—tell you.

Treat capture files as sensitive

Packet captures can contain personal information, session data, or other sensitive traffic. Keep filters focused, capture only what you need, and store or share the resulting PCAP, PCAPNG, or ETL file carefully.

Use WinDump when tcpdump-like commands are the priority, Pktmon when you want Windows’ built-in tool, and TShark when Wireshark is already part of your workflow. In every case, verify the adapter first, apply a useful filter, and stop capturing as soon as you have enough evidence.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.