getfileinformationbyhandle无法获取进程名，仅返回文件元数据；查占用进程需用handle.exe（管理员权限运行）、ntquerysysteminformation枚举句柄或toolhelp32snapshot+ntqueryobject组合，且必须启用sedebugprivilege权限。
Windows下用 GetFileInformationByHandle 无法直接获取进程名
这个函数只能拿到文件句柄对应的 BY_HANDLE_FILE_INFORMATION，里面根本没有进程信息。很多人误以为它能查谁在用文件，其实它只管文件本身（如索引号、创建时间等），和占用进程完全无关。
真正要查“哪个进程正打开着某个文件”，必须走系统级枚举路径：遍历所有进程 → 对每个进程遍历其打开的句柄 → 检查句柄是否指向目标文件。
关键依赖是：NtQuerySystemInformation（未公开API，需ntdll.dll）或更稳妥的 Toolhelp32Snapshot + NTQueryObject 组合。但注意：NTQueryObject 在低权限进程里大概率失败，且 Win10/11 默认禁用句柄继承查询，需管理员权限。
用 handle.exe 命令行工具快速验证是否可行
这是 Sysinternals 提供的成熟方案，不写代码也能定位问题。运行前必须以管理员身份启动命令行：
handle.exe -a "C:\path\to\your\file.txt"
输出类似：
notepad.exe pid: 1234 1A4: File (D:\test.txt)
说明 notepad.exe（PID 1234）正持有该文件句柄。这是调试阶段最可靠的基准——如果 handle.exe 都查不到，自己写的代码也几乎不可能查到，大概率是文件没被独占打开（比如只是读取后已关闭），或权限不足。
常见误区：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
handle.exe查不到 ≠ 文件空闲，可能是打开方式为FILE_SHARE_DELETE且无锁，系统不视为“占用” - 某些杀毒软件或 OneDrive 会以低可见性方式持有句柄，
handle.exe -u可尝试查用户模式句柄 - 符号链接或硬链接会导致路径匹配失败，得用
GetFinalPathNameByHandle先标准化路径
C++ 实现核心逻辑：用 EnumProcesses + NtDuplicateObject 枚举句柄
纯 WinAPI 方案需要三步联动：先枚举所有进程 PID，再对每个 PID 打开进程句柄（OpenProcess(PROCESS_DUP_HANDLE)），最后用 NtDuplicateObject 复制并查询每个句柄的目标对象类型与名称。
关键细节：
- 必须启用
SeDebugPrivilege权限，否则OpenProcess对大多数进程返回ERROR_ACCESS_DENIED -
NtDuplicateObject的TargetHandle参数设为NULL，配合DUPLICATE_SAME_ACCESS，才能绕过访问掩码检查 - 文件句柄的类型标识是
FILE或SECTION，但名称不一定可读——只有通过ObQueryNameString（需内核驱动支持）或GetFinalPathNameByHandle才能得到路径 - 64位系统上，
PROCESS_INFORMATION结构体大小和指针宽度需严格匹配，否则NtQueryObject返回STATUS_INVALID_HANDLE
简化的伪代码逻辑：
HANDLE hProcess = OpenProcess(PROCESS_DUP_HANDLE | PROCESS_QUERY_INFORMATION, FALSE, dwPID);
if (hProcess) {
HANDLE hDup;
if (NtDuplicateObject(hProcess, hSrcHandle, GetCurrentProcess(), &hDup, 0, 0, DUPLICATE_SAME_ACCESS) == STATUS_SUCCESS) {
WCHAR szPath[MAX_PATH];
if (GetFinalPathNameByHandle(hDup, szPath, MAX_PATH, FILE_NAME_NORMALIZED) > 0) {
// 比较 szPath 和目标路径
}
CloseHandle(hDup);
}
CloseHandle(hProcess);
}
为什么多数开源库（如 boost::filesystem）不提供此功能
这不是设计疏漏，而是 Windows API 层面就拒绝暴露这类信息给普通应用。操作系统刻意将“句柄归属”视为敏感信息，防止恶意程序探测其他进程行为。所以 Boost、Qt 等跨平台库干脆不封装——它们无法在 Linux/macOS 上实现等效功能（/proc/*/fd/ 是 Linux 特有），也不愿在 Windows 上强推高权限、易失败的私有 API 调用。
真正稳定的替代思路是：
- 若你控制文件打开方，让其主动注册 PID 到共享内存或命名管道
- 用
CreateFile时加FILE_SHARE_DELETE并捕获ERROR_SHARING_VIOLATION，反向推断“可能被占用”，但无法知道是谁 - 依赖 WMI 查询
Win32_Process+Win32_Handle关联，性能差且常因 UAC 或服务权限被截断
实际项目中，90% 的“获取占用进程名”需求，本质是想删除/替换文件。这时候更务实的做法是：改用 MoveFileEx 配合 MOVEFILE_DELAY_UNTIL_REBOOT，把清理交给系统重启阶段，避开所有句柄争抢。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
