内核态进程级内存泄漏拦截需钩住NtAllocateVirtualMemory和ExAllocatePoolWithTag，在分配时用per-CPU ring buffer记录PID/Tag/Size/栈帧，释放时匹配清除，未匹配且连续3次净增＞64KB则转储完整栈至MemoryLeakSnap.bin，并通过引用图快照与进程退出监听闭环验证泄漏。
内核态拦截进程级直接泄漏，核心不是“加日志”，而是让泄漏行为在发生瞬间就被感知和标记——这必须绕过用户态抽象层，直击内存分配原语与进程生命周期的交汇点。
定位关键拦截点：从进程创建到堆分配的链路
进程级直接泄漏通常表现为：进程持续调用 nt!NtAllocateVirtualMemory 或 nt!ExAllocatePoolWithTag 但未配对释放。内核钩子需卡在这些函数入口前，而非用户态的 malloc 或 HeapAlloc。
-
首选目标函数：Hook
NtAllocateVirtualMemory（用户空间映射）与ExAllocatePoolWithTag（内核空间分配），二者均带明确Tag参数，可天然分类追踪 -
避坑提示：不要 Hook
Zw*系列——它们是用户态调用门，实际执行仍走Nt*；也不要 HookMmAllocatePagesForMdl等底层页管理函数，粒度太细、噪声太大 -
进程上下文绑定：在钩子中通过
PsGetCurrentProcessId()+PsGetProcessImageFileName()获取当前进程标识，确保每条分配记录都打上PID/进程名/调用栈三元标签
轻量级标记与实时聚合策略
内核中不能做耗时操作，钩子函数必须控制在百纳秒级。标记不存日志，而写入 per-CPU ring buffer，并由独立 worker thread 定期采样聚合。
- 分配时仅记录：
PID、Tag、Size、ReturnAddress（用RtlCaptureStackBackTrace截取 4 层）、Timestamp - 释放时匹配
Tag+PID+地址范围，命中则清除对应标记；未命中则进入“疑似泄漏桶” - 每 5 秒触发一次聚合：按
PID+Tag统计净增长量，对连续 3 次净增 >64KB 的组合，触发 full stack trace dump 到\SystemRoot\MemoryLeakSnap.bin
规避蓝屏与稳定性风险的关键实践
内核钩子一旦出错即导致系统崩溃。所有操作必须满足“原子、无锁、无内存分配、无分页I/O”四原则。
-
Inline Hook 实现必须用汇编重写：C 编译器生成的 prologue/epilogue 会破坏寄存器状态，尤其
rax/rcx/rdx/r8-r11是 Windows 内核 ABI 保留寄存器，钩子前后必须完全一致 -
禁止在钩子中调用任何非
NTOSKRNL导出的函数：例如不能用DbgPrint，改用KeBugCheckEx的替代方案——将信息编码进KeRaiseIrqlToDpcLevel后的固定内存区，由用户态服务轮询读取 -
动态开关能力不可少：通过
IoCreateDeviceIoControlSymbolicLink暴露 IOCTL 接口，允许管理员运行devcon disable "LeakMonitor"瞬间卸载钩子，避免重启
验证泄漏真实性的闭环手段
仅看分配/释放不匹配还不够——要确认对象是否真被遗忘，而非暂存于缓存或等待异步释放。
- 对高风险 Tag（如
'Proc','Thre','Eve '）启用引用图快照：调用ObReferenceObjectByHandle反查句柄表，确认该内存是否仍被进程对象、线程对象或事件对象强引用 - 结合
PsSetCreateProcessNotifyRoutineEx监听进程退出：若某 PID 在退出前仍有未释放的ExAllocatePoolWithTag记录，且无对应ExFreePoolWithTag，即可判定为进程级直接泄漏 - 输出结果不只告警，而是生成可导入 WinDbg 的
.kdmp片段：含泄漏块地址、分配栈、所属进程 EPROCESS 地址、以及!pool -v <addr>可解析的 pool header 副本
