Delphi 64位下ShellExecuteEx启动进程无法被EnumProcesses检测

• UAC权限隔离：若检测进程未以管理员权限运行，即便EnumProcesses能枚举到高权限进程的PID，调用OpenProcess时会因权限不足返回无效句柄，导致IsProcessRunning误判进程未运行。Windows UAC机制会隔离不同权限级别的进程，普通权限进程无法获取高权限进程的完整访问权限。
• TTTLauncher组件PID传递错误：自定义组件启动进程时，若未正确从PROCESS_INFORMATION结构体中提取真实的dwProcessId，检测函数使用错误PID自然无法匹配目标进程。
• 64位适配疏漏：原32位代码迁移到64位后，EnumProcesses调用的缓冲区大小计算、变量类型兼容（如PID存储的DWORD在64位下需确保枚举逻辑适配）可能存在问题，导致部分高权限进程PID未被枚举到。
• IsProcessRunning函数实现缺陷：若函数依赖PROCESS_ALL_ACCESS权限打开进程，在64位+UAC环境下，普通权限进程无法获取该权限，直接导致句柄获取失败；或函数未处理OpenProcess返回NULL的情况，错误判定进程未运行。

• 同步检测进程权限级别：将检测进程也以管理员权限启动，消除UAC权限隔离带来的限制，确保OpenProcess能正常获取高权限进程的句柄。
• 修正TTTLauncher的PID返回逻辑：检查组件中CreateProcess/CreateProcessAsUser等启动进程的代码，确保正确读取PROCESS_INFORMATION.dwProcessId并传递给上层调用，避免传递无效或错误的PID。
• 优化IsProcessRunning函数实现：
  • 将OpenProcess的权限参数改为PROCESS_QUERY_LIMITED_INFORMATION，该权限在Windows Vista及以上系统中，普通权限进程也可获取高权限进程的基本状态信息，足以判断进程是否存活。
  • 增加错误处理：若OpenProcess返回NULL，可通过EnumProcesses枚举所有PID，对比目标PID是否存在，避免仅通过句柄有效性判断。
• 完善64位枚举逻辑：确保EnumProcesses的缓冲区大小计算正确，例如先调用一次获取所需大小，再动态分配对应内存，避免因缓冲区不足导致PID枚举不全。
• 结合进程路径辅助验证：若PID检测不稳定，可通过QueryFullProcessImageName获取进程完整路径，进行二次验证，确保匹配的是目标进程而非同名其他进程。

内容的提问来源于stack exchange，提问作者Jan Doggen