Windows下CreateProcessAsUser调用失败但无错误码的问题排查

首先，这个问题的核心矛盾点很明确：当程序manifest设置了非asInvoker的权限级别时，SYSTEM服务通过CreateProcessAsUser启动失败，但直接运行完全正常，且错误码返回0。结合Windows 10的UAC机制和服务会话隔离特性，我来拆解可能的原因和排查方向：

1. 为什么GetLastError会返回0？ #

这是个容易迷惑人的点——当你尝试启动需要UAC提升的程序（requireAdministrator或highestAvailable）时，Windows并不会直接通过CreateProcessAsUser返回常规错误。实际上，系统会尝试触发UAC提升流程，但因为你的服务运行在会话0（Windows服务的默认隔离会话），而用户的交互式桌面在会话1或更高，UAC的提升弹窗无法在会话0显示，导致进程创建流程无声失败。这种情况下，CreateProcessAsUser本身的API调用没有触发常规错误，但实际的进程创建逻辑在UAC子流程中失败了，所以返回FALSE但GetLastError()为0。

2. 会话隔离是核心障碍 #

SYSTEM服务运行在会话0，而普通用户的交互式会话是会话1+，两者完全隔离。当程序需要UAC提升时，系统需要在用户的交互式会话中创建提升后的进程，但你的CreateProcessAsUser调用可能没有正确配置跨会话的参数：

• 检查STARTUPINFO的lpDesktop字段：如果没有指定用户的桌面（比如"WinSta0\\Default"），进程会尝试在会话0的桌面启动，而会话0没有交互式桌面环境，无法完成UAC提升。
• 确保你获取的用户令牌是来自用户的交互式会话：如果你的服务是通过WTSQueryUserToken获取的令牌，要确认传入的会话ID是用户当前的交互式会话ID（可以用WTSEnumerateSessions枚举会话找到活动会话）。

3. 用户令牌的权限和完整性问题 #

CreateProcessAsUser本身需要服务拥有特定权限，同时令牌的完整性级别也会影响启动：

• 检查服务是否启用了必要权限：比如SeAssignPrimaryTokenPrivilege、SeIncreaseQuotaPrivilege、SeCreateTokenPrivilege，这些是CreateProcessAsUser成功运行的前提。你需要在服务启动时调用AdjustTokenPrivileges启用这些权限。
• 令牌的完整性级别：如果用户是管理员，系统会生成两个令牌——受限令牌（默认使用）和完整管理员令牌。如果你的服务使用的是受限令牌，即使程序设置了highestAvailable，也无法启动提升后的进程，而直接运行时系统会自动触发UAC提升切换到完整令牌。

4. 启动标志的潜在冲突 #

你设置的creationFlags里有几个需要注意的点：

• DETACHED_PROCESS：这个标志会让新进程没有控制台窗口，但结合UAC提升流程，可能导致进程无法正确关联到用户的交互式环境，进而失败。
• CREATE_NEW_PROCESS_GROUP：创建新的进程组本身没问题，但如果UAC提升后的进程需要和父进程（服务）有某种关联，这个标志可能会干扰流程。可以尝试暂时移除这些标志，看是否能正常启动，再逐步排查。

5. 可行的解决方向 #

• 调整会话和桌面配置：确保STARTUPINFO的lpDesktop设置为用户的交互式桌面（"WinSta0\\Default"），并且使用用户会话的正确令牌（通过WTSQueryUserToken获取活动会话的令牌）。
• 改用ShellExecuteEx：如果你的场景允许，ShellExecuteEx比CreateProcessAsUser更适合处理需要UAC提升的交互式程序启动，它会自动处理会话切换和UAC弹窗的显示（只要用户在交互式会话中）。
• 检查系统事件日志：打开事件查看器，查看“Windows日志-系统”或“应用程序和服务日志-Microsoft-Windows-UAC/Operational”下的日志，里面可能有UAC提升失败的详细原因，这比GetLastError()更可靠。
• 调试进程创建流程：用Process Monitor跟踪服务的CreateProcessAsUser调用，查看进程创建过程中哪些步骤失败，比如是否有访问被拒绝的资源，或者令牌权限不足的情况。

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