Skip to content
WindowsDeep Dive Published Updated 5 min readViews unavailable

Pktmon: Tracing Windows Packet Drops Across the Network Stack

Use Packet Monitor filters, component counters, and ETL exports to locate Windows packet drops without flooding a network investigation.

Packet Monitor (pktmon.exe) is an in-box Windows diagnostic tool that can capture packets and report packet drops at multiple components in the networking stack. It is particularly useful when traffic traverses virtual switches, containers, software-defined networking, or other layered paths where a capture at only the physical NIC cannot show where the packet disappeared. Pktmon’s multiple component snapshots are views of the same packet as it moves through the stack; they should not be counted as independent application messages.

The fastest way to make a capture useless is to record everything indefinitely. Start with a specific source or destination address, port, protocol, interface, or drop type. A filter focuses the experiment and reduces the volume of sensitive packet data. Pktmon supports multiple filters; a packet is captured when it matches the conditions of at least one configured filter, while the conditions within a filter narrow the match. Read the installed command’s help because options and output formats can vary by Windows build.

Take a bounded, targeted capture

This example records ICMP traffic associated with one endpoint. Replace the address and filter with the traffic that reproduces the incident. Review pktmon filter add help first, especially when filtering encapsulated traffic, and remove stale filters from prior experiments. The commands require an elevated terminal for many capture scenarios.

$case = Join-Path $env:TEMP ("pktmon-{0:yyyyMMdd-HHmmss}" -f (Get-Date))
New-Item -ItemType Directory -Path $case -Force | Out-Null
Push-Location $case
try {
    pktmon filter list
    if ($LASTEXITCODE -ne 0) { throw 'Could not inspect existing Pktmon filters.' }

    pktmon filter add -i 192.0.2.25 -t icmp
    if ($LASTEXITCODE -ne 0) { throw 'Could not add the requested capture filter.' }

    pktmon start --capture
    if ($LASTEXITCODE -ne 0) { throw 'Pktmon capture did not start.' }

    try {
        Read-Host 'Reproduce one connectivity failure, then press Enter'
        pktmon counters
    }
    finally {
        pktmon stop
        if ($LASTEXITCODE -ne 0) { Write-Warning 'Pktmon stop reported an error.' }
    }

    $etl = Join-Path $case 'PktMon.etl'
    if (Test-Path -LiteralPath $etl) {
        pktmon etl2txt $etl
        if ($LASTEXITCODE -ne 0) { throw 'ETL-to-text conversion failed.' }
    } else {
        Write-Warning 'Expected ETL file was not found; inspect Pktmon output for its path.'
    }
}
finally {
    Pop-Location
}

Pktmon’s default ETL path and command options can differ by release, so confirm the generated artifact name with pktmon start help and pktmon stop help on the host rather than silently assuming conversion succeeded. A completed pktmon stop and a nonempty ETL are separate checks. Review existing filters before adding one; do not remove filters owned by another diagnostic session. Remove only filters created for this experiment after coordination and evidence capture. The sample uses a documentation-only IPv4 address and is not a production destination.

Read packet flow and drop evidence

Run pktmon counters during the experiment for a high-level view, then inspect the converted or formatted ETL for the relevant packet. Pktmon can expose multiple interception points and drop reasons. Follow a packet from the ingress component toward the expected egress component. If a packet appears at an upper component but not a lower one, inspect the named component and its surrounding configuration. If it appears on the NIC but not in the protocol stack, correlate the host’s filtering, offload, VLAN, and virtual-switch configuration. A drop reason is a strong lead, but confirm it against the actual topology and current policy.

Capture filters are not directional for every address or port condition in the same way an analyst may expect; Microsoft documents that MAC, IP, and port filters do not distinguish source from destination. Encapsulation filters may need an explicit inner-packet option for VXLAN, GRE, NVGRE, or IP-in-IP. A filter that matches the outer tunnel only can miss the inner flow being investigated. Verify the filter with a known test packet before drawing conclusions from an empty capture.

Pktmon can export ETL data in text or PCAPNG format for additional analysis. Maintain the original ETL, checksum, host build, exact filter rules, selected components, capture duration, and reproduction steps. A Wireshark display filter applied later is not the same as a capture filter: the former hides records during analysis, while the latter determines which packets were collected.

Correlate with Windows networking layers

Pktmon shows where packet observations or supported drops occur; it does not explain every TCP retransmission, firewall policy decision, DNS failure, proxy issue, or remote-server response. Pair the capture with Get-NetAdapter, route information, IP configuration, DNS client events, Windows Filtering Platform evidence when relevant, and the application’s error timestamps. For virtual networking, record switch, vNIC, VLAN, NAT, and host/guest addresses so that encapsulation and component IDs can be mapped to the actual path.

Consider offloads and capture location when comparing Pktmon output to a packet capture from an external tap. Checksum offload, segmentation, coalescing, and virtual adapters can make host-visible packet shapes differ from on-wire frames. Do not call a checksum invalid solely because the host capture shows a value that a NIC later fills in. Capture at a second, independent point when the distinction changes the diagnosis.

Protect data and end the experiment cleanly

Packet captures can contain credentials, session tokens, personal data, internal hostnames, and payload fragments. Restrict write/read access to the case directory, use short capture windows, and follow the incident retention policy. Stop the capture even if the reproduction fails; do not leave an elevated tracing session active. Remove temporary filters after preserving the output, and avoid running Pktmon concurrently with unrelated capture tools unless the effect on visibility and resource use is understood.

Pktmon is most effective as a path-localization tool. A filtered, repeatable experiment can show the last component that observed a packet and the first component that reported a drop. That evidence turns a broad “network problem” into a specific Windows path to investigate, without mistaking a large trace for a diagnosis.

Related:

Sources:

Comments