C#批量发起Ping异步任务时部分任务永久处于WaitingForActivation状态

这个问题和.NET Task调度机制无关，核心是Windows底层ICMP协议栈的并发请求上限限制：

• 调用SendPingAsync时，请求最终会提交到Windows内核的ICMP发送队列，系统默认对未完成的ICMP请求设置了全局/单进程阈值，这个阈值刚好在1000~1500区间，和你测试到的1300临界点完全吻合。超过阈值后，后续的ICMP请求会被内核直接丢弃，不会触发完成回调，对应的SendPingAsync任务就会永久卡在WaitingForActivation状态。
• 把Ping逻辑替换为Task.Delay后所有任务正常完成，刚好验证了这个结论：Task.Delay是纯用户态的任务调度，没有内核资源限制，只要.NET线程池正常调度就能完成，和ICMP内核队列瓶颈完全无关。
• 你之前尝试的任务调度层面优化（限制Task并发、调整同步上下文等）都没有触及内核ICMP队列的瓶颈，所以不会有效果。

1. 动态并发控制的Ping扫描（适配现有代码逻辑） #

不要一次性创建所有65000个Ping任务，用SemaphoreSlim控制全局并发数，阈值设为1024（刚好低于系统ICMP队列上限），所有IP探测任务排队执行，一旦拿到目标存活IP，直接调用CancellationTokenSource.Cancel()取消所有剩余任务，比你固定分块的方案效率更高：

// 核心逻辑示例
var cts = new CancellationTokenSource();
var semaphore = new SemaphoreSlim(1024); // 并发数对齐ICMP阈值
var targetIPs = GetAllLinkLocalIPs(); // 生成169.254段所有IP
var aliveIPs = new ConcurrentBag<IPAddress>();

var scanTasks = targetIPs.Select(ip => Task.Run(async () =>
{
    if (cts.IsCancellationRequested) return;
    await semaphore.WaitAsync(cts.Token);
    try
    {
        if (cts.IsCancellationRequested) return;
        using var ping = new Ping();
        var reply = await ping.SendPingAsync(ip, 1000);
        if (reply.Status == IPStatus.Success)
        {
            aliveIPs.Add(ip);
            cts.Cancel(); // 找到存活IP直接终止所有剩余探测
        }
    }
    finally
    {
        semaphore.Release();
    }
}, cts.Token));

await Task.WhenAll(scanTasks);

2. ARP扫描（链路本地网段最优方案） #

169.254属于同网段链路本地地址，完全不需要用三层Ping探测，直接发二层ARP请求效率能提升10倍以上：

• ARP是二层协议，不需要IP层路由、ICMP报文封装，超时更短，单请求耗时不到Ping的1/3
• Windows对ARP请求的并发限制远高于ICMP，全段65000个地址最快1~2秒就能扫完
• 实现也很简单，直接调用Windows原生SendARPAPI即可，只要收到目标IP对应的MAC地址回复，就说明设备存活。

3. 调整系统ICMP限制（不推荐） #

如果必须使用高并发Ping，可以修改注册表调整Windows ICMP请求上限，但这个操作会影响系统全局网络稳定性，优先级远低于应用层并发控制方案。

内容的提问来源于stack exchange，提问作者Phil Atkin