pathping — Combined Traceroute and Ping

What it is

pathping is a built-in Windows network diagnostic command that combines the hop-by-hop path discovery of tracert with a sustained packet-loss and latency measurement phase. After discovering the route, it sends a configurable number of ICMP echo requests to every intermediate hop and the destination, then reports per-hop loss percentages and average RTT. This makes it uniquely suited for diagnosing intermittent packet loss at a specific router in the path — something tracert cannot do (it shows RTT only once per hop) and ping cannot do (it shows end-to-end loss only).

Availability

pathping ships as C:\Windows\System32\pathping.exe on Windows 2000 and later.

pathping /?

Output:

Usage: pathping [-g host-list] [-h maximum_hops] [-i address] [-n]
                [-p period] [-q num_queries] [-w timeout]
                [-4] [-6] target_name

Options:
    -g host-list    Loose Source Route along host-list.
    -h maximum_hops Maximum number of hops to search for target.
    -i address      Use the specified source address.
    -n              Do not resolve addresses to hostnames.
    -p period       Wait period milliseconds between pings.
    -q num_queries  Number of queries per hop.
    -w timeout      Wait timeout milliseconds for each reply.
    -4              Force using IPv4.
    -6              Force using IPv6.

Syntax

pathping [-n] [-h max_hops] [-p period_ms] [-q num_queries] [-w timeout_ms] [-4|-6] <target>

Output: (route discovery phase, then per-hop statistics)

Essential options

Basic usage

Running pathping with just a target first displays the discovered path (identical to tracert) and then begins the statistics-gathering phase, which takes about 25 seconds for a 10-hop route at default settings. Do not interrupt — the loss data is printed only at the end.

pathping 8.8.8.8

Output:

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
  0  myhost [192.168.1.100]
  1  router.local [192.168.1.1]
  2  10.10.10.1
  3  72.14.215.165
  4  8.8.8.8

Computing statistics for 100 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           myhost [192.168.1.100]
                                0/ 100 =  0%   |
  1    2ms     0/ 100 =  0%     0/ 100 =  0%  router.local [192.168.1.1]
                                0/ 100 =  0%   |
  2   12ms     0/ 100 =  0%     0/ 100 =  0%  10.10.10.1
                                0/ 100 =  0%   |
  3   18ms     0/ 100 =  0%     0/ 100 =  0%  72.14.215.165
                                0/ 100 =  0%   |
  4   20ms     0/ 100 =  0%     0/ 100 =  0%  dns.google [8.8.8.8]

Trace complete.

Skipping DNS resolution

-n prevents reverse-DNS lookups for each hop IP, which speeds up the discovery phase and avoids false timeouts caused by DNS latency in the trace.

pathping -n 8.8.8.8

Output:

Tracing route to 8.8.8.8
over a maximum of 30 hops:
  0  192.168.1.100
  1  192.168.1.1
  2  10.10.10.1
  3  8.8.8.8

Computing statistics for 75 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           192.168.1.100
                                0/ 100 =  0%   |
  1    2ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1

Adjusting sample count and interval

By default pathping sends 100 queries per hop with 250 ms between them. Reducing both speeds up the total test time; increasing gives more statistically reliable loss percentages.

rem Quick check: 25 queries, 200 ms interval
pathping -n -q 25 -p 200 192.168.1.1

Output:

Tracing route to 192.168.1.1
over a maximum of 30 hops:
  0  192.168.1.100
  1  192.168.1.1

Computing statistics for 10 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           192.168.1.100
                                0/ 25 =  0%   |
  1    2ms     0/ 25 =  0%     0/ 25 =  0%  192.168.1.1

Trace complete.

Interpreting packet loss columns

The statistics table has two loss columns that mean different things. "Source to Here" measures cumulative loss from the source to that hop; "This Node/Link" isolates the loss attributable to just that hop or the link leading into it.

pathping -n -q 50 203.0.113.1

Output:

Computing statistics for 25 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           192.168.1.100
                                0/ 50 =  0%   |
  1    2ms     0/ 50 =  0%     0/ 50 =  0%  192.168.1.1
                               10/ 50 = 20%   |
  2  100ms    10/ 50 = 20%     0/ 50 =  0%  203.0.113.1

In this example: 20% loss appears on the link between hop 1 and hop 2 (the | line shows 20%), while hop 2 itself shows 0% local loss — meaning the upstream link is congested, not the router at hop 2.

When to choose pathping over tracert or ping

Each of the three Windows network diagnostics answers a different question. Pick the right one for the symptom you are diagnosing.

The price of pathping's precision is time — a single run can take 5+ minutes on a long path with the defaults. Tune -q and -p aggressively when you need faster turnaround.

Source address (-i) and IPv6 (-6)

-i binds pathping to a specific local source IP, which matters on multi-homed hosts where the default route would pick the wrong interface. -6 forces ICMPv6 probes; without it, AAAA-only hosts are queried over IPv4 and time out.

rem Force pathping to leave via the VPN interface
pathping -i 10.8.0.5 -n 10.0.0.1

Output:

Tracing route to 10.0.0.1
over a maximum of 30 hops:
  0  10.8.0.5
  1  10.8.0.1
  2  10.0.0.1
...

pathping -6 -n ipv6.google.com

Output:

Tracing route to ipv6.l.google.com [2607:f8b0:4004:c08::8a]
over a maximum of 30 hops:
  0  2001:db8::abcd
  1  fe80::1
  ...

Anatomy of the statistics table

The two-column loss view in pathping is its key value-add. Understanding what each column measures is essential to interpreting the output correctly.

            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           myhost [192.168.1.100]
                               10/100 = 10%   |
  1   3ms     0/100 =  0%      0/100 =  0%   192.168.1.1
                               20/100 = 20%   |
  2  50ms    20/100 = 20%      5/100 =  5%   10.0.0.1
                               10/100 = 10%   |
  3  80ms    25/100 = 25%      5/100 =  5%   100.64.0.1

• Hop column — sequential router number.
• RTT — average round-trip from source to that hop.
• Source to Here Lost/Sent = Pct — cumulative loss from source up to and including that hop. Monotonically non-decreasing.
• This Node/Link Lost/Sent = Pct (| line) — loss on the link leading INTO that hop. This is the per-segment loss.
• This Node/Link Lost/Sent = Pct (hop line) — loss attributable to the router itself (ICMP rate-limiting, CPU policing).
• Address — IP or PTR of the responding router.

To diagnose: scan the | (link) column for the first non-zero value. That link is the suspect segment. Loss values on the hop line itself usually represent ICMP rate-limiting rather than real customer-impacting loss.

Distinguishing real loss from ICMP rate-limiting

Many routers rate-limit ICMP responses to protect the CPU — common policy is "no more than 100 ICMP TTL-exceeded per second per source". If pathping sends 100 probes in a few seconds, the router may legitimately drop some replies even though forwarding is healthy. Two patterns to recognise:

1. Hop N shows X% loss locally, but hop N+1 shows 0% locally — router N rate-limits ICMP but forwards data fine. Not customer-impacting.
2. Both hop N (link in) and hop N+1 (link in) show similar loss — real link congestion or fibre damage between them. Escalate.

                               20/100 = 20%   |     ← link loss between 1 and 2
  2  50ms     0/100 =  0%      0/100 =  0%   10.0.0.1
                                0/100 =  0%   |
  3  80ms     0/100 =  0%      0/100 =  0%   100.64.0.1

In this example the link into hop 2 lost 20% but everything downstream is clean — the loss is happening on that single segment.

Loose source routing (-g)

-g host-list requests Loose Source Routing — pathping adds an IP option asking each named router to be visited in order before reaching the destination. Almost universally blocked on the public Internet (RFC 7126) but functional inside MPLS or lab networks.

pathping -g 10.0.0.1 10.0.0.2 -n -q 25 192.168.99.10

Output:

Tracing route to 192.168.99.10
over a maximum of 30 hops:
  0  192.168.1.100
  1  10.0.0.1
  2  10.0.0.2
  3  192.168.99.10
...

If the option is dropped, every hop reports 100% loss — fall back to a normal trace.

PowerShell equivalents and modern alternatives

PowerShell does not include a direct pathping replacement. The closest combination is Test-NetConnection -TraceRoute (which traces but does not measure loss) combined with iterated Test-Connection. Test-NetConnection -TraceRoute was introduced in PowerShell 6.0 and remains the script-friendly tracer in PowerShell 7.6 LTS — but it still lacks per-hop loss measurement, which is exactly what pathping provides. The Linux ecosystem's mtr is the modern multi-hop loss measurement tool — install via WSL, or use WinMTR as a standalone Windows port that continues tracing past non-responding hops.

# Get the hops, then ping each one in parallel for loss measurement
$hops = (Test-NetConnection 8.8.8.8 -TraceRoute).TraceRoute
$hops | ForEach-Object -Parallel {
    $sent = 50
    $rcv = (Test-Connection -ComputerName $_ -Count $sent -Quiet `
        -TimeoutSeconds 1 -ErrorAction SilentlyContinue).Count
    $loss = [math]::Round(($sent - $rcv) * 100.0 / $sent, 1)
    [PSCustomObject]@{Hop=$_; Sent=$sent; Received=$rcv; LossPct=$loss}
} -ThrottleLimit 5

Output:

Hop           Sent Received LossPct
---           ---- -------- -------
192.168.1.1     50       50       0
10.0.0.1        50       45      10
100.64.0.1      50       50       0
72.14.215.165   50       50       0
8.8.8.8         50       50       0

# Inside WSL — mtr offers a live updating per-hop loss view
mtr --report --report-cycles 100 8.8.8.8

Output:

Start: 2026-05-25T14:00:00+0000
HOST: myhost                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                 0.0%   100    0.4   0.5   0.3   1.2   0.1
  2.|-- 10.0.0.1                    0.0%   100    8.0   8.2   7.9   9.0   0.2
  3.|-- 100.64.0.1                  5.0%   100   12.0  12.3  11.9  14.0   0.5
  4.|-- 72.14.215.165               0.0%   100   14.0  14.0  13.9  14.2   0.1
  5.|-- 8.8.8.8                     0.0%   100   14.0  14.0  13.9  14.3   0.1

mtr reports stddev as well as min/max, which is invaluable for spotting jitter even when loss is zero.

Tuning total runtime

Total time = (hop count × -p) + (hop count × -q × -p / 1000) seconds. With defaults (-p 250 -q 100), a 10-hop trace takes 10 × 25 = 250 seconds.

Increasing -q raises statistical confidence in the loss percentage (95% confidence interval narrows as 1/√n).

Comparing pathping output across time

A daily archived snapshot makes it easy to spot the day a new loss problem started. Use forfiles to retain a rolling window.

@echo off
set TS=%date:~-4,4%-%date:~-10,2%-%date:~-7,2%
pathping -n -q 50 8.8.8.8 > C:\Logs\pp_8888_%TS%.txt
pathping -n -q 50 1.1.1.1 > C:\Logs\pp_1111_%TS%.txt
forfiles /p C:\Logs /m pp_*.txt /d -30 /c "cmd /c del @path" 2>NUL
echo Snapshot saved.

Output:

Snapshot saved.

When pathping is silent

Several conditions cause pathping to appear to hang or produce no useful output:

1. All intermediate hops drop ICMP — the trace phase prints * * * for every hop and the statistics phase shows 100% loss everywhere; switch to tcpping/mtr -T.
2. Destination is the same subnet as source — no intermediate hops, so the table has only one row; behaves like ping.
3. Asymmetric routing — forward path is fine but return path drops TTL-exceeded; you see hops in the discovery phase but loss in the statistics phase.
4. Path uses MPLS with no-propagate-ttl — intermediate routers do not decrement TTL, so the trace appears to be only 2-3 hops even when the underlying path is much longer.

Common pitfalls

1. Total run time is long — with defaults, pathping runs for roughly 25 seconds per 10 hops; for a 30-hop path it can take 2+ minutes; use -q 25 -p 200 to shorten to ~15 seconds.
2. ICMP filtering gives false loss — many routers rate-limit or silently drop ICMP probes to reduce CPU load; 100% loss at a hop followed by 0% at the next hop is almost always firewall filtering, not real loss.
3. Cannot interrupt and get partial results — statistics are printed only after the full sampling phase completes; Ctrl+C abandons the run with no output.
4. * hops delay timing — non-responding hops cause pathping to wait for the full timeout for each query, dramatically extending the run when intermediate routers don't reply to ICMP.
5. IPv6 requires -6 — pathping defaults to IPv4 even for IPv6 hostnames unless -6 is specified explicitly.
6. No TCP probe option — pathping only uses ICMP; for TCP-based per-hop loss, use mtr -T in WSL or a paid tool like PingPlotter.
7. Loss column ambiguity — newcomers often read "Source to Here" as per-hop loss; it is cumulative. The | (link) column is the per-segment value.
8. DNS slows the trace phase — without -n, every hop triggers a PTR lookup that may time out; -n saves seconds to minutes on long paths.
9. -p shorter than -w — if -p 100 but -w 3000, a missing reply still blocks the queue for 3 s; tune them together.
10. ECMP can produce inconsistent hop sets — successive probes may land on different physical routers; pathping presents them as one hop with averaged stats.
11. Pathping is read-only — unlike ping -l for MTU testing, pathping cannot be used to probe path MTU; use ping -l X -f for that.
12. Output cannot be parsed easily — the multi-line format with | connectors is human-readable but not machine-friendly; use PowerShell mtr alternatives for scripting.

Real-world recipes

Quickly isolate which hop is losing packets

pathping -n -q 50 -p 100 8.8.4.4

Output:

Computing statistics for 10 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           192.168.1.100
                                0/ 50 =  0%   |
  1    3ms     0/ 50 =  0%     0/ 50 =  0%  192.168.1.1
                                5/ 50 = 10%   |
  2   40ms     5/ 50 = 10%     0/ 50 =  0%  10.10.10.1
                                0/ 50 =  0%   |
  3   20ms     5/ 50 = 10%     0/ 50 =  0%  8.8.4.4

The 10% link loss between hop 1 and hop 2 identifies the suspect link; escalate with the ISP owning that segment.

Log pathping output to a file for later analysis

pathping -n -q 100 8.8.8.8 > C:\Logs\pathping_%date:~-4,4%%date:~-7,2%%date:~-10,2%.txt

Output:

(none — output written to file)

Schedule a nightly pathping baseline

A schtasks job that captures a 200-probe baseline overnight, when the network is least loaded, gives a clean reference to compare against the next time something seems off.

schtasks /Create /SC DAILY /ST 02:00 /TN "NightlyPathping" ^
    /TR "cmd /c pathping -n -q 200 -p 200 8.8.8.8 > C:\Logs\baseline_%date:~-4,4%-%date:~-10,2%-%date:~-7,2%.txt" ^
    /RU SYSTEM

Output:

SUCCESS: The scheduled task "NightlyPathping" has successfully been created.

Compare two paths to the same destination

When investigating asymmetric routing or VPN vs direct paths, run pathping over both interfaces and diff the results.

@echo off
pathping -n -i 192.168.1.100 -q 50 8.8.8.8 > C:\Logs\pp_lan.txt
pathping -n -i 10.8.0.5      -q 50 8.8.8.8 > C:\Logs\pp_vpn.txt
fc C:\Logs\pp_lan.txt C:\Logs\pp_vpn.txt > C:\Logs\pp_diff.txt
echo Diff saved to C:\Logs\pp_diff.txt

Output:

Diff saved to C:\Logs\pp_diff.txt

Extract loss rows for alerting

A PowerShell parser pulls the per-link loss percentage from pathping output. Use it to fire an alert when any segment exceeds a threshold.

$threshold = 5
pathping -n -q 50 -p 200 8.8.8.8 | ForEach-Object {
    if ($_ -match '(\d+)/\s*\d+\s*=\s*(\d+)%') {
        $loss = [int]$matches[2]
        if ($loss -ge $threshold) {
            Write-Warning "Loss above threshold: $loss% on line: $_"
        }
    }
}

Output:

WARNING: Loss above threshold: 10% on line:                                10/50 = 10%   |

Use pathping to find the AS boundary

The first hop with a public, non-RFC1918 IP marks where your traffic leaves your ISP. Pair pathping with PTR labels to identify the AS transition.

pathping -q 25 example.com

Output: (the trace lists each hop with PTR; look for the first non-private IP)

Look for the first non-private address in the route discovery section — that is the ISP's customer edge. The hop after that is typically the ISP's core. PTR labels like cust.example-isp.net confirm the boundary.

Capture pathping + traceroute + ping in one diagnostic bundle

A single script captures three views of the path; submit the resulting folder to support as a problem report.

@echo off
set TGT=%1
if "%TGT%"=="" set TGT=8.8.8.8
set OUT=C:\Logs\diag_%COMPUTERNAME%_%date:~-4,4%-%date:~-10,2%-%date:~-7,2%
mkdir %OUT% 2>NUL
ipconfig /all > %OUT%\ipconfig.txt
ping -n 20 %TGT% > %OUT%\ping.txt
tracert -d %TGT% > %OUT%\tracert.txt
pathping -n -q 100 %TGT% > %OUT%\pathping.txt
arp -a > %OUT%\arp.txt
route PRINT > %OUT%\route.txt
echo Diagnostic bundle: %OUT%

Output:

Diagnostic bundle: C:\Logs\diag_MYHOST_2026-05-25

Per-hop loss summary in PowerShell

A regex-driven parser that produces a clean per-hop loss table from raw pathping output.

$lines = pathping -n -q 50 8.8.8.8
$rows = $lines | Select-String -Pattern '^\s*\d+\s+\S+\s+\d+/\s*\d+\s*=\s*\d+%'
$rows | ForEach-Object {
    if ($_ -match '^\s*(\d+)\s+(\d+ms|\<1ms)\s+(\d+)/\s*(\d+)\s*=\s*(\d+)%\s+(\d+)/\s*(\d+)\s*=\s*(\d+)%\s+(\S+)') {
        [PSCustomObject]@{
            Hop      = $matches[1]
            RTT      = $matches[2]
            CumLoss  = "$($matches[5])%"
            LocLoss  = "$($matches[8])%"
            Address  = $matches[9]
        }
    }
}

Output:

Hop RTT     CumLoss LocLoss Address
--- ---     ------- ------- -------
  1 <1ms    0%      0%      192.168.1.1
  2 12ms    10%     0%      10.0.0.1
  3 14ms    10%     0%      8.8.8.8

See also

• ping — quick reachability check
• tracert — hop-by-hop path without loss measurement
• arp — Layer 2 neighbor cache
• route — local routing table
• netstat — established TCP/UDP connections
• nslookup — verify name resolution before tracing
• netsh — netsh trace for kernel-level packet capture

Sources

• What's the PowerShell equivalent of tracert — PDQ blog
• Test-Connection — Microsoft Learn (PowerShell 7.6)
• WinMTR / MTR vs Pathping vs traceroute — Mo's Blog
• Pathping - What can you do with it? — LazyAdmin