PC-side tools tell you packets died. A managed switch tells you where and when - which port, how many damaged frames, and the exact seconds the link went down and came back. If your switch has a web console, the answer to a week of guessing may already be sitting in its statistics page.
Every Ethernet frame carries a checksum. When a frame arrives damaged, the switch counts it - CRC or FCS errors - and usually drops it. Those counters are the difference between opinion and evidence in a packet-loss hunt. Pair them with the switch log, which timestamps every link down and link up, and a marginal cable pair or a duplex mismatch stops being a theory and becomes a row of numbers.
Example only: errors climbing by the thousand during one copy, plus link drops at logged times, convict the physical path on that port - no opinion required.
CRC / FCS errors: frames that arrived corrupted - physical layer trouble on that port: cable pair, termination, interference, or a duplex mismatch tearing frames apart. Runts and giants: frames too short or too long, often collision debris from a half-duplex end. Discards: frames the switch chose to drop, often congestion - different story. Read the error counters first; they separate a sick wire from a busy network in one glance. A healthy port on a healthy link accumulates CRC errors at roughly zero, week after week.
This is the switch-side version of the video method: measure, change one thing, measure again.
If users drop packets through a port whose error counters stay at zero and whose link never flaps, the physical path is probably innocent - look up a level: duplex settings can still tear traffic between specific device pairs (watch for runts more than CRC), an overloaded uplink, or a fault beyond the switch entirely. Counters exonerate as usefully as they convict. Trust them over cable folklore both ways.
Budget unmanaged switches keep no counters and no logs - the honest workaround is to swap in a managed switch, or even a laptop running the counters from the PC side, for the duration of the diagnosis. PC adapters keep their own statistics too: Windows shows some in the adapter status and detailed counters via PowerShell Get-NetAdapterStatistics. A fault that appears once a month may justify one managed switch on the problem segment permanently - it pays for itself the first time it names a port.
See the video case - the same evidence-first method from the PC side, ending at a setting nobody had thought to read.
Watch Full VideoFrames are arriving damaged on that port. The cause lives on that link: a faulty cable pair, a bad termination at the plug, jack or patch panel, strong interference, or a duplex mismatch. Clear the counters, run traffic, and watch whether they climb - a fast climb is a live fault, not history.
Use the PC side: continuous ping counts, adapter statistics with Get-NetAdapterStatistics in PowerShell, and the negotiated link speed. Or place a managed switch on the problem segment temporarily. Unmanaged hardware cannot testify - borrow something that can.
Then this link's physical layer is likely healthy. Check for a duplex mismatch, an overloaded uplink or switch, and faults beyond the switch. Zero counters are a real result: they clear the cable and let you stop re-terminating ends that were never guilty.