--- title: "Pktmon: Capture Windows Traffic Without a Third-Party Driver" description: "Use the in-box Windows Pktmon tool to capture packets and packet-drop reasons, then convert the ETL to pcapng and text for offline analysis." canonical: "https://adamtheautomator.com/pktmon-capture-windows-traffic/" --- # Pktmon: Capture Windows Traffic Without a Third-Party Driver > Use the in-box Windows Pktmon tool to capture packets and packet-drop reasons, then convert the ETL to pcapng and text for offline analysis. Source: https://adamtheautomator.com/pktmon-capture-windows-traffic/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![Pktmon: Capture Windows Traffic Without a Third-Party Driver](https://adamtheautomator.com/wp-content/uploads/publisher/3ec5d9c85b2b81d9ab7cd5dbb6caf044/21b786d67f19d1813150edf9871e36ead78714b63880de8c6161c7fde11a9769.webp) # Pktmon: Capture Windows Traffic Without a Third-Party Driver [![](https://secure.gravatar.com/avatar/d0b9d42e21e5622713f8b693aa5c0f9244d5f7dd200ed29b8398f52dee5de337?s=192&d=mm&r=g)Adam Bertram](https://adamtheautomator.com/author/adam-bertram/)5 October 202614 min. read Categories: [IT Ops](/category/it-ops/) Tags:[Windows](/tag/windows/)[Networking](/tag/networking/)[PowerShell](/tag/powershell/)[Wireshark](/tag/wireshark/) Table of Contents * [What Pktmon Is and When It Beats Wireshark or netsh trace](#what-pktmon-is-and-when-it-beats-wireshark-or-netsh-trace) * [Where Pktmon Loses to Wireshark](#where-pktmon-loses-to-wireshark) * [Check Your Windows Build and Pktmon Syntax First](#check-your-windows-build-and-pktmon-syntax-first) * [Confirm the Syntax on the Box](#confirm-the-syntax-on-the-box) * [Prerequisites: Elevation and Interface Discovery](#prerequisites-elevation-and-interface-discovery) * [Map a Component ID to a Real Adapter](#map-a-component-id-to-a-real-adapter) * [Build Capture Filters That Cut the Noise](#build-capture-filters-that-cut-the-noise) * [The Flags That Scope a Filter](#the-flags-that-scope-a-filter) * [Start a Full-Packet Capture and Pick the Right Log Mode](#start-a-full-packet-capture-and-pick-the-right-log-mode) * [Choose the Log Mode That Matches the Incident](#choose-the-log-mode-that-matches-the-incident) * [Reproduce the Problem and Read Live Counters](#reproduce-the-problem-and-read-live-counters) * [Counters Show Where the Packet Stopped](#counters-show-where-the-packet-stopped) * [Stop the Capture and Convert the ETL](#stop-the-capture-and-convert-the-etl) * [Clean Up and Verify Before You Copy](#clean-up-and-verify-before-you-copy) * [Diagnose Packet Drops and the Stack Path](#diagnose-packet-drops-and-the-stack-path) * [Correlate Snapshots of the Same Packet](#correlate-snapshots-of-the-same-packet) * [Automate a Support Bundle and Capture Safely](#automate-a-support-bundle-and-capture-safely) * [Redact Before You Share](#redact-before-you-share) * [Limitations and Gotchas That Change Your Plan](#limitations-and-gotchas-that-change-your-plan) * [When the Capture Shows Nothing](#when-the-capture-shows-nothing) * [Wrap Up: Run the Whole Workflow on the Next Incident](#wrap-up-run-the-whole-workflow-on-the-next-incident) Do not install a third-party packet capture driver on a production Windows server just to learn which hop is dropping your packets. The driver you add for one afternoon of troubleshooting can outlive the ticket, survive a reboot, and reappear in your next change-control review. Windows has shipped its own packet capture and drop-detection tool for years, and it does real diagnostic work without a third-party binary. The risk you carry into a capture is the capture itself. A full-packet trace on the wrong interface records credentials and customer payloads to disk, and an unbounded file can fill the system drive of the server you are trying to rescue, which is why the filter, file-size, and log-mode choices below decide whether the trace is an asset or an incident. In this tutorial, you will use Packet Monitor (Pktmon) to capture traffic and packet drops on a live Windows server, then turn that capture into a file you can analyze offline. You will confirm the tool’s syntax on your build, map the right network component to a real adapter, and build filters that keep the capture readable. From there you start and stop a full-packet capture, read the live drop counters, convert the result to pcapng and text, and package it for whoever analyzes it next. Everything runs from an elevated command prompt on the server, with nothing to install. ## What Pktmon Is and When It Beats Wireshark or netsh trace Pktmon captures packets at multiple points inside the Windows networking stack and reports where each one traveled, which is what you need when a server can reach the gateway but not the internal API behind it. Microsoft Learn [describes Pktmon](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) in one sentence: “Packet Monitor (Pktmon) is an in-box, cross-component network diagnostics tool for Windows. It can be used for packet capture, packet drop detection, packet filtering and counting.” That cross-component behavior separates it from a sniffer bound to a network adapter. On a host running Hyper-V, containers, or software-defined networking, traffic can move between virtual components without touching the physical NIC, and a capture attached to that NIC sees none of it. The same engine is reachable from a prompt through `pktmon.exe` and from a console through extensions in [Windows Admin Center](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-wac-extension). ### Where Pktmon Loses to Wireshark Pktmon is a first-response tool rather than a full protocol analyzer. It captures and counts packets, then hands the file off for decoding. Wireshark still owns [stream reassembly](https://adamtheautomator.com/wireshark-linux/), TLS decryption, and graphical filtering, and you will end up there once the capture is in [pcapng form](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-pcapng-support). | What you need | Wireshark + Npcap | [netsh trace](https://adamtheautomator.com/netsh-trace/) | Pktmon | | --- | --- | --- | --- | | Ships in-box | No | Yes | Yes | | Packet capture | Yes | Yes | Yes | | Native pcapng export | Yes | No | Yes | | Drop reason per component | No | No | Yes | | Cross-component path | No | Partial | Yes | | Survives a reboot | No | Yes | No | Pktmon wins when the machine is the problem and you cannot change what is installed on it. Wireshark wins when you already hold the file and need to [follow a TCP stream](https://adamtheautomator.com/tshark/). The diagram below shows where the intercept points sit in the stack. ![Pktmon stack intercepts](https://adamtheautomator.com/wp-content/uploads/publisher/aa507c5ea5803856940a0d2f8cd6a2dd860c461c98a6f7866432e852929da0ed.png) The next thing to settle is which pktmon syntax your build accepts. ## Check Your Windows Build and Pktmon Syntax First Copying a Pktmon command from an older article is the fastest way to get a syntax error that looks like a broken tool. Pktmon changed its capture switch between Windows releases, and a command that once worked now returns an invalid argument or quietly does nothing. Microsoft’s current reference documents the modern form, [`pktmon start --capture`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-start) (short form `-c`). If a command you copied uses `--etw`, treat it as suspect and verify it on the box. ### Confirm the Syntax on the Box The safe move is to ask the tool on the machine what it supports before you trust any blog, including this one. ```powershell pktmon /? pktmon start /? pktmon filter add help ``` The first command prints the top-level command list for your build; the third prints the filter syntax the binary accepts. When the help text and the command agree, the syntax matches the build. Two version facts drive the rest of this post. Pktmon ships in-box on Windows 10 version 1809 (build 17763) and later and on Windows Server 2019 and later. The modern syntax used throughout this tutorial is the one documented for Windows 10 version 2004 (build 19041) and later, which Windows 11 and Windows Server 2022 and 2025 carry. ## Prerequisites: Elevation and Interface Discovery The captures below load a kernel driver and read the local networking stack, so they need an elevated prompt on the target server. If you want to follow along live, you will need: * An elevated command prompt or PowerShell session. Pktmon fails at start without administrator rights, so open the prompt with **Run as administrator** before anything else. * Pktmon present on the build (in-box on Windows 10 1809+ and Windows Server 2019+, confirmed with `pktmon /?`); skip this section entirely if you only analyze someone else’s pcapng. * 1 to 2 GB of free space on the target drive. The default log size is 512 MB, and a full-packet capture approaches it quickly. * A reproduction window. If the problem is a nightly job, start the capture before the schedule fires, because the capture only sees what happens while it runs. ### Map a Component ID to a Real Adapter Pktmon identifies every networking component with a numeric ID, and you pass those IDs to `--comp` to limit which adapter you capture. Run [`pktmon list`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-list) to print components by adapter binding, with the NIC at the top, then filter drivers, then protocols. The output gives you the ID but not always the friendly name you recognize, so pair it with PowerShell: ```powershell pktmon list Get-NetAdapter | Select-Object Name, InterfaceDescription, ifIndex, Status ``` The `pktmon list` output prints the adapter description next to its component ID, and [`Get-NetAdapter`](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapter) gives you the name and `ifIndex` you already recognize. Match on the description string. When adapters are bonded or abstracted by a virtual switch, the strings do not line up, so run `pktmon list --json` and match the adapter name there instead. Component IDs are not stable. Microsoft Learn warns that “IDs are not persistent and may change across reboots and as Packet Monitor’s driver restarts.” Re-run `pktmon list` at the start of every session rather than reusing an ID from last week’s notes. The screenshot below shows the match you are looking for. ![Adapter component map](https://adamtheautomator.com/wp-content/uploads/publisher/991625626542b81e77f9384c87af5446379d0c07266c47d518653ee19d55064d.png) ## Build Capture Filters That Cut the Noise An unfiltered capture on a busy Windows server is mostly DNS, telemetry, and update checks, and the packets from your incident arrive buried in that traffic. Filters keep the trace readable, and Microsoft’s guidance is direct about doing it up front: “It’s highly recommended to apply filters before starting any packet capture, because troubleshooting connectivity to a particular destination is easier when you focus on a single stream of packets.” Up to 32 filters can be active at once. Conditions inside a filter combine with AND, and separate filters combine with OR. Filters are bidirectional, so a port or IP matches on both source and destination, and Pktmon has no way to express “everything except this port.” ### The Flags That Scope a Filter | Flag | Matches | Example | | --- | --- | --- | | `-i` | Source or destination IP, or a CIDR subnet | `-i 10.0.0.142` | | `-p` | Source or destination port | `-p 445` | | `-t` | TCP, UDP, ICMP, ICMPv6, or a protocol number; TCP accepts flags | `-t TCP SYN` | | `-m` | Source or destination MAC address | `-m 00-15-5D-01-02-03` | | `-v` | VLAN ID in the 802.1Q header | `-v 20` | | `-d` | EtherType such as IPv4, IPv6, or ARP | `-d IPv4` | | `-e` | Apply the same conditions to inner and outer encapsulated headers | `-e` | A clean start means removing whatever filters an earlier session left behind, then adding one scoped filter with [`pktmon filter add`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-filter-add). ```powershell pktmon filter remove pktmon filter add "SMB to fileserver" -i 10.0.0.142 -t TCP -p 445 pktmon filter list ``` The filter above captures only packets that are TCP, on port 445, and involving 10.0.0.142, because all three conditions must match. To capture that host or DNS, add a second filter for port 53 and leave the first in place, because the two filters work as an OR through [`pktmon filter`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-filter). * * * _**Warning: An unfiltered capture logs every broadcast, name-resolution query, and update check the server performs, which hides your incident in unrelated traffic and inflates the file. Confirm the filter list before you start.**_ * * * ## Start a Full-Packet Capture and Pick the Right Log Mode The default capture is smaller than most people expect. Pktmon logs only the first 128 bytes of each packet unless you override it, which covers the IP and TCP headers while stripping the application payload and most of a TLS handshake. When the question is whether the request arrived and what it carried, set the packet size to 0. ```powershell pktmon start --capture --pkt-size 0 --file-size 256 --file-name C:\captures\incident-1042.etl --log-mode circular --comp nics ``` Each option changes what the log holds. `--capture` turns on packet logging and counters. `--pkt-size 0` logs whole packets rather than the first 128 bytes. `--file-size 256` caps the log at 256 MB, down from the 512 MB default. `--log-mode circular` tells Pktmon to overwrite the oldest packets once the cap is reached. `--comp nics` limits capture to adapters; omit it to capture on every component, or replace it with a comma-separated list of component IDs from `pktmon list`. ### Choose the Log Mode That Matches the Incident | Log mode | What it does | Use it when | | --- | --- | --- | | `circular` | New packets overwrite the oldest at the size cap | You want a bounded file and can lose the oldest part of the window | | `multi-file` | Writes `PktMon1.etl`, `PktMon2.etl`, and so on at the cap | You must keep every packet and have disk budget for it | | `real-time` | Prints packets to the console; writes no log file | You want an interactive look at whether traffic arrives | | `memory` | Buffers events in a circular memory buffer and dumps to disk on stop | The host is noisy enough that writing to disk drops capture events | The memory mode exists for a reason. On a high-volume host, writing every packet to disk can cost you the packets you were trying to catch, so the buffer trades RAM for fidelity. The full reference for these options lives on [`pktmon start`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-start). * * * _**Key Insight: _**`--pkt-size 0`**_ writes whole packets, including credentials and customer data, to a plain file on disk. Set it to 0 only when headers cannot answer the question.**_ * * * ## Reproduce the Problem and Read Live Counters Start the capture, then reproduce the failure while it runs: retry the failing connection, run the scheduled job, or trigger the login that hangs. With the issue live, query the counters instead of opening the log. Pktmon arranges counters by binding stack, with adapters at the top and protocols at the bottom, split into transmit (Tx) and receive (Rx) columns, and drops reported in the same table. If a packet left the protocol layer but never reached the adapter, that gap is visible without a log parse. ### Counters Show Where the Packet Stopped ```powershell pktmon counters pktmon counters --type drop --drop-reason pktmon counters --live --refresh-rate 5 pktmon reset ``` [`pktmon counters`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-counters) takes `--type drop` to narrow the table to dropped packets, and `--drop-reason` adds the most recent reason a component dropped a packet, which is often the whole answer. `--live` refreshes the view until you press **Ctrl+C**, and `--refresh-rate` controls how many times per second it redraws, from 1 to 30 with a default of 10. [`pktmon reset`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-reset) zeroes the counters without stopping the capture, so you can clear background noise, reproduce the failure again, and watch only the delta. When you only need to confirm that a connection attempt reaches the machine, real-time mode is faster than reading a file. ```powershell pktmon start -c -m real-time ``` That prints packets to the console until you press **Ctrl+C**, and it writes no ETL at all. Use it to answer whether the traffic arrives, then switch back to a logged capture when you need evidence to keep. Counters tell you which component dropped traffic and why; stopping the capture and converting the log carries that detail off the server. ![Live drop counters](https://adamtheautomator.com/wp-content/uploads/publisher/b59fddbb38a7e62fd474ee5a78618f4ddb5dc3bb176b37f50fd14d658c576b64.png) ## Stop the Capture and Convert the ETL Pktmon writes its log in Event Trace Log (ETL) format, which is optimized for Event Tracing for Windows and is not readable by Wireshark. The conversion to pcapng is built in, so you never need an older analyzer or a third-party converter. Stop the capture first, then convert with [`pktmon etl2pcap`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-etl2pcap). ```powershell pktmon stop pktmon etl2pcap C:\captures\incident-1042.etl --out C:\captures\incident-1042.pcapng pktmon etl2pcap C:\captures\incident-1042.etl --drop-only --out C:\captures\incident-1042-drops.pcapng pktmon etl2pcap C:\captures\incident-1042.etl --component-id 5 --out C:\captures\incident-1042-comp5.pcapng pktmon etl2txt C:\captures\incident-1042.etl --out C:\captures\incident-1042.txt ``` The default conversion drops the drop information, so the second command exists on purpose: `--drop-only` produces a file containing just the dropped packets. The third isolates traffic from a single component with `--component-id`, which matters because pcapng has no field for the Windows component that captured a packet. When you would rather grep than click, [`pktmon etl2txt`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-etl2txt) writes a text log in [tcpdump-style format](https://adamtheautomator.com/tcpdump-linux/) you can search on the server. ### Clean Up and Verify Before You Copy Two chores belong here. Run [`pktmon status`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pktmon-status) to confirm nothing is still collecting, then `pktmon filter remove` so the next person starts clean. After that, open the pcapng in Wireshark before you copy it anywhere, because a conversion that failed silently is worse than no file. The text log is where a drop becomes a root cause. ## Diagnose Packet Drops and the Stack Path The text log names the reason behind each drop, and those fields are worth learning before your first incident. Consider a virtual machine that cannot open a TCP connection to a SQL server on port 1433, on a host where a capture on the physical NIC shows nothing. Build a scoped filter and capture across all components. ```powershell pktmon filter add "SQL to db" -i 10.20.0.15 -t TCP -p 1433 pktmon start --capture --pkt-size 0 --file-name C:\captures\sql.etl --comp all ``` Reproduce the failed connection, stop the capture, and query the counters with `pktmon counters --type drop --drop-reason`. A rising drop count under a virtual switch component, paired with a reason such as MTU mismatch or filtered VLAN, shows the packet was dropped inside the stack rather than on the wire. Convert the ETL to text and search for the word “drop”; each dropped packet carries a `dropReason` value that names the cause directly, so you skip the guesswork of eliminating every other component one at a time. ### Correlate Snapshots of the Same Packet Pktmon captures a snapshot of a packet at every component boundary it crosses, so one packet appears as several entries in the log. The [Pktmon command formatting reference](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-syntax) names three fields that tie those entries together. `PktGroupId` and `PktNumber` are identical across every snapshot of the same packet, and `Appearance` counts the snapshots in order, starting at 1 where the packet first entered the stack. The component ID on each snapshot resolves against the component table at the bottom of the log, and a component with two edges reports a snapshot on each edge, which is why one packet can list four or more appearances. Read together, those fields give you the packet’s travel history: it entered at the protocol layer, crossed the switch, and stopped at the adapter with a drop reason attached. The diagram below shows how the snapshots chain together for a single dropped packet. ![Packet across the stack](https://adamtheautomator.com/wp-content/uploads/publisher/3a929873cf5cf6c1abc5a726455617f755ce7353cef72cec7aea2013a934c6b3.png) ## Automate a Support Bundle and Capture Safely An incident is easier to hand off when the capture, counters, and text log travel together, and a small function makes that repeatable. Run this from an elevated PowerShell prompt on the server. ```powershell function New-PktmonBundle { param( [Parameter(Mandatory)][string]$OutDir, [Parameter(Mandatory)][string]$FilterIp, [int]$Seconds = 60, [int]$FileSizeMB = 256 ) New-Item -ItemType Directory -Path $OutDir -Force | Out-Null $etl = Join-Path $OutDir 'capture.etl' pktmon filter remove pktmon filter add "bundle" -i $FilterIp pktmon start --capture --pkt-size 0 --file-size $FileSizeMB --file-name $etl --comp nics Start-Sleep -Seconds $Seconds pktmon counters --json | Out-File (Join-Path $OutDir 'counters.json') pktmon stop pktmon etl2pcap $etl --out (Join-Path $OutDir 'capture.pcapng') pktmon etl2pcap $etl --drop-only --out (Join-Path $OutDir 'drops.pcapng') pktmon etl2txt $etl --out (Join-Path $OutDir 'capture.txt') Compress-Archive -Path (Join-Path $OutDir '*') -DestinationPath (Join-Path $OutDir 'pktmon-bundle.zip') -Force } ``` The order matters. Counters are captured before `pktmon stop` so the JSON reflects the same window as the ETL. The conversion runs after the stop so the ETL is complete. Zipping last keeps the four artifacts in one object to attach to a ticket. ### Redact Before You Share A full-packet capture is production data. With `--pkt-size 0`, the ETL and the pcapng carry the payload of every captured packet, which can include session tokens, credentials typed into a form, and customer records. Treat both files the way you treat a database export. * Keep captures on the server or a secured share, and never email a raw ETL or pcapng. * Scope the filter by IP and port so you collect only the traffic under investigation, and keep the default 128-byte capture when headers answer the question. * Set a file-size cap so a forgotten capture cannot fill the drive, and delete the ETL and pcapng when the incident closes, because nothing expires automatically. * If you must share the file, strip payloads first. Wireshark’s [`editcap`](https://www.wireshark.org/docs/man-pages/editcap.html) can trim and filter a pcapng, and Microsoft’s [`etl2pcapng`](https://github.com/microsoft/etl2pcapng) tool preserves the component and drop metadata the built-in converter discards. * * * _**Reality Check: A pcapng from a full-packet capture can contain credentials. Handing it to a vendor or dropping it in a ticket without redaction is a data-handling incident, not a support step.**_ * * * ## Limitations and Gotchas That Change Your Plan Four constraints decide whether Pktmon fits your incident, and knowing them up front keeps you from chasing a capture that cannot answer the question. * **No promiscuous mode.** Pktmon sees only traffic to or from the local Windows system. It cannot passively sniff a switched LAN or a SPAN port, so “what else is on this segment” is out of scope. * **Duplicate packets and false retransmissions.** Capturing at multiple stack points means the same packet can appear several times in the pcapng, and offload features such as Large Send Offload (LSO) and Receive Segment Coalescing (RSC) can produce artifacts Wireshark flags as retransmissions. Verify a suspected retransmission against the component path before treating it as a network fault. * **No capture across a reboot.** A Pktmon capture ends when the system restarts, so boot-time and pre-logon failures need a persistent trace instead. * **Shallow protocol decoding.** Pktmon captures and counts; it does not follow a TCP stream or decode TLS. Move to Wireshark for that work. ### When the Capture Shows Nothing An empty capture from a working filter usually means the traffic never reached the component you filtered on, so check `pktmon list` before you question the filter. Localhost traffic is the other common miss: it can bypass the physical adapter entirely, so capture it on the loopback component rather than the NIC. One more trap sits in conversion. `pktmon etl2pcap` cannot convert an ETL written by the [netsh trace utility](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-trace), and those files need the standalone `etl2pcapng` tool instead. ## Wrap Up: Run the Whole Workflow on the Next Incident Pktmon gives you a capture path that starts and ends on the server, with no installer, no reboot, and no vendor approval. The [Packet Monitor overview](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) is the authoritative reference when a flag here disagrees with your build. The workflow is the same every time: 1. Confirm the build with `pktmon /?` and read the syntax your binary accepts. 2. Map the component with `pktmon list` and match it against `Get-NetAdapter`. 3. Clear stale filters, then add one scoped filter for the traffic under investigation. 4. Start a bounded full-packet capture with an explicit file size and the right log mode. 5. Reproduce the failure and read `pktmon counters --drop-reason`. 6. Stop, convert to pcapng and text, and confirm the pcapng opens. 7. Package counters, pcapng, and text into one bundle, then redact before you share it. The command list is the easy part. When a server drops traffic at 2 a.m. and you cannot install anything on it, you already know which component dropped the packet, why, and how to prove it to the team that owns the application. Share this article [Share on X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fadamtheautomator.com%2Fpktmon-capture-windows-traffic%2F&text=Pktmon%3A%20Capture%20Windows%20Traffic%20Without%20a%20Third-Party%20Driver)[Share on Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fadamtheautomator.com%2Fpktmon-capture-windows-traffic%2F)[Share on LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fadamtheautomator.com%2Fpktmon-capture-windows-traffic%2F) ## Related Posts ![](https://adamtheautomator.com/wp-content/uploads/2023/03/powershell-ip-configuration.jpg) ### [PowerShell IP Configuration: A Beginner’s Guide to Windows Settings](/powershell-ip-configuration/) Master PowerShell IP Configuration: Learn to set up and troubleshoot network IPs on Windows effortlessly. A comprehensive guide for efficient network management. ![](https://adamtheautomator.com/wp-content/uploads/2026/06/26995-troubleshoot-dns-issues-powershell-codex.webp) ### [Troubleshoot DNS Issues with PowerShell](/troubleshoot-dns-issues-powershell/) Troubleshoot DNS issues with PowerShell by testing name resolution, DNS client settings, cache entries, and network connectivity in a repeatable workflow. ![](https://adamtheautomator.com/wp-content/uploads/2022/12/powershell-get-windows-version.jpg) ### [Learn the Many Ways in PowerShell to Get The Windows Version](/powershell-to-get-the-windows-version/) Stay informed and learn the many ways in PowerShell to Get the Windows Version through examples in this ATA Learning tutorial! ## Categories * [IT Ops](/category/it-ops/) * [Cloud](/category/cloud/) * [DevOps](/category/devops/) * [Home Ops](/category/home-ops/) * [Information Security](/category/infosec/) * [Software Development](/category/software-development/) ## Site * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Copyright 2026© ATA Learning | [Privacy Policy](/privacy/)