如果你维护过任何常驻后台的Windows服务大概率遇到过类似的诡异场景服务没有任何报错日志也正常但内存一天比一天高最后整个机器开始卡顿。这次要记录的GODService内存泄漏修复就是典型的“不动声色慢慢漏”的案例。GODService平时承担着任务调度、WMI状态采集和令牌模拟这几类工作部署在Windows Server和Windows 11工作站上随着运行时间拉长它的私有内存能稳定爬到1.8GB以上同时系统里的分页缓冲池和非分页缓冲池也在涨严重时连Win11笔记本的可用内存都被拖得很低。下面我把完整排查、根因确认、代码修复和回归验证的过程写下来这篇既适合遇到同类问题的运维也适合写长期运行服务的开发人员参考。1. 先搞清楚GODService这次修的是什么1.1 服务定位和运行特征GODService不是那种对外提供页面接口的业务系统它是作为Windows服务宿主里的一个后台常驻进程承担了三件事一是下发并调度各类维护计划任务二是通过WMI定期采集服务器和工作站的状态指标三是部分运维场景下需要用服务账号模拟用户身份去访问特定网络资源或本地共享。部署范围既有Windows Server 2019/2022也有一批Windows 11的办公终端。这类服务最大的特点就是长时间运行开机启动、关机退出中间几乎不重启。恰恰是这种运行模式让内存泄漏暴露得特别彻底。普通前台程序漏一点内存用户关掉重开就恢复了但Windows服务一旦泄漏会随着运行天数持续累积直到把物理内存吃满最后影响同一台机器上的其他进程。在我们这边GODService刚启动时占用大约120MB运行到第三天就会突破600MB到第五天稳定涨到1.8GB以上句柄数也跟着从几百涨到上万。另外还有一个容易被误判的现象任务管理器里“内核内存”一栏显示的分页缓冲池和非分页缓冲池也在同步上升。一开始团队里有同事怀疑是Windows 11某个版本的系统级泄漏差点把问题甩给操作系统更新。后来把GODService停掉池内存曲线明显平稳重新启动后又继续涨这才确定问题还是出在服务自身或者说出现在服务与系统内核交互的方式上。1.2 修复目标要分成三个层面修复前我们先把“内存泄漏”这个词拆开否则很容易被表象带偏。这次问题实际上叠加了三层泄漏第一层是用户态私有内存也就是任务管理器里看到的GODService进程内存列涉及托管堆、缓存队列和WMI事件订阅残留。第二层是系统级的分页缓冲池和非分页缓冲池普通进程本身不能直接分配内核池内存但可以通过反复打开内核对象句柄、触发驱动分配缓冲区间接让系统池内存不断上升。第三层是句柄、模块、线程这类资源型泄漏表现不一定直观反映在字节数上但最终都会反馈到内存和系统稳定性上。所以这次修复的目标不是机械地把内存压到某个数字而是消除“随运行时间线性增长”的趋势让服务启动后内存曲线趋平句柄数量稳定在合理范围系统池内存恢复基线水平。针对三层问题分别定位、分别修复、最后统一验证这就是整篇报告的基本思路。2. 排查全过程从任务管理器到Poolmon一步步锁定2.1 现象复盘先确认是增长趋势而不是瞬时抖动这次排查第一步做得比较简单但非常关键建立基线画增长趋势。我没有直接抓dump而是先用性能计数器记录GODService进程的Private Bytes、Working Set和Handle Count每半小时采样一次连续观察24小时。采集结果很清晰Private Bytes每隔几小时稳定增加几十MBHandle Count同步增长增长斜率几乎恒定。这种“匀速增长”基本可以排除缓存预热和正常业务波动属于典型的资源生命周期泄漏。如果是缓存问题通常是启动初期快速上涨之后到达上限趋于稳定只有对象被创建但一直没有释放才会出现这种无限延伸的直线。另一个细节是每次重启GODService进程内存会立刻回落到120MB左右这进一步说明泄漏源就在进程内部不在其他外部组件或驱动。还有一个现象在Windows 11上特别明显当GODService运行超过两天任务管理器“性能”页的内存组合图里非分页缓冲池部分持续走高系统提交内存也跟着升高。用resource monitor查看时GODService进程本身没有占用那么多物理内存但系统池内存却在增长这说明关于“服务导致系统池内存泄漏”的判断不能再靠猜得用工具定位到具体对象类型。2.2 用Process Explorer和Poolmon锁定泄漏方向在Windows平台上排查这种问题Process Explorer和Poolmon这两款工具是最直接的突破口。先用Process Explorer打开GODService进程属性在Performance选项卡里看Private Bytes和Virtual Size的趋势线在Handles选项卡里看句柄类型分布。当时我注意到一个有趣的事实句柄列表里出现了大量重复的Token类型句柄和File类型句柄数量占整体句柄的一半以上。Token对象就是访问令牌对应服务做身份模拟时调用LogonUser之类的API产生的File对象则通常是文件句柄没关干净。这两个方向正好和服务自身的业务逻辑对应嫌疑立刻集中。接下来需要确认这些对象是否对应系统内存池的上涨。这里用到Sysinternals的Poolmon。在管理员终端启动Poolmon让它实时刷新然后按增长量排序。注意Poolmon统计的是整个系统的池分配单看当前值没有意义必须隔几分钟再回来看哪个Pool Tag的计数在持续增长。观察结果里反复出现两个标签Toke和File英文全称分别是Token和File对象相关分配而且都落在非分页池。非分页池里的内存是不能换到磁盘的内核内存如果这个区域持续增加要么是驱动没释放要么是进程生成了大量关联内核对象的引用。这里要补充一个容易踩的坑Poolmon给出的Tag只能告诉你什么类型的对象在内核池里占据内存不能直接告诉你谁创建的。Token和File这类对象也并非只有GODService会创建所以我又用了Process Explorer把GODService进程的句柄按类型分组确认Token和File两类句柄的数量增长节奏与内存池上涨节奏一致这才敢把责任指向服务。排查思路就是先锁定系统池里增长的对象类型再回到进程的句柄表里找同一类型两边对齐证据链闭合。2.3 Windows 11分页/非分页缓冲池泄漏为什么值得单独看搜索热词里反复出现“win11 分页缓冲池和非分页缓冲池内存泄漏”这说明很多人在Windows 11上遇到了系统池持续增长的问题。这里先理清概念因为两个池经常被混在一起说。分页缓冲池是内核中可被换出到磁盘的内存区域主要放一些不太频繁访问的内核数据结构非分页缓冲池则永远驻留在物理内存中任何中断上下文或DMA操作需要访问的数据都必须放在这里。非分页池一旦泄漏对系统内存的影响更直接因为这部分内存无法通过“吃满后自动换页”来自我调节。Windows 11上比较容易出现池泄漏的区域集中在网络驱动、WFP过滤驱动、图形驱动和一些第三方安全软件。比如NDIS相关的缓冲区、WFP过滤器会话如果没有清理都会让非分页池持续增长。这也是为什么一开始我们怀疑过系统自身。但最终定位结果说明Windows服务的普通用户态代码虽然不能直接分配池内存却可以通过反复创建内核句柄、反复调用设备控制接口、反复触发驱动级资源分配让系统池内存被一点点抬高。理解这个因果关系排查方向才不会跑偏。3. 三层根因拆解泄漏其实不在一个地方3.1 第一层根因WMI事件订阅从未解除GODService里有一个监控采集模块核心逻辑是创建ManagementEventWatcher对象订阅WMI事件一旦机器出现指定事件就触发回调随后把事件数据写入队列。问题就出在这个订阅对象创建后只调用了Start方法服务的整个生命周期里从不调用Stop也从不取消EventArrived事件上的回调委托。在.NET环境下ManagementEventWatcher内部会向WMI Provider注册一个事件订阅进程退出或Watcher被Dispose之前这个订阅会一直保留。如果服务启动后业务逻辑又多次重建Watcher每次重建都会导致旧订阅继续存在新订阅不断累积最终造成两个后果一是托管堆里残留大量无法回收的事件订阅对象和事件数据二是WMI Provider内部为每个订阅保持的上下文和缓冲区越积越多直接推高进程私有内存。代码层面的错误写法大致是这样_watcher new ManagementEventWatcher(scope, query); _watcher.EventArrived OnEventArrived; _watcher.Start();看起来没什么问题问题在于整个服务找不到对应的停止逻辑。这属于典型的“只订阅、不取消”生命周期泄漏。排查时用dotnet-dump抓了两份GC堆快照对比第一份和半小时后的第二份对比发现ManagementEventWatcher关联的对象实例数量在持续增加和模拟业务触发的次数完全正相关基本坐实了这层原因。3.2 第二层根因令牌句柄和文件句柄泄漏第二个问题比第一个更隐蔽因为它不直接体现在进程的Private Bytes里而是体现在系统非分页池增长上。GODService有一个模块需要定期做身份模拟调用LogonUser拿到用户令牌后再用WindowsIdentity.Impersonate切到目标身份访问共享资源。问题出在句柄没有释放。早期代码是直接用IntPtr接收LogonUser返回的句柄业务执行完只是调用了Impersonate的还原却没有调用CloseHandle。这样的代码反复执行后每模拟一次身份就漏掉一个Token句柄。Token对象对应的内核内存分配在非分页池所以句柄表越来越大非分页池也越涨越高。Poolmon里看到的Toke标签持续增长源头就在这。同类问题还出现在文件操作上。服务里有几段读取配置和临时文件的逻辑用了FileStream但没包using异常路径下完全没有释放。于是Poolmon里又出现了File标签的持续增长文件对象属于内核对象同样占用非分页池。这层问题提醒我很多看起来像“系统池内存泄漏”的现象追到底还是应用层对内核对象句柄的生命周期管理出了问题。3.3 第三层根因定时任务调度队列的无限堆积第三层问题出在服务自己的调度器。GODService维护了一个业务任务队列定时把待执行任务放入队列由后台线程逐条消费。本来队列的容量应该是有上限的但历史代码里只做了入队、没有做淘汰也没有在消费失败时重新入队前做次数限制。实际运行中部分WMI采集任务偶尔会因为目标机器无响应而卡住任务会带着错误状态一直留在集合里。长时间下来这个集合越堆越多里面的业务对象、异常对象、关联的上下文对象全部引用在一起GC根本无法回收。这一层主要推高进程私有内存也让任务处理耗时增长形成恶性循环。三层根因并列来看恰好覆盖了内存泄漏最常见的三个面向事件回调无注销、内核句柄无释放、业务集合无淘汰。排查时如果只盯着其中一层去修漏掉另外两层内存曲线只会暂时好转时间一长又会复发。这也是我把报告写得比较全的原因。4. 修复落地代码层面怎么改才能根治4.1 给事件订阅和Timer建立显式生命周期第一处修复是把WMI事件订阅的创建和停止逻辑显式化。修好的代码必须保证Start、Stop、Dispose成对出现事件订阅回调也要在Dispose之前先解除。因为在.NET EventArgs这类委托链里如果只Dispose而不解除自身事件对象仍可能被事件源引用住无法被GC回收。修复后的核心逻辑_watcher new ManagementEventWatcher(scope, query); _watcher.EventArrived OnEventArrived; _watcher.Start(); // 在服务停止或者组件不再需要时按顺序执行 _watcher.Stop(); _watcher.EventArrived - OnEventArrived; _watcher.Dispose(); _watcher null;这里有个容易忽略的细节Stop和Dispose不是一回事。Stop是让Watcher停止接收新事件Dispose是释放非托管资源和事件句柄。如果只Dispose不Stop在某些WMI Provider实现下订阅未必会被完整清理如果只Stop不Dispose托管资源还会继续占用。正确顺序是先Stop再解除事件委托再Dispose。服务里另一个位置用到了System.Timers.Timer每次触发时都重新创建Timer实例这同样会让旧的Timer对象引用残留在事件调度器里。修复策略是只创建一个Timer在初始化阶段注册Elapsed回调在停止时调用Dispose并置空。4.2 句柄释放和SafeHandle使用规范针对Token句柄和文件句柄泄漏修复方式是把裸句柄IntPtr全部替换成SafeHandle并保证所有使用点都在using块内。SafeHandle的好处是即使业务代码抛出异常对象的析构逻辑也会在托管运行时执行非托管句柄释放不再依赖开发人员手动补齐CloseHandle。以LogonUser调用为例修改后的写法[DllImport(advapi32.dll, SetLastError true, CharSet CharSet.Unicode)] static extern bool LogonUser( string lpszUsername, string lpszDomain, string lpszPassword, int dwLogonType, int dwLogonProvider, out SafeAccessTokenHandle phToken); if (LogonUser(user, domain, password, LOGON32_LOGON_NEW_CREDENTIALS, LOGON32_PROVIDER_DEFAULT, out SafeAccessTokenHandle token)) { using (token) using (WindowsIdentity.Impersonate(token.DangerousGetHandle())) { // 执行业务逻辑 } }文件对象同理所有FileStream都套using不再出现裸new FileStream之后只调用Close但没放finally的情况。这里还要注意一点FileStream的Close和Dispose看似等效但还是统一走using最稳妥避免文件句柄在异常分支漏关。4.3 服务停止时优雅关闭所有后台组件修好局部问题之后还要把服务层面的生命周期串起来。Windows服务不是把OnStop里写上Environment.Exit就能跑路的SCM会有超时逻辑服务停止时机和后台线程的清理时机如果没对齐照样可能留下半初始化状态的组件。这次改造把服务内所有后台循环统一接收一个CancellationToken启动时创建TokenSource停止时先Cancel再等待任务队列处理完剩余任务最后释放WMI Watcher、Timer、句柄相关组件。OnStop简化后大概是这样的逻辑protected override void OnStop() { _cts.Cancel(); _taskQueue.CompleteAdding(); Task.WaitAll(_workerTasks, TimeSpan.FromSeconds(30)); _watcher?.Stop(); _watcher?.Dispose(); _timer?.Dispose(); base.OnStop(); }之所以先取消再等待固定超时是避免某个任务卡在外部调用上导致服务停止超时。等待30秒后如果还没结束日志会记录异常但服务本身不会一直挂在那。4.4 为什么没有用“定时GC”这种偏方修复过程中有同事提过一个很直接的问题与其改这么多不如每分钟调一次GC.Collect让内存降下来不就行了这里必须说明为什么这是偏方。强制GC只能回收托管堆里没有被引用的对象而这次三层根因里涉及的WMI订阅、Token句柄、任务队列都是被引用状态或非托管资源GC完全管不到。即使强制回收后看到Private Bytes短暂下降也只是把可回收的临时数据清了泄漏源依旧存在过几个小时曲线又会涨回去。更麻烦的是强制GC在高频场景下会让服务性能明显变差因为GC需要挂起所有托管线程去做标记和压缩这会直接影响任务调度的及时性。代码改了之后GODService在完全不调用GC.Collect的情况下内存曲线自然保持平稳这才算真正修复。5. 验证与回归连续跑7天看什么指标5.1 压力测试方案设计修复完成后的验证不能只在测试机启动半小时看一次内存就算通过。长期运行服务的回归测试至少需要覆盖泄漏产生的所有路径并连续运行数天。这次压测设计了三个场景第一个场景是高频率WMI事件订阅和释放模拟监控采集模块反复启动和停止第二个场景是高密度身份模拟操作让LogonUser和文件读取在一个循环里连续执行第三个场景是长时间任务调度队列里不断加入任务并随机制造超时观察集合是否还能保持稳定。测试环境选了一台Windows 11 24H2笔记本和一台Windows Server 2022虚拟机前者重点观察分页缓冲池和非分页缓冲池变化后者重点观察服务稳定性和句柄数。两台机器都按生产环境相同的计划任务频率运行连续跑14天没有重启服务。第14天的内存状态和第一天对比波动范围基本一致没有出现持续斜率。改造前同期运行的状态是Private Bytes从120MB涨到1.8GB以上改造后稳定在120MB到160MB之间句柄数长期维持在800以内。5.2 关键观察指标和告警阈值回归测试我把观察指标固定成一套后续告警也直接复用这套口径。最重要的四个指标是进程私有内存、进程句柄数、系统非分页池字节数、系统分页池字节数。其中句柄数和私有内存反映用户态泄漏两个池字节数反映内核侧资源是否有残留。观察指标修复前状态第5天修复后状态第14天建议告警阈值Process\Private Bytes1.8GB持续上升120~160MB波动连续2小时超过400MBProcess\Handle Count1.5万以上持续上升800以内超过3000触发告警Memory\Pool Nonpaged Bytes高位且每日递增恢复基线无趋势连续3个采样点递增时告警Memory\Pool Paged Bytes偏高且波动大无趋势波动连续3个采样点递增时告警任务队列积压长度长期积压0~10超过50持续10分钟这里要注意池内存本身会随业务负载波动单次冲高不能说明问题必须看“趋势”。所以我建议告警逻辑写成连续N个采样点递增而不是只看瞬时值。这样既能抓住泄漏又不会因为周期性任务导致误报。5.3 回归结果和遗留风险回归测试数据整体符合预期。非分页池在修复前每天能涨数百MB修复后14天内在几十MB范围内波动这种波动属于正常业务负载带来的池分配任务结束系统会自动回收。句柄数从1.5万降到800以内是最直观的证据说明Token对象和File对象不再残留。遗留风险也提一下。WMI本身与系统组件的交互比较封闭某些第三方WMI Provider如果自身存在泄漏在极端场景下仍可能让系统池内存出现小幅增长。这部分只能通过监控兜底。另外非分页池和分页池的上涨并不一定都是由应用导致的如果哪天服务已经停止但池内存依然上涨那就应该去摸网卡驱动、杀毒软件、WFP过滤驱动不要再盯GODService。区分“服务引起的池增长”和“系统驱动引起的池增长”最有效的办法就是停止服务观察曲线斜率。6. 防再漏把这套检查固化成日常流程6.1 把内存健康检查做成自动化巡检修复GODService之后我把这次用过的指标整理成了一个自动化巡检脚本。做法很简单就是每30分钟用Get-Counter采集一次关键指标写入本地日志文件再用一个小脚本判断相邻采样点的增量。采集命令大概是这样的$counters ( \Process(GODService)\Private Bytes, \Process(GODService)\Handle Count, \Memory\Pool Nonpaged Bytes, \Memory\Pool Paged Bytes ) Get-Counter -Counter $counters -SampleInterval 1800 -MaxSamples 48 | Export-Csv -Path C:\Monitor\godservice_mem.csv巡检本身不追求实时只要能把趋势记录下来就行。连续出现三次递增就告警比等到内存爆了再去复盘实用得多。这套脚本不仅适用于GODService换成其他Windows服务同样成立只需要改进程名和性能计数器路径。6.2 给团队的两个实操建议最后说两条落地经验。第一代码评审里必须把“释放”当成和“分配”同等级的关注点。凡是看到事件订阅、Timer、文件流、P/Invoke返回句柄、WMI Watcher都要追问一句对象在哪里释放异常路径会不会漏。尤其是服务类项目启动时创建的订阅和回调在OnStop里必须成对清理。第二发布前做一次“基础内存固化测试”。不用搞多复杂把服务跑起来按生产频率触发三类高风险操作连续跑3天对比第一天和最后一天的Private Bytes、Handle Count、Pool Nonpaged Bytes。如果三天内三条曲线都没有明显斜率那么绝大多数泄漏问题都能在上线前暴露出来。最后再分享一个我自己的小习惯发现进程内存上涨第一件事不是着急改代码而是先算增长率。拿两个时间点的Private Bytes和Handle Count做差分如果斜率稳定大概率是对象生命周期问题如果是台阶状上涨才更可能是缓存或者池分配突变。这次GODService能一次修到位靠的就是先把增长斜率抓明白了。后面你们自己遇到类似问题不妨也照着这个顺序来一遍能省下很多盲查的时间。