监控windows服务内存泄漏需区分用户模式（private bytes持续增长）与内核模式（pool nonpaged bytes刚性上涨），结合60–300秒采样、8小时以上趋势分析，并用process explorer、umdh或dotmemory定位根因。
监控 windows 服务中的内存泄漏，关键在于区分泄漏发生在用户模式（服务进程自身）还是内核模式（驱动或系统组件），并用对的工具、对的计数器、对的时间尺度来观察变化趋势。任务管理器只能看“此刻占多少”，而泄漏是“越用越多还不还”，必须靠持续追踪才能识别。
盯住核心计数器：服务进程私有内存
Windows 服务本质是运行在 svchost.exe 或独立可执行文件中的进程，其用户模式泄漏主要体现在私有内存持续增长：
- Process\Private Bytes：这是最直接指标。它统计该服务进程独占分配的所有内存（含堆、栈、映射内存等），不包含共享部分。若某服务的 Private Bytes 在空闲状态下仍每小时稳定上升 20–50MB 且不回落，基本可判定存在泄漏。
- Process\Working Set：反映当前驻留物理内存大小。若 Private Bytes 持续涨而 Working Set 波动不大，说明泄漏内存未被频繁访问，可能已变成“僵尸内存”；若两者同步涨，则更可能是活跃堆泄漏。
- .NET CLR Memory\# Bytes in all Heaps（仅限 .NET 服务）：若服务基于 .NET，此计数器比 Private Bytes 更敏感。配合 Gen 2 Collections 观察——如果二代回收频繁发生但堆内存不降，大概率是对象被静态引用或事件未解绑导致无法释放。
判断泄漏是否来自内核层
有些服务（如打印、网络、存储类）会加载内核驱动或调用底层 API，泄漏可能藏在内核池中：
- Memory\Pool Nonpaged Bytes：非分页池占用持续上涨（例如 4 小时内从 300MB 升至 900MB 且无回落），尤其伴随系统变慢、服务无响应或事件日志出现 “The server service terminated due to nonpaged pool exhaustion”，就指向驱动级泄漏。
- Memory\Pool Paged Bytes：若该值同步增长，说明泄漏可能涉及多层内核组件（如 WMI 提供程序、过滤驱动）；若仅 Nonpaged 上涨而 Paged 平稳，则更可能是纯内核驱动问题。
- Memory\Available MBytes：应与 Pool Nonpaged 呈反向刚性关联——它单向不可逆下降，且下降量≈Nonpaged 增长量，就是典型内核泄漏特征。
设置有效监控策略
短时间快照容易误判缓存行为，必须用合理节奏长期观察：
- 采样间隔设为 60–300 秒（1–5 分钟），太密影响性能，太疏错过拐点；
- 总监控时长建议 至少 8 小时，覆盖服务启动、业务周期、空闲期；
- 使用数据收集器集（logman 或 PerfMon GUI）保存为 二进制循环日志（.blg），避免磁盘写满；
- 重点对比“操作前—操作中—操作后”的三段曲线：真正泄漏会在操作结束后仍继续爬升，而非随负载下降而回落。
定位到具体服务后深入分析
确认某个 svchost.exe 实例或独立服务 exe 存在 Private Bytes 异常后，下一步不是猜，而是抓证据：
- 用 Process Explorer 查看该进程的线程、句柄、GDI 对象是否同步增长，辅助判断泄漏类型；
- 用 UMDH 配合 GFlags 开启用户模式堆栈跟踪，生成两个时间点快照并比对，直接定位到分配未释放的代码调用栈；
- 若怀疑 .NET 服务，可用 dotMemory 或 Visual Studio Diagnostic Tools 抓取内存快照，查看哪些对象实例数异常增多、谁持有了它们的根引用。
