You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Learn how to troubleshoot TCP/IP packet loss.
4
4
ms.date: 04/28/2025
5
5
ms.topic: troubleshooting
@@ -11,108 +11,94 @@ ms.custom:
11
11
ms.reviewer: kaushik, mifriese, v-lianna
12
12
audience: itpro
13
13
---
14
-
# Diagnosing Packet Loss on Windows
14
+
# Diagnose packet loss in Windows
15
15
16
-
## Overview
16
+
Packet loss occurs whenever a network packet doesn't reach its intended destination. Some packet loss is normal, and doesn't always cause higher-level networking issues. At other times, packet loss can reduce performance, and cause application programming interfaces (APIs) or applications to fail.
17
17
18
-
Packet loss occurs whenever a network packet does not reach its intended destination. Some packet loss is normal, and a dropped packet does not automatically imply it is the cause of a higher-level networking issue. At other times, packet loss can cause reduced performance, and APIs or even applications to fail.
18
+
## Capture and diagnose packet loss
19
19
20
-
## Capturing Packet Loss Diagnostics
20
+
The first step when conducting a packet loss investigation is to capture [Packet Monitor (Pktmon)](/windows-server/networking/technologies/pktmon/pktmon) traces, typically by using the pktmon command-line workflow. Pktmon can capture packet traces, attribute local packet loss to specific reasons and code locations, and collect packet loss statistics. When combined with [Wireshark](https://www.wireshark.org/) analysis of protocol-level behavior, pktmon traces are sufficient to identify the root causes of many cases of packet loss.
21
21
22
-
The first step when conducting a packet loss investigation is to capture [pktmon](https://learn.microsoft.com/windows-server/networking/technologies/pktmon/pktmon) traces, typically by using the pktmon command-line workflow. Pktmon is capable of capturing packet traces, attributing local packet loss to specific reasons and code locations, and collecting packet loss statistics. When combined with [Wireshark](https://www.wireshark.org/) analysis of protocol-level behavior, pktmon traces are sufficient to root cause many cases of packet loss. Pktmon will also be capable of collecting packet loss statistics within network cards, but as of early 2025, this feature is not available.
22
+
If pktmon diagnostics are inconclusive, more exhaustive component-level traces can be captured using the `netsh.exe trace start scenario=InternetClient` or `netsh.exe trace start scenario=InternetServer`command for client and server scenarios respectively. After the events are captured, stop the trace by using the `netsh.exe trace stop` command. These component-level traces are noisy and not clear, but often contain additional context before or after a local packet is dropped. For remote loss, they might indicate that the local system has inferred the occurrence of packet loss. The traces can be converted to text using `netsh.exe trace convert nettrace.etl`, opened in [Windows Performance Analyzer](/windows-hardware/test/wpt/windows-performance-analyzer), or used with any other Event Tracing for Windows (ETW) tool.
23
23
24
-
If pktmon diagnostics are inconclusive, more exhaustive component-level traces may be captured using netsh.exe trace start scenario=InternetClient or netsh.exe trace start scenario=InternetServer for client and server scenarios respectively, followed by netsh.exe trace stop after the events have been captured. These component-level traces are relatively noisy and opaque, but often contain additional context before or after a local packet is dropped, or for remote loss, an indication the local system has inferred packet loss has occurred. The traces can be converted to text using netsh.exe trace convert nettrace.etl, opened in [Windows Performance Analyzer](https://learn.microsoft.com/windows-hardware/test/wpt/windows-performance-analyzer), or used with any other ETW tool.
24
+
If the network interface card (NIC) is suspected as a cause of the packet loss, you can monitor its discard counters through any [performance counters](/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) interface or the [Get-NetAdapterStatistics](/powershell/module/netadapter/get-netadapterstatistics) cmdlet.
25
25
26
-
If the network interface (NIC) is suspected as a cause of packet loss, its discard counters can be monitored through any [Performance Counters](https://learn.microsoft.com/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) interface or the [Get-NetAdapterStatistics](https://learn.microsoft.com/powershell/module/netadapter/get-netadapterstatistics?view=windowsserver2025-ps) cmdlet.
26
+
## Common causes of packet loss
27
27
28
-
##Common Causes of Packet Loss
28
+
### Local packet loss
29
29
30
-
### Local Packet Loss
30
+
Local packet loss is fully observable and can be caused by various internal and external factors.
31
31
32
-
Local packet loss is fully observable and can be caused by a variety of internal and external factors.
32
+
- Local policy: inspection software might cause packets from remote machines to be dropped by default, such as when the Windows Firewall rejects inbound connection attempts. Cybersecurity or anti-malware software on the system can also cause these issues.
33
+
- Low resources: if the system or socket has run out of resources to handle the packet, the packet will be dropped. Examples of resource limits include physical memory on the system and socket send or receive buffers. Depending on the resource limit, these events might last only microseconds, such as when the system's CPU can't react quickly enough to a full receive buffer.
34
+
- ARP/ND failure: if the next hop for an outbound packet doesn't respond to Address Resolution Protocol (ARP) or neighbor discovery (ND) requests, then packets sent to that next hop will be dropped on the local system. Packets might also be dropped during ARP/ND processes if the ARP/ND packet queue limit is exceeded. The ARP/ND packets themselves are typically not dropped locally and belong to the remote packet loss category.
35
+
- No route: if the network layer can't find a valid route to the destination, packets might be dropped.
36
+
- Invalid packet: if the packet headers are invalid, the packet might be dropped. For example, the packet headers contain an invalid checksum or field value.
33
37
34
-
- Local policy: inspection software will often cause packets from remote machines to be dropped by default, such as when the Windows firewall rejects inbound connection attempts. These can also be caused by cybersecurity/anti-malware software on the system.
38
+
### Remote packet loss
35
39
36
-
- Low resources: if the system or socket has run out of resources to handle the packet, it will be dropped. Examples of resource limits include physical memory on the system and socket send/receive buffers. Depending on the resource limit, these events may last only microseconds, such as when the system’s CPU cannot react quickly enough to a full receive buffer.
40
+
Remote packet loss isn't directly observable to the local machine when the packet is dropped. The IP (Internet Protocol) protocol and most layers below it are "best effort" and not reliable. The [end-to-end principle](https://en.wikipedia.org/wiki/End-to-end_principle) requires endpoints to implement reliability within their protocols if resilience to packet loss is required. In some scenarios, the network or remote endpoint sends a protocol-specific error message indicating the reason for the loss. However, in many cases, the only indication of packet loss is a lack of response.
37
41
38
-
- ARP/ND failure: if the next hop for an outbound packet does not respond to ARP or neighbor discovery (ND) requests, then packets sent to that next hop will be dropped on the local system. Packets may also be dropped while ARP/ND is occurring if the ARP/ND packet queue limit is exceeded. The ARP/ND packets themselves are typically not dropped locally and belong to the remote packet loss category.
39
-
40
-
- No route: if the network layer cannot find a valid route to the destination, packets will be dropped.
41
-
42
-
- Invalid packet: if the packet headers are invalid, e.g. contain an invalid checksum or field value, the packet will be dropped.
43
-
44
-
### Remote Packet Loss
45
-
46
-
Remote packet loss is not directly observable to the local machine at the instant the packet is dropped: the IP protocol and most below it are “best effort” and not reliable. The [end-to-end principle](https://en.wikipedia.org/wiki/End-to-end_principle) requires endpoints to implement reliability within their protocols if resilience to packet loss is required. In some scenarios, the network or remote endpoint sends a protocol-specific error message indicating the reason for loss, but in many cases, the only indication of packet loss is a lack of response.
47
-
48
-
- Congestion: loss-based congestion control algorithms send faster and faster until a packet is lost. If the algorithm infers the loss was caused by [congestion](https://en.wikipedia.org/wiki/Network_congestion), it temporarily reduces the rate of sending in response. These algorithms require a small amount of loss to provide a feedback signal.
49
-
50
-
- Remote policy: the network or remote machine may drop packets per its own policy.
51
-
52
-
- Destination unreachable: this can occur if the remote machine does not have a socket bound to the remote port, remote machine is offline, the network cannot find a path to the remote machine, etc.
53
-
54
-
- Session loss: if the network (including stateful NAT, firewalls, load balancers, etc.) or the remote machine is reset or has not received a packet recently, its session context may expire, and subsequent packets are dropped.
55
-
56
-
- MTU drops: may produce an ICMP fragmentation required / packet too big error if the size of the packet exceeds the maximum transmission size of a network link along the path to the remote machine.
42
+
- Congestion: loss-based congestion control algorithms send faster and faster until a packet is lost. If the algorithm infers the loss is caused by [congestion](https://en.wikipedia.org/wiki/Network_congestion), it temporarily reduces the rate of sending in response. These algorithms require a small amount of loss to provide a feedback signal.
43
+
- Remote policy: the network or remote machine might drop packets according to its own policy.
44
+
- Destination unreachable: this can occur if the remote machine doesn't have a socket bound to the remote port, remote machine is offline, or the network can't find a path to the remote machine.
45
+
- Session loss: if the network (including stateful Network Address Translation (NAT), firewalls, load balancers, and so on) or the remote machine is reset or hasn't received a packet recently, its session context might expire, and subsequent packets are dropped.
46
+
- Maximum Transmission Unit (MTU) drops: this might produce an Internet Control Message Protocol (ICMP) fragmentation required or packet too big error if the size of the packet exceeds the maximum transmission size of a network link along the path to the remote machine.
57
47
58
48
## Examples
59
49
60
50
### Pktmon
61
51
62
52
Running the following commands:
63
53
64
-
```cmd
54
+
```console
65
55
pktmon.exe start -c
66
56
pktmon.exe stop
67
57
pktmon.exe etl2txt PktMon.etl
68
58
```
69
59
70
-
The resulting PktMon.txt file contains lines such as:
60
+
The resulting **PktMon.txt** file contains lines such as:
71
61
72
-
```txt
73
-
[30]0000.0000::2025-03-27 16:10:34.934020500 [Microsoft-Windows-PktMon] Drop: PktGroupId 8444249301423149, PktNumber 1, Appearance 0, Direction Rx , Type IP , Component 49, Filter 1, DropReason INET: transport endpoint was not found , DropLocation 0xE000460A, OriginalSize 402, LoggedSize 148
62
+
```output
63
+
[30]0000.0000::<DateTime> [Microsoft-Windows-PktMon] Drop: PktGroupId 8444249301423149, PktNumber 1, Appearance 0, Direction Rx , Type IP , Component 49, Filter 1, DropReason INET: transport endpoint was not found , DropLocation 0xE000460A, OriginalSize 402, LoggedSize 148
This indicates the outbound ICMP packet was dropped due to WFP inspection. The next step for WFP is to follow the [WFP live drops troubleshooting steps](https://learn.microsoft.com/windows/security/operating-system-security/network-security/windows-firewall/troubleshooting-uwp-firewall#debugging-live-drops).
85
+
This information indicates the outbound ICMP packet was dropped due to Windows Filtering Platform (WFP) inspection. The next step for WFP is to follow the [WFP live drops troubleshooting steps](/windows/security/operating-system-security/network-security/windows-firewall/troubleshooting-uwp-firewall#debugging-live-drops).
96
86
97
-
In another scenario, a previously sent TCP segment has not been acknowledged by the remote endpoint, and eventually a local retransmit timer fires, causing TCP to re-send some of the potentially lost data:
87
+
In another scenario, a previously sent TCP segment hasn't been acknowledged by the remote endpoint, and eventually a local retransmit timer fires, causing TCP to resend some of the potentially lost data:
98
88
99
89
```txt
100
-
[31]0000.0000::2025/03/27-16:12:19.937105000 [Microsoft-Windows-TCPIP]TCP: Connection 0xFFFFE189BD811AA0 0(RetransmitTimer) timer has expired.
0 commit comments