Mastering Packet Monitor (Pktmon) on Windows
For years, troubleshooting network traffic on Windows servers often meant installing third-party tools like Wireshark or Npcap directly on production systems, something many administrators and security teams prefer to avoid.
What many IT professionals still do not realize is that modern versions of Windows Server (Windows 10 and Windows Server 2019 (Version 1809 and later)) already include a powerful built-in packet capture and diagnostics tool: Packet Monitor, better known as Pktmon.
In this post, we will take a deep dive into Packet Monitor (Pktmon), exploring how to capture and filter network traffic directly on Windows servers without installing additional software. We will cover practical real-world troubleshooting scenarios, filtering traffic by IP addresses, protocols, and ports, converting captures into PCAPNG format for later analysis, and using Pktmon effectively in enterprise production environments.
Limitations of Packet Monitor (Pktmon)
Promiscuous Mode
Although Packet Monitor is a powerful built-in troubleshooting tool for Windows, it is important to understand its limitations compared to full-featured packet analyzers like Wireshark with Npcap.
Pktmon primarily captures traffic processed by the local Windows networking stack and therefore does not support classic promiscuous mode for passively sniffing arbitrary Layer-2 traffic on the network. This means Pktmon is mainly intended for troubleshooting traffic to and from the local system rather than acting as a traditional network sniffer on switched networks or SPAN/mirror ports.
Duplicate Packets and False TCP Retransmissions
Because Pktmon captures packets at multiple points within the Windows networking stack, converted PCAPNG captures may contain duplicate packets or misleading TCP retransmission indicators when opened in Wireshark.
This behavior is especially common on modern Windows servers using NIC offloading technologies such as Large Send Offload (LSO) or Receive Segment Coalescing (RSC).
More Limited Packet Analysis Capabilities
While Pktmon is excellent for capturing packets directly on Windows systems, its built-in analysis capabilities are much more limited compared to Wireshark.
Advanced protocol decoding, stream reconstruction, graphical statistics, deep inspection, VoIP analysis, and extensive filtering options are typically performed later in Wireshark after converting the capture into PCAPNG format.
Listing and Removing Existing Pktmon Filters
Before starting a new packet capture session with Packet Monitor, it is usually a good idea to first verify whether filters from previous capture sessions are still configured.
Existing filters can affect new captures and may lead to unexpected or incomplete results.
To display all currently configured filters, we can run the following command:
PS> pktmon filter list
If existing filters are present, we can remove them and start with a clean filter configuration by running:
This ensures that only the newly configured filters are applied to the next packet capture session.
PS> pktmon filter remove
Capturing SMB (TCP 445) Traffic Using Pktmon
In the example below, I was running all Packet Monitor commands directly on the domain controller 10.0.0.70 to capture SMB traffic from the client 10.0.0.142 on TCP port 445.
Afterwards, I accessed the administrative SMB share \\10.0.0.70\c$ on the domain controller from the client machine to generate matching SMB traffic and finally converted the ETL capture into PCAPNG format for later analysis in Wireshark.
Important: In
pktmon filter add, the-iparameter is used to filter by IP address, but it does not distinguish between source and destination.The
-dparameter does not mean destination IP; it is used for data-link protocol / EtherType filters such as IPv4, IPv6, or ARP.Source: https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-syntax
PS> pktmon filter remove PS> pktmon filter add -t TCP -i 10.0.0.142 -p 445 PS> pktmon start --capture --pkt-size 0
Here I was accessing the administrative SMB share \\10.0.0.70\c$ on the domain controller from the client machine.
After reproducing the issue or generating the desired network traffic, we can stop the active capture session by running the following command:
This command stops the packet capture process and automatically writes the collected trace data into the
PktMon.etlfile, which can later be converted into readable text or PCAPNG format for further analysis.
PS> pktmon stop
Finally, we can convert the native ETL capture file generated by Packet Monitor into the more commonly used PCAPNG format by running the following command:
The ETL format (
Event Trace Log) is Microsoft’s native event tracing format used internally by Windows and optimized for Event Tracing for Windows (ETW). In contrast, PCAPNG (Packet Capture Next Generation) is the industry-standard packet capture format that can be opened and analyzed with tools like Wireshark.
PS> pktmon pcapng PktMon.etl -o capture.pcapng
After converting the capture into PCAPNG format, we can open and analyze the file using Wireshark just like a regular network packet capture.
This allows us to inspect protocols, conversations, retransmissions, ports, IP addresses, and detailed packet contents using Wireshark’s advanced filtering and analysis capabilities.
When opening the converted PCAPNG capture in Wireshark, you may notice a large number of TCP retransmission packets. In many cases, these are not caused by actual network problems or packet loss, but instead are artifacts caused by how Packet Monitor captures traffic through the Windows networking stack and how the ETL capture is later converted into PCAPNG format.
Modern NIC offloading features such as Large Send Offload (LSO) and Receive Segment Coalescing (RSC) can further contribute to these misleading retransmission indicators.
Below we will see some additional practical examples demonstrating how to use Packet Monitor for troubleshooting common network issues directly on Windows servers without installing third-party packet capture tools.
Capture DNS Traffic (UDP/TCP 53)
DNS primarily uses UDP port 53 for standard queries, but TCP port 53 is also used, for example with larger responses, zone transfers, or fallback scenarios. Therefore, when troubleshooting DNS resolution issues, it makes sense to capture both UDP and TCP traffic on port 53.
The command below I will also run on my domain controller which is also configure as DNS server on the clients.
Without using the
-iparameter (source IP or destination IP), the configured filter will capture matching traffic regardless of the source or destination IP address.
PS> pktmon filter remove PS> pktmon filter add -t UDP -p 53 PS> pktmon filter add -t TCP -p 53 PS> pktmon start --capture --pkt-size 0
On the client machine, I generated DNS traffic by running an nslookup query against the FQDN of my blog to produce matching DNS requests and responses visible in the packet capture.
Afterwards we need to the stop the active capture session again.
PS> pktmon stop
The following screenshot shows the DNS query request generated by the client while resolving the FQDN of my blog through the configured DNS server.
The next screenshot shows the corresponding DNS response returned by the DNS server, including the resolved IP address for the requested FQDN.
Command-Line Help
We can check command-line help for arguments and capabilities by running:
PS> pktmon /?
To check if Paket Monitor is running and capturing the network traffic curently we can ru:
PS> pktmon status
Links
Packet Monitor (Pktmon)
https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmonIntroducing Packet Monitor
https://techcommunity.microsoft.com/blog/networkingblog/introducing-packet-monitor/1410594/replies/2392949?utm_source=chatgpt.comPktmon command formatting
https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-syntax
