.NET Framework 4.7 WinForms应用内存泄漏求助：NtProcessInfoHelper.CachedBuffer

一、定位实例化位置的具体方法 #

• PerfView深度追踪：捕获完整的GC堆快照（而非仅Diff视图），定位System.Diagnostics.NtProcessInfoHelper.CachedBuffer实例后，查看其调用堆栈，向上回溯即可找到触发创建的代码路径。注意开启PerfView的Collect Call Stacks选项，并配置微软符号服务器加载.NET Framework的系统符号，确保堆栈信息完整。
• 代码定向排查：针对项目中using System.Diagnostics;的代码块，重点排查：
  • 调用Process类属性/方法的逻辑，比如WorkingSet64、PrivateMemorySize64、TotalProcessorTime等，NtProcessInfoHelper是.NET内部为Process类提供进程信息的辅助类，这些操作会间接触发它。
  • 自定义性能监控代码，比如定期采集进程内存、CPU使用率的循环逻辑，频繁调用可能导致缓存持续累积。
• 第三方库排查：对BouncyCastle、JSON.Net进行补充排查：
  • 采用增量移除法，临时移除非核心依赖，运行应用观察内存增长是否停止，缩小嫌疑范围。
  • 用ILSpy或dnSpy反编译库文件，搜索是否存在System.Diagnostics.Process相关调用，这是触发NtProcessInfoHelper的核心入口。

二、可能触发CachedBuffer增长的常用类 #

• System.Diagnostics.Process：这是最直接的触发源，几乎所有读取进程状态（内存、CPU、线程等）的操作都会内部调用NtProcessInfoHelper，其CachedBuffer用于复用读取缓冲区，若频繁调用且缓存未被合理回收，会导致内存持续增长。
• System.Diagnostics.PerformanceCounter：部分进程类性能计数器会间接依赖NtProcessInfoHelper获取底层数据，频繁查询场景下可能引发缓存泄漏。
• 自定义监控组件：项目中自行封装的进程状态监控工具类，只要内部调用了Process类成员，都可能触发该缓存的增长。

三、验证与临时缓解方案 #

• 关联性验证：暂停所有可能调用进程信息的逻辑，观察CachedBuffer的增长是否停止，确认泄漏源的关联性。
• 临时缓解：在每日低峰期执行强制垃圾回收：

  GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);
  GC.WaitForPendingFinalizers();
  

  该方法无法彻底解决泄漏，但可延缓内存增长速度，为排查争取时间。

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