这种本地独有、突然发作的性能问题确实挺棘手的，结合我之前处理类似问题的经验，给你列几个可落地的排查步骤，按顺序试效率更高：

• 先排查虚拟网卡/异常适配器：这个API会枚举系统所有网络适配器，包括虚拟网卡（比如VPN、Docker、Hyper-V、虚拟机生成的网卡）。如果某个虚拟网卡处于异常状态（比如驱动挂了、连接超时），会拖慢整个枚举过程。你可以打开「设备管理器」→「网络适配器」，看看有没有带黄色感叹号的设备，或者先禁用最近新增的虚拟网卡，再测试API调用速度。也可以用命令行跑ipconfig /all，对比团队其他成员的网卡列表，看看有没有多余的、状态异常的条目。

• 回溯系统近期变更：既然问题是近期出现的，先回忆下这段时间有没有做过这些操作：安装新的VPN/杀毒/虚拟化软件、更新系统补丁、修改网络配置？比如部分杀毒软件的「网络流量监控」功能会拦截这个API的底层调用，导致超时。可以临时禁用杀毒软件的实时防护，再测试耗时；如果是刚更了系统补丁，试试卸载对应补丁看是否恢复。

• 用工具追踪底层操作：用Process Monitor（ProcMon）来监控调用这个API时的系统行为——过滤你的进程名，观察调用期间所有的文件、注册表、网络操作，找耗时最长的那个操作项，通常就能定位到卡住的根源（比如某个网卡驱动在读取超时的硬件信息、或者某个注册表项访问慢）。也可以用Windows事件查看器，看看有没有和网络、WMI相关的错误日志。

• 测试极简代码隔离问题：写个纯控制台程序，只包含以下代码，排除业务代码的干扰：

  using System;
  using System.Net.NetworkInformation;
  
  class Program
  {
      static void Main()
      {
          var sw = System.Diagnostics.Stopwatch.StartNew();
          var interfaces = NetworkInterface.GetAllNetworkInterfaces();
          sw.Stop();
          Console.WriteLine($"耗时：{sw.ElapsedMilliseconds}ms，找到{interfaces.Length}个网卡");
      }
  }
  

  如果这个极简程序还是慢，那100%是本地系统环境的问题，和业务代码无关；如果速度正常，再回头排查业务代码里的上下文、锁、其他依赖逻辑。

• 检查WMI服务状态：GetAllNetworkInterfaces()底层依赖WMI（Windows Management Instrumentation）服务，比如Winmgmt服务。可以打开「服务」面板，看看这个服务是否正常运行；如果状态异常，试试重启它：

  net stop winmgmt
  net start winmgmt
  

  注意：重启WMI服务会影响所有依赖它的程序，操作前尽量关闭其他无关软件。

• 对比网卡驱动与系统配置：看看你的物理网卡驱动版本，是不是和团队成员的不一样？如果最近更新过驱动，试试回滚到之前的稳定版本；如果驱动很久没更，更新到官方最新版。另外用PowerShell跑Get-NetAdapter命令，如果这个命令也慢，那说明是系统网络栈的问题，不是.NET API的锅，可以考虑重置网络栈：

  netsh int ip reset
  netsh winsock reset
  

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