A loss figure beside one router in Windows PathPing does not automatically prove that router is dropping your game or call traffic. Read the complete result, distinguish replies addressed to a router from traffic being forwarded through it, and check what happens at later hops and the destination.
PathPing is useful evidence, but its probes are not your application’s actual packets. A single incomplete trace cannot certify a route or identify an ISP’s motive. Use a bounded test, retain the whole output and repeat under recorded conditions when the result matters.
Understand the two stages
Microsoft’s PathPing documentation describes an initial route discovery followed by repeated echo probes and statistics. A pause while it gathers those statistics is expected; it is not the same as a program hanging.
The related Tracert documentation explains that some intermediate routers do not return the expected expired-TTL replies. Asterisks can therefore reflect reply behavior. They do not, by themselves, establish that ordinary traffic stops at that hop.
Collect a result you can interpret
- Choose an appropriate destination. Use a host you own or are permitted to test and whose expected probe behavior you understand. An arbitrary game-service name may not identify an actual match host or answer ICMP.
- Record the context. Note the time, device, wired or wireless connection, VPN state and whether other transfers are active.
- Use a bounded command. For example,
pathping /n /q 20 HOSTNAMEuses a limited query count. Replace HOSTNAME with the intended destination; it is a placeholder. Leave probe pacing at a reasonable default rather than attempting a flood. - Wait for the statistics. Route discovery alone is not the full PathPing result. Preserve the completed output or clearly label an interrupted run.
- Save the whole result. Cropping one alarming line removes the later hops that help interpret it.
The example count is a practical bounded observation, not a universal accuracy threshold. A short sample can miss intermittent trouble, while a longer sample still does not observe every application packet.
Read the columns and the destination together
The output separates cumulative results towards a hop from the local node/link view. Rows identifying a router and rows identifying a link are not interchangeable. Microsoft illustrates that a router can fail to answer some probes addressed to itself while still forwarding traffic that is not addressed to it.
| Pattern | Careful interpretation |
|---|---|
| One middle router shows missing replies; later hops and destination respond cleanly | Do not blame that router for equivalent application loss from that line alone. |
| Loss appears and remains visible towards the destination | Preserve repeated evidence and investigate the relevant path, without assuming one trace identifies the exact cause. |
| The destination does not answer | Check whether it supports the probes; distinguish absent evidence from a confirmed complete outage. |
| The path or result changes between runs | Keep the times and conditions; avoid combining different routes into one supposedly continuous measurement. |
An illustrative percentage is not a verdict
Imagine a deliberately simplified example in which five of fifty probes addressed to a middle router receive no reply, while all fifty destination probes receive replies. The arithmetic for that middle row is10%, but it does not establish10% loss of the destination’s application traffic. This is a mathematical illustration, not a trace we performed.
If instead the destination also misses replies repeatedly, the observation deserves attention. It still concerns these probes at these times. Filtering, destination response policy and a different return path can complicate interpretation. Keep the application’s own symptoms and diagnostics beside the trace.
Compare conditions, then escalate
If the problem occurs on Wi-Fi, compare a wired run where practical, keeping the destination and other conditions similar. Repeat when the application is healthy and when it is struggling. A difference across those periods is more useful than an isolated worst-looking router line.
Our packet-loss troubleshooting guide covers the broader diagnostic sequence. PathPing adds route evidence to that process; it should not replace the application’s own telemetry or a check of local connection conditions.
A browser internet speed test provides a different HTTP measurement. The method documentation explains why HTTP request failures are not direct UDP or ICMP packet-loss measurements. Do not attach a matching label merely because several tools display percentages.
If symptoms coincide with uploads or downloads, an idle-versus-loaded latency comparison can be a separate experiment. Record that it uses another endpoint and workload rather than treating it as a second copy of the same trace.
What to send support
Provide the full saved output, exact command, time, destination, connection type and relevant application symptom. Explain what changed between successful and problematic periods. Remove private addresses or names when posting publicly, while retaining an unaltered copy for trusted support if requested.
That record supports a focused investigation. “Hop three is red” or a screenshot containing only one missing-reply percentage leaves out the evidence needed to distinguish response policy from a problem affecting forwarded traffic.