服务里Process.Start一行代码，进程确实起来了，任务管理器里能看到，界面就是不出现——这个场景我前后碰过三次，最早那次排查了大半天，以为是路径或者权限问题，后来才发现根子在会话上。这次把"C# 写的 Windows 服务怎样把 UI 交互程序真正推到用户桌面上"这件事完整拆一遍：为什么直接启动行不通、几种路线的真实代价、核心 API 每一行在干什么、代码怎样落地编译、以及上线之后那些只会在客户现场冒出来的坑。如果你正在做守护型服务、自动更新器、开机自启的桌面前端、或者要给一套内部工具加"服务拉 UI"的能力，这篇基本能让你少绕两天弯路。文中所有代码都按可直接编译的标准写，参数含义和取舍理由我会讲清楚，方便你按自己的场景裁剪。

1. 先把问题讲透：Session 0 到底拦住了什么

1.1 一个"程序跑起来了，屏幕上却没有"的典型现场

最早的现场是这样的：一个自研的守护服务，用Process.Start拉起桌面前端，日志里一切正常，进程 ID 也拿到了，HasExited是 false，说明进程活得挺好。但用户在桌面上什么都看不到，远程进来看也没有，任务管理器里却明明白白列着那个进程。更邪门的是，把同样的 exe 手动双击，界面立刻弹出来。

这就是 Session 0 隔离最典型的表现。服务进程由服务控制管理器拉起，运行在 Session 0，这是一个专门给系统服务和驱动用的会话，从 Windows Vista 开始，它被设计成不与任何用户交互：没有可见桌面，没有窗口站，没有登录用户的环境变量，也没有用户配置的 DPI 和输入法。你把一个带窗体的程序扔进 Session 0，它照样能创建窗口，只是那个窗口画在一张谁也看不见的桌面上。程序没坏，服务没坏，代码没坏，是"开会的地方"错了。

理解这一点特别重要，因为它直接决定了后面所有方案的走向：你的目标不是"突破隔离"，而是"在正确的会话里、用正确的身份、创建这个进程"。Session 0 隔离本身是一道安全边界，它把系统级的高权限代码和用户的可交互代码隔开，防止一个被攻破的浏览器或者文档阅读器顺着窗口消息摸到系统服务。所以任何宣传"穿透"的做法，本质上都是在找一个合法的、系统认可的通道去别的会话里创建进程，而不是真的把墙拆了。这个认知一旦建立，你后面看各种方案就不会被"黑科技"式的说法带偏。

还有一个容易被忽略的点：隔离影响的不只是画面。Session 0 里的进程拿到的环境块和用户会话完全不同，%APPDATA%、%TEMP%、%USERPROFILE%这些变量要么缺失要么指向C:\Windows\System32\config\systemprofile。很多程序在启动瞬间就要读用户配置文件，环境不对会直接崩在初始化阶段，表现成"启动即退出"，日志里还什么都没有。所以你看到的现象可能是"看不见"，也可能是"闪退"，甚至是"看起来起来了但功能全废"，根因却是同一个。

1.2 隔离机制与三个流传很广的误解

第一个误解是"服务属性里勾上'允许服务与桌面交互'就行了"。这个选项确实存在过，那是 Windows XP 时代的做法，服务的窗口能直接出现在用户的桌面上。但从 Vista 起，这个勾选框虽然在某些界面里还留着，实际行为已经变了：勾了也不会让服务进程跑到用户会话里，改动只影响服务自己的窗口站权限，跟"在用户桌面弹窗"完全是两码事。网上有些老帖子还在教这个，照着做只会浪费一晚上。

第二个误解是"用管理员权限运行服务就能弹窗"。权限和会话是两个正交的维度。服务以 LocalSystem 运行，权限高到几乎可以为所欲为，但它在 Session 0；普通用户在 Session 1，权限低，但在正确的会话里。你要的是"用 Session 1 那个用户的身份，在 Session 1 创建进程"，跟服务本身权限高不高没有直接关系——当然，服务权限不够的话，它连"查询用户令牌"这一步都做不了，这是另一回事。

第三个误解是"用Process.Start加UseShellExecute = true就能借用资源管理器"。这个思路在某些场景下有点道理，因为 ShellExecute 会尝试交给外壳去处理，但服务进程没有外壳上下文，UseShellExecute在服务里要么失效，要么直接抛异常。而且就算能借用，执行的会话也还是服务自己的会话。指望靠一个属性开关跨会话，是不现实的。

把这三个误解排掉之后，问题的形状就清楚了：你需要一个手段，让服务在指定会话里，用该会话登录用户的主令牌，创建进程，并且给这个进程指定一个可交互的窗口站和桌面。四个要素缺一个，结果就是"进程在跑，人看不见"。

1.3 几条路线的横向对比

在动手写代码之前，先把可选路线摊开看，这一步能省掉大量返工。我把实际用过的四条路线放在一张表里对照：

把这四条摆在一起，你会发现它们不是互斥的，实际项目里我最后用的是"令牌法 + 用户态代理"的组合：服务第一次把代理拉起来用令牌法，代理起来之后常驻，后续所有 UI 拉起、特权操作请求都走管道。这样既解决了"用户还没登录时代理不存在"的冷启动问题，又把高频路径上的权限风险降到了最低。后面第 4 章会把这个组合完整写出来。

2. 方案选型：为什么我把 Process.Start 换成了 CreateProcessAsUser

2.1 Process.Start 失败的真实原因，不是权限而是会话

先把这个最容易被误判的点说透。Process.Start内部最终也会走到CreateProcess系列，它创建的子进程继承调用者的令牌和会话。服务的令牌是 LocalSystem（或者你配置的服务账户），会话是 Session 0，所以子进程自然也在 Session 0。你在代码里加Verb = "runas"、加WorkingDirectory、改成绝对路径，全都没有用，因为这些东西影响的不是会话归属。

有人会问，那我用Process.Start加上一个explorer.exe的参数行不行？不行，因为服务会话里没有 explorer 在跑，即使你把路径指过去，启动的也还是 Session 0 的 explorer 实例。要跨会话，就必须显式地走"令牌 + 会话"这条路，没有捷径。

顺带说一个诊断技巧：判断一个问题是不是会话导致的，最快的办法是查进程的 SessionId。任务管理器"详细信息"标签页里有"会话 ID"这一列，默认不显示，右键列头勾上就能看到。服务拉起来的进程显示 0，用户双击的显示 1 或更大，一眼就能定性。命令行下也可以用Get-Process -Name xxx | Select-Object Id, SessionId看一眼。养成这个习惯，能避免大量无效排查。

2.2 计划任务法：最省事，但有三个隐性成本

计划任务法是我给很多团队推荐的第一站，因为它不需要写任何 P/Invoke，注册一个登录触发任务，服务只需要负责"触发"这一下。核心命令大致是这样：

schtasks /Create /TN "MyAppUserAgent" /TR "\"C:\Program Files\MyApp\agent.exe\" --from-task" /SC ONLOGON /RL LIMITED /F

关键在/SC ONLOGON和/RL LIMITED。ONLOGON保证任务在用户登录后运行，天然就在用户会话里；LIMITED表示以普通权限运行，这一点非常关键，后面会解释为什么不能用最高权限。

但它有三个隐性成本，必须提前算进去。第一是注册时机：不带/RU的任务默认以系统身份创建，虽然登录触发，但执行身份可能不是你想要的；带/RU 用户名时通常还要配/RP 密码，在域环境里密码策略一改，任务就失效了。第二是首次登录前不可用，如果用户还没登录，任务根本不会跑，这时候服务想推界面依然没辙。第三是任务本身游离在应用之外，运维排查时要多查一个地方，出问题时"服务日志说触发了，任务计划程序说没执行"这种扯皮很常见。

我后来把这套方案定位成"兜底"，也就是代理程序本身用计划任务保证每次登录都能起来，但"服务要拉起界面"这个动作不走计划任务，走管道通知代理。这样两边的优点都拿到了。

2.3 我的决策路径

把这些经验压缩成一张判断表，实际选型时直接照着走：

这里有一条我必须强调的原则：不要试图让 UI 进程带着管理员权限跑起来。服务是 LocalSystem，理论上能拉起一个高完整性级别的进程，但在开启了 UAC 的系统上，这样做要么被系统拦下，要么把整个安全模型搞出一个大口子。正确的做法是把权限拆开——需要高权限的动作（写系统目录、改注册表关键项、装驱动）留在服务里，通过命名管道接收请求；UI 进程用普通用户令牌启动，只做界面和交互。这个拆分看起来多写了一些代码，但它同时解决了"弹不出来"和"弹出来就是提权木马"两个问题。

2.4 还有一个绕不开的前置问题：服务账户

令牌法要求服务以 LocalSystem 运行，原因很简单：WTSQueryUserToken需要SeTcbPrivilege（作为操作系统一部分运行的权限），而这个特权实际上只有 LocalSystem 持有。你如果把服务配成 NetworkService 或者某个普通域账户，这一步会直接返回"拒绝访问"。

所以在项目初期就要把服务账户定下来，不要等到联调时才发现。安装服务时用sc create或者New-Service指定账户，默认就是 LocalSystem：

New-Service -Name "MyAppDaemon" ` -BinaryPathName '"C:\Program Files\MyApp\daemon.exe"' ` -DisplayName "MyApp 守护服务" ` -StartupType Automatic

需要说明的是，LocalSystem 权限很高，这也意味着你的服务代码本身必须经得起审视：任何来自管道、文件、注册表的输入都要当作不可信数据处理。这一点在只做启动器的场景里风险不大，但只要服务开始接收指令，就必须认真对待。

3. 核心 API 拆解：Token 拿对了，问题就解决八成

3.1 找会话：WTSGetActiveConsoleSessionId 不够用的时候

最直觉的做法是调WTSGetActiveConsoleSessionId()，它返回当前物理控制台的会话 ID。在"一台机器一个本地登录用户"的场景下，这个值就是你要的，代码短得让人心情愉快。但它有两个失效场景必须知道。

第一个是返回0xFFFFFFFF。在较新的服务器系统上，如果没有用户通过控制台登录，这个函数就返回这个哨兵值，你拿它去WTSQueryUserToken会直接失败。第二个更常见：用户是远程登录的，物理控制台上根本没人。这时候函数返回的可能是控制台会话 ID（值为 1 但没人登录），也可能是哨兵值，取决于系统版本和连接状态。你要是只用这一个函数，远程办公的用户就会遇到"界面永远不出来"。

稳的做法是枚举会话，按状态和用户名筛：

[DllImport("wtsapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)] static extern bool WTSEnumerateSessions(IntPtr hServer, int reserved, int version, out IntPtr ppSessionInfo, out int pCount); [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)] struct WTS_SESSION_INFO { public int SessionId; public string pWinStationName; public int State; // 0=Active 1=Connected 2=ConnectQuery 3=Shadow 4=Disconnected 5=Idle 6=Listen 7=Reset 8=Down }

枚举出来之后，优先选State == 0（Active）的会话；如果有多个活跃会话（多用户同时登录），再按配置的用户名或"最近活跃时间"去匹配。我一般会在配置里给一个"目标用户"字段，留空则取第一个活跃会话，填了就精确匹配。这个设计在多用户服务器上非常必要，否则界面可能弹到别人的屏幕上，那就不只是技术问题了。

还有一个细节：用户锁屏时，会话状态仍然是 Active，令牌也拿得到，进程能启动，但界面要等解锁才看得见。这是正常行为，不是 bug，测试的时候别当成故障去查。

3.2 WTSQueryUserToken 的前置条件

这个函数的签名很简单：

[DllImport("wtsapi32.dll", SetLastError = true)] static extern bool WTSQueryUserToken(uint sessionId, out IntPtr phToken);

它做的事件是"给我这个会话里已登录用户的主令牌"。前置条件有三个，缺一不可：调用者必须是 LocalSystem（前面说过）；指定会话里必须已经有一个交互登录的用户，否则返回 1008（ERROR_NO_TOKEN）；调用线程不能处于模拟状态，如果你在服务里用了WindowsIdentity.Impersonate又没还原，这里也会失败。

拿到的令牌用完之后必须CloseHandle，这是很常见的泄漏点。服务是长期运行的，一天触发几十次，句柄泄漏积累下来会导致进程句柄数飙升，最后启动失败，而且错误信息毫无提示性。养成"谁拿谁放"的习惯，用 try/finally 包住。

3.3 DuplicateTokenEx 与提权标志位

WTSQueryUserToken返回的是一个模拟令牌（impersonation token），而CreateProcessAsUser需要主令牌（primary token）。这一步转换靠DuplicateTokenEx：

[DllImport("advapi32.dll", SetLastError = true)] static extern bool DuplicateTokenEx( IntPtr hExistingToken, uint dwDesiredAccess, IntPtr lpTokenAttributes, int ImpersonationLevel, // SecurityImpersonation = 2 int TokenType, // TokenPrimary = 1 out IntPtr phNewToken);

dwDesiredAccess我一般传0x02000000（MAXIMUM_ALLOWED），让系统自己算需要的权限位。有人喜欢传TOKEN_ALL_ACCESS，也能工作，但更容易在受限环境下失败。转换完之后，原来那个令牌就可以关掉了。

接下来是CreateProcessAsUser，这个函数有一组"调用者必须具备的特权"，文档里写得很清楚：需要SeAssignPrimaryTokenPrivilege和SeIncreaseQuotaPrivilege。LocalSystem 持有这两个特权，但可能是禁用状态，不显式启用就会返回 1314（ERROR_PRIVILEGE_NOT_HELD）。启用代码不长，但一定要加：

static void EnablePrivilege(string name) { if (!OpenProcessToken(GetCurrentProcess(), 0x0020 | 0x0008, out var hToken)) // ADJUST_PRIVILEGES|QUERY throw new Win32Exception(Marshal.GetLastWin32Error()); try { if (!LookupPrivilegeValue(null, name, out var luid)) throw new Win32Exception(Marshal.GetLastWin32Error()); var tp = new TOKEN_PRIVILEGES { PrivilegeCount = 1, Luid = luid, Attributes = 0x00000002 // SE_PRIVILEGE_ENABLED }; AdjustTokenPrivileges(hToken, false, ref tp, 0, IntPtr.Zero, IntPtr.Zero); // AdjustTokenPrivileges 即使部分失败也返回 true，必须查最后一次错误 var err = Marshal.GetLastWin32Error(); if (err != 0) throw new Win32Exception(err, $"启用特权失败: {name}"); } finally { CloseHandle(hToken); } }

这里有个坑值得单独说：AdjustTokenPrivileges的返回值在"部分成功"时仍然是 true，必须紧接着查GetLastWin32Error才能知道特权到底有没有启用。我第一次写的时候漏了这一步，结果 1314 一直出现，排查方向完全跑偏。

如果因为某些原因服务不是 LocalSystem，CreateProcessAsUser走不通，还有一条备选路线是CreateProcessWithTokenW。它只要求SeImpersonatePrivilege，LocalSystem、NetworkService 和管理员账户都有，但要经过一次身份代理，行为和直接创建略有差异。我的做法是主路径用CreateProcessAsUser，失败后回落CreateProcessWithTokenW，两条路都记日志，现场排查时能直接看出走的是哪条。

3.4 环境块、桌面名与工作目录

这三个东西决定了"进程能起来"和"进程起来了但立刻崩"之间的差别，很多人代码写对了却还是失败，问题往往在这里。

环境块靠CreateEnvironmentBlock从令牌里重建：

[DllImport("userenv.dll", SetLastError = true)] static extern bool CreateEnvironmentBlock(out IntPtr lpEnvironment, IntPtr hToken, bool bInherit);

不传环境块、把lpEnvironment置为IntPtr.Zero，子进程拿到的就是服务自己的环境，%APPDATA%指向 systemprofile，很多程序在读用户配置时直接抛异常。传了环境块还必须配套CREATE_UNICODE_ENVIRONMENT标志位，否则路径里的非 ASCII 字符会乱码，这个现象在国内环境下特别常见，表现为"用户名是中文的机器上程序起不来"。

桌面名必须显式指定：

si.lpDesktop = @"winsta0\default";

winsta0是交互式窗口站，default是登录用户看到的默认桌面。写成空字符串或者别的桌面，窗口就画在别处了——常见的情况是进程活着，但界面藏在某个不可见的桌面上。如果程序是在锁屏界面运行的（比如某些登录辅助场景），那个桌面是winsta0\winlogon，完全是另一回事，本文不考虑。

工作目录要显式给，不要依赖服务的当前目录。服务的默认工作目录通常是C:\Windows\System32，程序如果按相对路径找配置文件或者资源，会全部找不到。启动参数里的路径记得加引号，路径含空格时lpApplicationName和lpCommandLine的处理方式不同，稳妥做法是lpApplicationName传完整路径、lpCommandLine里把路径用双引号包起来。

4. 完整实操：把服务改成能在用户桌面上启动程序

4.1 工程结构与服务宿主

工程我一般拆成三个项目：Daemon（服务主体）、Agent（用户态代理、带界面）、Shared（协议和常量的共享库）。只做启动器的话可以合成一个 exe，用命令行参数区分角色，部署时省事。

服务的宿主部分有几个硬性要求。OnStart里不能长时间阻塞，服务控制管理器只给 30 秒，超时就会报 1053 并把服务标成启动失败。我的做法是OnStart里只做参数校验和定时器初始化，真正的拉起动作放到后台任务里：

public partial class DaemonService : ServiceBase { private CancellationTokenSource _cts; public DaemonService() { ServiceName = "MyAppDaemon"; } protected override void OnStart(string[] args) { _cts = new CancellationTokenSource(); Task.Run(async () => { try { await Task.Delay(2000, _cts.Token); // 给网络和用户环境一点时间 await SessionLauncher.EnsureAgentAsync(_cts.Token); await PipeServer.RunAsync(_cts.Token); } catch (OperationCanceledException) { } catch (Exception ex) { EventLogger.Error("后台启动失败", ex); // 千万别让异常逃逸出去 } }, _cts.Token); } protected override void OnStop() { _cts?.Cancel(); } }

延迟两秒不是偷懒。机器刚开机时用户会话还没完全就绪，太早调WTSQueryUserToken会拿到 1008。很多"开机自启不生效"的案例，根因就是这个时序。两秒是个经验值，需要更稳的话可以改成轮询：每 500 毫秒试一次，最多试 30 秒，成功就退出循环。

4.2 启动器核心代码

下面是核心方法，去掉日志之后大约四十行，可以直接抄：

public static bool LaunchInSession(string exePath, string arguments, uint sessionId, out int pid) { pid = 0; IntPtr hUser = IntPtr.Zero, hPrimary = IntPtr.Zero, hEnv = IntPtr.Zero; try { if (!WTSQueryUserToken(sessionId, out hUser)) throw new Win32Exception(Marshal.GetLastWin32Error(), $"WTSQueryUserToken 失败，会话 {sessionId}"); if (!DuplicateTokenEx(hUser, 0x02000000, IntPtr.Zero, SECURITY_IMPERSONATION_LEVEL.SecurityImpersonation, TOKEN_TYPE.TokenPrimary, out hPrimary)) throw new Win32Exception(Marshal.GetLastWin32Error(), "DuplicateTokenEx 失败"); if (!CreateEnvironmentBlock(out hEnv, hPrimary, false)) throw new Win32Exception(Marshal.GetLastWin32Error(), "CreateEnvironmentBlock 失败"); var si = new STARTUPINFO { cb = Marshal.SizeOf(typeof(STARTUPINFO)), lpDesktop = @"winsta0\default", dwFlags = 0x00000001, // STARTF_USESHOWWINDOW wShowWindow = 1 // SW_SHOWNORMAL }; const uint flags = 0x00000400 | 0x00000010; // UNICODE_ENVIRONMENT | NEW_CONSOLE bool ok = CreateProcessAsUser(hPrimary, exePath, $"\"{exePath}\" {arguments}", IntPtr.Zero, IntPtr.Zero, false, flags, hEnv, Path.GetDirectoryName(exePath), ref si, out var pi); if (!ok) throw new Win32Exception(Marshal.GetLastWin32Error(), "CreateProcessAsUser 失败"); pid = pi.dwProcessId; CloseHandle(pi.hThread); CloseHandle(pi.hProcess); return true; } finally { if (hEnv != IntPtr.Zero) DestroyEnvironmentBlock(hEnv); if (hPrimary != IntPtr.Zero) CloseHandle(hPrimary); if (hUser != IntPtr.Zero) CloseHandle(hUser); } }

会话选择的辅助方法：

public static uint PickSession(string preferredUser) { if (!WTSEnumerateSessions(IntPtr.Zero, 0, 1, out var buf, out var count)) throw new Win32Exception(Marshal.GetLastWin32Error()); try { int size = Marshal.SizeOf(typeof(WTS_SESSION_INFO)); uint fallback = uint.MaxValue; for (int i = 0; i < count; i++) { var info = Marshal.PtrToStructure<WTS_SESSION_INFO>(buf + i * size); if (info.State != 0) continue; // 只要 Active if (string.IsNullOrEmpty(preferredUser)) return (uint)info.SessionId; var user = QuerySessionUser(info.SessionId); // 内部再调 WTSQuerySessionInformation if (string.Equals(user, preferredUser, StringComparison.OrdinalIgnoreCase)) return (uint)info.SessionId; if (fallback == uint.MaxValue) fallback = (uint)info.SessionId; } return fallback; } finally { WTSFreeMemory(buf); } }

WTSQuerySessionInformation返回的字符串必须用WTSFreeMemory释放，注意不是CloseHandle，也不是Marshal.FreeHGlobal。混用释放函数会导致堆损坏，症状是偶发的崩溃，极难定位，我在这上面吃过一次大亏。

4.3 安装与权限配置

安装脚本里有两个点要留意。一是服务账户，默认 LocalSystem；二是服务失败后的恢复动作，给个自动重启比较稳：

sc create MyAppDaemon binPath= "\"C:\Program Files\MyApp\daemon.exe\"" start= auto obj= "LocalSystem" sc failure MyAppDaemon reset= 86400 actions= restart/5000/restart/10000/restart/30000 sc description MyAppDaemon "负责会话拉起与特权操作的守护服务"

代理程序的目录权限也要看一眼。如果代理放在Program Files下，普通用户只有读和执行权限，这是好事；如果放在用户可写的目录里，那它就可能被替换，服务通过管道调用它时就存在被利用的风险。稳妥做法是代理放在受保护目录，用管道的 ACL 再限制一层，只允许特定用户组连接。

4.4 加一层命名管道：更稳的架构

只靠令牌法也能跑，但跑一段时间你会发现两个问题：会话切换（用户注销再登录）之后，之前拉起的代理失效了，服务不知道；每次要弹界面都得重新走一遍令牌流程，失败率反而更高。这时候加一个常驻代理就很有价值。

代理的职责很简单：开机被计划任务拉起，连上服务端的管道，然后一直挂着等指令。服务要弹界面时，往管道里写一条消息，代理在自己的会话里Process.Start把主程序拉起来——这一步天然正确，因为它本来就在用户会话里，不需要任何令牌技巧。

管道服务端的关键是 ACL 和身份校验：

var security = new PipeSecurity(); security.AddAccessRule(new PipeAccessRule( new SecurityIdentifier(WellKnownSidType.AuthenticatedUserSid, null), PipeAccessRights.ReadWrite, AccessControlType.Allow)); using var server = new NamedPipeServerStream("myapp_agent", PipeDirection.InOut, 1, PipeTransmissionMode.Byte, PipeOptions.Asynchronous, 4096, 4096, security); await server.WaitForConnectionAsync(ct);

服务端拿到连接之后，一定要做身份校验，别只看"连上了没有"。可用的校验维度有三个：调用方的会话 ID（GetNamedPipeClientSessionId）、调用方的进程路径、以及调用方进程的可执行文件签名。前两个足够挡住绝大多数误用，第三个在安全要求高的场景再加。校验不通过就断开，不要给任何提示性的返回，避免成为探测工具。

消息格式我用最朴素的行文本协议，一行一条 JSON，长度前缀都省了，因为消息体很小。协议设计上有一个原则：服务只接受"动作枚举"，不接受任意命令行。代理收到{"action":"show_main"}就去拉配置里写死的主程序路径，收到{"action":"open_logs"}就打开日志目录。如果协议里允许传路径，服务就变成了一个"任意程序启动器"，一旦管道被滥用，后果不可控。这个约束看起来限制灵活性，但它是一条必须守住的红线。

5. 踩坑实录：错误码、排查顺序与自检清单

5.1 错误码速查表

现场排查时，错误码是最快的线索。这张表是我这些年攒下来的，基本覆盖了这条路线上会遇到的情况：

特别说一下 740。这个错误的意思是"你启动的这个程序要求管理员权限"，而我们的令牌是普通用户的，系统会拦下来。这不是我们的代码有问题，是设计冲突。解决办法只有一个：把程序清单里的requestedExecutionLevel改成asInvoker，需要管理员权限的操作抽到服务里执行。试图用服务的 LocalSystem 令牌去"绕过"这个限制，既不安全也不符合规范，早晚出问题。

5.2 界面不出来的四种形态

同样是"看不见界面"，背后的原因完全不同，分开对待能省很多时间。

第一种，进程在但会话是 0。这基本等于令牌流程没走通，或者代码里还在用Process.Start。查进程的 SessionId 就能确认。

第二种，进程在、会话对、但窗口不显示。多半是lpDesktop写错了，或者程序自己判断"当前非交互环境"主动隐藏了窗口。有些框架会检查Environment.UserInteractive，服务里这个值是 false，程序据此走了无界面分支。这种情况要改程序逻辑，不能怪启动方式。

第三种，进程起来几秒就退了。九成是环境块的问题，或者工作目录不对，导致程序在初始化阶段找不到配置。用CreateEnvironmentBlock并配CREATE_UNICODE_ENVIRONMENT能解决大部分。

第四种，进程压根没起来，CreateProcessAsUser返回 false。看错误码，1314 查特权，2 查路径，740 查清单，5 查账户。

5.3 怎么调试一个看不见的服务

服务最麻烦的地方是它没有控制台，出错了你连堆栈都看不到。我的做法是三条腿走路。

第一条是事件日志。服务里所有关键节点都写一条，包括"开始查找会话""找到会话 X""令牌获取成功""进程已创建，PID=Y"。用自定义日志源，别往 Application 里乱塞：

if (!EventLog.SourceExists("MyAppDaemon")) EventLog.CreateEventSource("MyAppDaemon", "Application"); EventLog.WriteEntry("MyAppDaemon", msg, EventLogEntryType.Information);

注意CreateEventSource需要管理员权限，第一次要在安装阶段做，不能放在服务运行时做。

第二条是文件日志。用滚动文件记录详细信息，包括每次的错误码和当时的会话列表快照。现场的机器你没法远程调试，日志是唯一的证据。我一般会在启动失败时把当前所有会话的 ID、状态、用户名都打进去，很多问题看一眼日志就明白了。

第三条是把服务逻辑抽成一个可以控制台运行的模式。加个--console参数，直接dotnet run或者双击运行，断点随便打。这一条能省掉 80% 的调试痛苦，强烈建议一开始就做。同一个类，服务宿主和控制台宿主各包一层，业务代码完全复用。

5.4 上线前自检清单

每次交付前我会过一遍这几项，基本能拦住大部分现场问题：

• 服务账户确认是 LocalSystem，sc qc看一眼
• OnStart里没有超过 1 秒的同步阻塞
• 所有WTSQueryUserToken的返回值都有CloseHandle配对
• 管道连接做了会话和进程校验，ACL 不是Everyone
• 目标程序的清单是asInvoker，没有requireAdministrator
• 路径全部是绝对路径，且带引号
• 中文用户名、中文安装路径的机器上实测过一遍
• 用户注销再登录之后，代理能自动重连
• 多用户同时登录时，界面投递到正确的人
• 事件日志源在安装阶段创建好，服务运行时不需要管理员权限

最后两项是最容易漏的，也最容易在客户现场炸。

我个人在这套东西上折腾了挺久，最大的体会是：这类问题的难点从来不在 API 本身，CreateProcessAsUser的签名抄一遍就会，真正耗时间的是那些"看起来一样、其实完全不是一回事"的现象——进程在但看不见、看得见但立刻退出、能弹窗但弹到别人屏幕上。把每种现象背后的机制捋清楚，再配上足够细的日志，排查就从"猜"变成了"查"。另外别急着上复杂方案，先用二十行令牌法验证一下能不能弹出来，跑通了再考虑代理和管道，架构是一步步长出来的，不是一开始就设计完的。