Windows Network Adapter Errors and Discards: Read the Counters

Windows network adapter counters can show that an interface reports errors or discarded traffic, but they do not tell you the packet-loss percentage of an internet game. Use two labelled snapshots to see what changes during an incident. A large number with no time interval, adapter identity or explanation is weak evidence.

This guide is for reading existing statistics, not changing advanced driver properties. If you need the broader concept first, packet loss and its measurement explains why the measurement point matters. The immediate task here is to identify an interface, observe it and preserve enough context to ask a better support question.

Find the adapter you mean to inspect

Microsoft’s Get-NetAdapter reference describes reading adapter properties and selecting physical or hidden adapters. If the command is available on your Windows installation, open PowerShell and start with:

Get-NetAdapter

Look for the interface that corresponds to your actual connection. A computer can have Ethernet, Wi-Fi, VPN and virtual interfaces with similar names. Record the displayed name and description rather than selecting the first row automatically. A disconnected interface may be irrelevant to the symptom you are observing.

Do not rename, disable or remove anything to make the list simpler. If the command is unavailable or your organisation restricts it, use your support team’s approved collection method. An unavailable command is not evidence that an adapter is broken.

Read a snapshot, then read it again

The Get-NetAdapterStatistics documentation lists statistics including errors, discards, broadcast and multicast traffic. Replace ADAPTER_NAME with the name you just identified:

Get-NetAdapterStatistics -Name "ADAPTER_NAME" | Format-List -Property *

Save the displayed values privately with a timestamp. After a short, defined observation period, run the same read-only command for the same interface again. Keep the output labels intact: receive and transmit statistics answer different questions, and traffic totals should not be confused with error totals.

Do not assume every counter resets at midnight or after a fixed time. If the interface reconnects, the computer restarts or the numbers decrease, start a new comparison rather than subtracting across that boundary. If a statistic is absent, write “not exposed” instead of interpreting it as zero.

Use a delta, not the biggest total

Consider a hypothetical counter that reads 40 before an observation and 44 afterwards. The relevant change is four during that interval, not 44 errors attributed to the activity. That calculation still does not supply a valid loss rate: you would need a compatible denominator and a definition of what the counter actually counts.

A second hypothetical interface might show a larger lifetime total that did not change during the complaint. That is different evidence from a smaller number rising at the same moment as a visible interruption. Neither example proves a cause; the point is to compare matching intervals rather than rank computers by old totals.

Do not combine receive errors and transmit discards into a homemade “health score.” Keep each statistic named and let the adapter or device documentation explain its meaning. This preserves useful detail when a vendor reviews the output.

Pair the counters with one ordinary activity

1. Write down the exact symptom, such as a file transfer stopping or a call losing audio, and the time it happens.
2. Collect the first snapshot before the activity. Note whether the connection is wired, wireless or routed through a dock.
3. Perform the normal activity briefly, without adding several unrelated tests. Save its own error message or status if available.
4. Collect the second snapshot and compare corresponding fields. Record whether the visible symptom and a counter change happened in the same interval.
5. Repeat one controlled comparison if useful, keeping the adapter and activity identifiable. Do not reset the adapter simply to make the counters look clean.

If you compare Ethernet with Wi-Fi, treat them as separate observations. Their counters belong to different interfaces. The slow Ethernet guide and one-device troubleshooting guide help choose the next condition to compare without claiming that a particular counter proves a cable or driver failure.

What these readings cannot establish

A clean local adapter snapshot does not certify the entire internet route. A rising counter does not identify a remote game server, an ISP hop or the cause of a specific application’s problem. The observations may help localise a question, but the application’s own connection evidence remains important.

A browser speed test measures traffic to its own endpoints and cannot read these Windows statistics. Keep its time and result separate. A failed browser HTTP request is also a different observation from an adapter discard; assigning both the same “packet loss” label hides that distinction.

For support, send the adapter description, Windows version, two timestamps, unchanged output labels, the observed deltas and the symptom. Add the controlled comparison you tried and say what did not change. Avoid exporting unrelated virtual-adapter or address details publicly. This is a useful evidence package even when the correct conclusion is that the local counters did not explain the incident.