GetProcessHandleCount仅返回总数，无法定位泄漏源；需用Process Explorer查类型与堆栈、Application Verifier+gflags捕获分配点，或自研ScopedHandle记录生命周期。
Windows平台下用GetProcessHandleCount只能看总数，没法定位泄漏源
这个函数返回的是当前进程打开的句柄数量，但不区分类型（文件、事件、互斥体、窗口等），也不提供句柄归属对象或创建栈信息。单纯靠它无法判断哪个模块、哪段代码在反复CreateFile却没调CloseHandle。
真正要定位泄漏，得依赖工具链配合调试符号，而不是仅靠API。
用Process Explorer实时查看句柄类型和堆栈（需开启符号）
这是最直接有效的现场排查方式。启动Process Explorer，右键目标进程 → “Properties” → “Handles”页签，可看到所有句柄的类型、名称（如\Device\HarddiskVolume2\foo.txt）、引用计数。
- 按
Ctrl+D可启用“Lower pane shows stack traces”，前提是已配置符号路径（_NT_SYMBOL_PATH或通过Options → Configure Symbols设置） - 若某类句柄（如
Event、Section）持续增长，右键→“Stack Trace”能定位到CreateEvent或CreateFileMapping的调用位置 - 注意：Release版二进制需带PDB，且不能Strip掉函数名；否则堆栈里只显示
ntdll!NtCreateEvent，看不到你自己的代码行
用Application Verifier + gflags捕获句柄分配点
这是微软官方推荐的检测手段，能在句柄创建时自动记录调用栈，适合复现周期长、泄漏慢的场景。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 运行
gflags.exe /i yourapp.exe +ust启用用户模式堆栈跟踪 - 在
Application Verifier中勾选目标进程，启用“Handles”选项（不是“Heap”） - 重启程序，泄漏发生后，在WinDbg中执行
!htrace -enable，再用!htrace -diff对比前后句柄差异，输出会包含完整调用链 - 常见陷阱：
gflags配置对子进程无效，如果程序CreateProcess启动了子进程，需单独为子进程配置
C++代码里主动记录句柄生命周期（适用于自研模块）
无法依赖外部工具时，可在关键资源封装层加轻量级日志。比如写一个ScopedHandle包装器：
class ScopedHandle {
HANDLE h_;
const char* site_; // __FILE__ ":" STRINGIFY(__LINE__)
public:
ScopedHandle(HANDLE h, const char* site) : h_(h), site_(site) {
if (h == INVALID_HANDLE_VALUE) log("INVALID at %s", site_);
}
~ScopedHandle() {
if (h_ != nullptr && h_ != INVALID_HANDLE_VALUE) {
CloseHandle(h_); // 这里可加log
}
}
// ... move ctor, release(), etc.
};这样能把每个CreateFile、CreateMutex的来源打点。但要注意： DuplicateHandle会增加引用计数，不能只靠构造/析构计数——必须配合GetHandleInformation查HANDLE_FLAG_INHERIT和实际引用数。
真正的难点不在获取句柄本身，而在于区分“合法长期持有”和“意外未释放”。比如一个全局EVENT被多个线程等待，它一直存在是正常的；但若每次网络连接都新建一个没关的SOCKET句柄，就属于泄漏。判断依据永远是业务逻辑，不是数字大小。
