Windows后台服务跨会话打开文件：Session 0隔离与令牌复制实践

服务里调用ShellExecute返回 TRUE，日志干干净净，用户屏幕上却什么都没有——这个现象我前后撞上过三次，最早那次还怀疑是资源管理器抽风，重装系统都没解决。问题从来不在"打开文件"这行代码上，而在于 Windows 后台服务脚下根本没有一块能被用户看见的桌面。标题里这串关键词拆开看是三件事：后台服务（LocalSystem 权限、Session 0）、启动 UI 程序（跨会话创建进程）、以默认打开文件的方式打开文件（走 Shell 关联而不是硬编码某个 exe）。三件事叠在一起，坑就密集起来了。这篇东西写给正在做设备接入、打印守护、桌面代理、自动化巡检这类需要"服务端触发、用户端表现"的同行，无论你用的是 C++、C# 还是 Go，底层逻辑是同一套。下面按我实际的落地顺序讲：先讲清楚为什么打不开，再讲怎么借到一只能上桌面的令牌，最后讲怎么把"打开文件"这件事做稳。中间会附上可直接抄的代码和一堆真实返回码。

1. 服务里打不开文件，问题不在代码而在会话

1.1 Session 0 隔离：服务脚下根本没有"屏幕"

从 Vista 开始，Windows 把服务统一放进 Session 0，而用户登录后拿到的是 Session 1 及之后的会话。这是一次彻底的安全重构：早期 XP 时代服务可以直接往用户桌面上弹窗、画界面，代价是任何登录用户都能通过窗口消息给 SYSTEM 服务发消息，提权路径多得像筛子。隔离之后，Session 0 有自己的窗口站（Service-0x0-3e7$）和桌面（Default），这个桌面从来不显示在物理显示器上，也没有explorer.exe在跑。

理解这一点，很多怪现象就顺了。你在服务里ShellExecute(NULL, L"open", path, ...)，它确实可能返回一个"看起来成功"的结果，因为它是在 Session 0 的窗口站里尝试激活 shell，那里没有 Shell 桌面对象，也没有文件关联对应的 COM 激活器，结果要么静默失败，要么启动了进程但没有任何可见输出。同理，Process.Start("C:\\a.pdf")用UseShellExecute = true在服务里跑，行为也是不可预期的。

注意：网上还能搜到"服务属性 → 登录 → 允许服务与桌面交互"这个勾选项，那是 XP 时代的遗产，在 Vista 之后的系统上勾了也没用，别在这上面浪费时间。

真正要做的不是"让服务显示界面"，而是"让用户会话里的某个进程去显示界面"。这个思维转换是整件事的分水岭。服务在这里扮演的角色是触发者，不是执行者。它只负责判断"该打开了"、找到"该由谁打开"、然后把请求投递过去。执行者必须是用户会话里以用户身份运行的进程。想明白这层，后面所有 API 的选择都只是在回答"怎么把请求投递得足够干净"。

1.2 三种跨会话打开文件的路线及其取舍

把请求从 Session 0 投递到用户会话，业界主流有三条路，我按自己用过的顺序做个对照。

第一次做这个需求时我用的是计划任务，图省事，schtasks /create /tn xxx /tr "cmd /c start ..." /sc once /st ...然后立即/run。能用，但踩了两个坑：一是任务创建和执行之间有肉眼可见的延迟，用户点了按钮要愣一下才弹窗；二是任务记录会在系统里堆积，运维同事看到一堆莫名任务会来问。后来换成令牌复制，代码虽长但一次写完之后极其稳定，就一直用下来了。常驻代理方案我只在需要"打开后等用户关闭再继续下一步"的场景用过，因为它能拿到SHELLEXECUTEINFO.hProcess，可以WaitForSingleObject。

这里给个选择建议：如果只是"设备插上后打开一份说明文档"这种低频动作，计划任务完全够用，别过度设计；如果触发频繁（比如每处理一个任务就要打开一次结果文件），老老实实写令牌复制；如果业务上需要知道"用户到底关没关那个文件"，只有常驻代理能给你确定答案。

2. 关键前置换算：从服务账户借一个能上桌面的令牌

2.1 服务账户与三个特权的账

CreateProcessAsUser这函数名字起得很实在——"以某用户身份创建进程"，但它对调用者有要求。要让调用成功，调用进程的令牌里得有SeAssignPrimaryTokenPrivilege（给新进程指定主令牌）和SeIncreaseQuotaPrivilege（为新进程调整配额）。而WTSQueryUserToken要求调用者具备SeTcbName（也就是通常说的SE_TCB_NAME，"作为操作系统的一部分"）。

这三个特权在 LocalSystem 账户下默认是有的，所以最省事的做法就是让服务以 LocalSystem 运行。听起来像句废话，但现实中我见过太多服务被安装成NT AUTHORITY\NetworkService或某个自定义域账户，然后开发同事对着 1314 错误码查一整天。NetworkService 没有 TCB 特权，WTSQueryUserToken必然失败。

还有一个更隐蔽的坑：服务令牌的 SID 类型。Windows 支持把服务令牌限制成"受限令牌"（restricted token），这会砍掉一部分特权。用sc.exe qsidtype <服务名>可以查，如果显示RESTRICTED，用sc.exe sidtype <服务名> unrestricted改回来再重启服务。这个坑我在一个老系统迁移项目里遇到过，同一个安装包在新机器上就是不行，最后发现是安装脚本调了ChangeServiceConfig时传了受限 SID 类型。

如果实在不能用 LocalSystem，退路是CreateProcessWithLogonW或者CreateProcessWithTokenW。前者需要用户的明文密码，安全上不可接受，直接排除；后者要求调用者有SeImpersonatePrivilege，而且令牌必须是 primary 类型。CreateProcessWithTokenW在某些场景下比CreateProcessAsUser宽容一些，可以作为备选。

实操心得：写代码时不要假设特权一定存在。启动阶段用OpenProcessToken+AdjustTokenPrivileges显式启用这三个特权，失败就打日志并降级到计划任务方案，比运行到一半突然失败要好排查得多。

2.2 找对会话号：控制台会话不一定是你想要的那个

拿到令牌之前得先知道往哪个会话投递。很多人第一反应是WTSGetActiveConsoleSessionId()，这函数返回当前物理控制台的会话 ID，在单机单用户场景下没问题。但它有个语义陷阱：控制台会话不一定是活动会话。用户锁屏、切换用户、或者通过远程桌面连进来的时候，控制台会话可能处于 disconnected 状态，而真正活跃的会话是另一个 ID。

更稳的做法是枚举所有会话，挑状态为WTSActive的那个。WTSEnumerateSessionsW返回一个WTS_SESSION_INFO数组，每个元素带SessionId和State。策略可以这样定：优先选WTSActive且同时等于控制台会话的那个；如果没有，取第一个WTSActive的；如果连活动会话都没有（比如用户全部锁屏），那就记录日志放弃，或者把文件路径塞进一个待处理队列，等会话恢复再处理。

#include <windows.h> #include <wtsapi32.h> #pragma comment(lib, "Wtsapi32.lib") DWORD FindTargetSession() { DWORD consoleId = WTSGetActiveConsoleSessionId(); PWTS_SESSION_INFOW pSessions = nullptr; DWORD count = 0; DWORD fallback = (DWORD)-1; if (!WTSEnumerateSessionsW(WTS_CURRENT_SERVER_HANDLE, 0, 1, &pSessions, &count)) return (DWORD)-1; DWORD chosen = (DWORD)-1; for (DWORD i = 0; i < count; ++i) { if (pSessions[i].State != WTSActive) continue; if (pSessions[i].SessionId == consoleId) { chosen = consoleId; break; } if (fallback == (DWORD)-1) fallback = pSessions[i].SessionId; } WTSFreeMemory(pSessions); return (chosen != (DWORD)-1) ? chosen : fallback; }

这段代码里有个容易忽略的细节：WTSEnumerateSessionsW分配的内存必须用WTSFreeMemory释放，不能用free或delete[]。混用会导致堆损坏，而且是那种"跑三天才崩一次"的堆损坏，极难定位。我自己就吃过这个亏，最后靠 Application Verifier 才抓到。

2.3 令牌复制与用户环境块

WTSQueryUserToken返回的是用户在该会话中的主令牌句柄，但这个句柄不能直接甩给CreateProcessAsUser，得先用DuplicateTokenEx复制一份TokenPrimary类型的副本。原因是原始句柄可能带有一些不该被新进程继承的属性标记，复制一次能得到干净的、可控的令牌。

复制完令牌，还要解决环境变量的问题。服务进程的环境块是 SYSTEM 的，%USERPROFILE%、%APPDATA%、%TEMP%全都不对。如果直接把这个环境块传给新进程，被打开的程序（尤其是 Office、PDF 阅读器这类会读写用户配置的软件）会找不到自己的配置文件，表现可能是启动后立刻退出，或者弹出一个语焉不详的"配置文件损坏"对话框。

正确姿势是调用CreateEnvironmentBlock(&pEnv, hUserToken, FALSE)，用用户令牌生成环境块，创建进程时传CREATE_UNICODE_ENVIRONMENT标志。用完记得DestroyEnvironmentBlock。

HANDLE hRawToken = nullptr; if (!WTSQueryUserToken(sessionId, &hRawToken)) { // 常见错误码：1314 ERROR_PRIVILEGE_NOT_HELD return GetLastError(); } HANDLE hUserToken = nullptr; BOOL ok = DuplicateTokenEx( hRawToken, MAXIMUM_ALLOWED, nullptr, SecurityImpersonation, TokenPrimary, &hUserToken); CloseHandle(hRawToken); if (!ok) return GetLastError(); LPVOID pEnv = nullptr; CreateEnvironmentBlock(&pEnv, hUserToken, FALSE); // 失败也不致命，降级用 NULL

有一个边界情况要提：如果目标用户的配置文件还没加载（比如服务在用户登录完成之前就尝试打开文件），CreateEnvironmentBlock可能返回一个不完整的环境块。极端情况下需要在服务里调LoadUserProfile主动加载。不过实践下来，只要触发时机是"用户已经点了按钮"或者"用户已经插了设备"，配置文件基本都是加载好的，不必过度防御。

3. 完整实操：把"默认程序打开文件"这件事做对

3.1 工程准备与字符集、库设置

先把工程配置说清楚，因为这里配错了后面全是玄学问题。

项目属性里，字符集选Unicode，不要用多字节。路径里出现中文、日文、带空格的目录名是常态，CreateProcessA那一套会让你在编码转换上耗掉半天。所有 API 都用W结尾的版本，字符串统一用std::wstring。

需要链接的库：Wtsapi32.lib（会话枚举和令牌查询）、Userenv.lib（环境块）、Advapi32.lib（令牌操作）、Shell32.lib（如果走 ShellExecuteEx）。头文件按需包含<windows.h>、<wtsapi32.h>、<userenv.h>、<shellapi.h>。

平台工具集建议选x64。不是性能问题，是文件关联重定向问题：32 位进程访问HKEY_CLASSES_ROOT时会被重定向到Wow6432Node，查到的默认程序可能跟用户在 64 位资源管理器里看到的完全不一样。我遇到过一次"服务打开的 PDF 阅读器和用户双击打开的阅读器不是同一个"，就是这个原因。如果你的服务必须是 32 位，那更要把"查关联"这件事交给 shell 去做，别自己用AssocQueryString查。

调试建议：不要一上来就写成服务。先写一个普通控制台程序，把FindTargetSession和LaunchInUserSession两个函数跑通，确认文件能被打开。确认之后再把wmain换成ServiceMain，逻辑一行不用改。调试服务最痛苦的是断点，用OutputDebugString+ DebugView 比附加进程省事得多。

3.2 核心代码：构造命令行并跨会话启动

主函数长这样。思路是：拿会话 → 拿令牌 → 拿环境块 → 拼命令行 → 指定桌面 → 创建进程 → 清理句柄。

#include <windows.h> #include <wtsapi32.h> #include <userenv.h> #include <string> #pragma comment(lib, "Wtsapi32.lib") #pragma comment(lib, "Userenv.lib") // 简单的参数加引号：路径里可能有空格 static std::wstring Quote(const std::wstring& s) { std::wstring out = L"\""; for (wchar_t c : s) { if (c == L'"') out += L'\\'; out += c; } out += L"\""; return out; } DWORD LaunchInUserSession(const std::wstring& filePath, DWORD sessionId) { HANDLE hRawToken = nullptr; if (!WTSQueryUserToken(sessionId, &hRawToken)) return GetLastError(); HANDLE hUserToken = nullptr; if (!DuplicateTokenEx(hRawToken, MAXIMUM_ALLOWED, nullptr, SecurityImpersonation, TokenPrimary, &hUserToken)) { DWORD err = GetLastError(); CloseHandle(hRawToken); return err; } CloseHandle(hRawToken); LPVOID pEnv = nullptr; CreateEnvironmentBlock(&pEnv, hUserToken, FALSE); wchar_t sysDir[MAX_PATH] = { 0 }; GetSystemDirectoryW(sysDir, MAX_PATH); std::wstring explorer = std::wstring(sysDir) + L"\\explorer.exe"; std::wstring cmdLine = Quote(explorer) + L" " + Quote(filePath); STARTUPINFOW si = { sizeof(si) }; si.lpDesktop = const_cast<LPWSTR>(L"winsta0\\default"); PROCESS_INFORMATION pi = { 0 }; DWORD flags = CREATE_UNICODE_ENVIRONMENT; BOOL ok = CreateProcessAsUserW( hUserToken, explorer.c_str(), &cmdLine[0], nullptr, nullptr, FALSE, flags, pEnv, nullptr, &si, &pi); DWORD result = ok ? ERROR_SUCCESS : GetLastError(); if (ok) { CloseHandle(pi.hThread); CloseHandle(pi.hProcess); } if (pEnv) DestroyEnvironmentBlock(pEnv); CloseHandle(hUserToken); return result; }

几个参数值得单独说。si.lpDesktop = L"winsta0\\default"这一行是整个函数的灵魂，漏了就前功尽弃——进程会创建在 Session 0 的默认桌面上，你又会看到"返回成功但看不见"的熟悉画面。注意字符串必须写成winsta0\\default，反斜杠要转义，写错成winsta0\default在 C++ 里是转义错误，可能变成别的字符。

lpApplicationName传了 explorer 的完整路径，lpCommandLine里也带上了 argv[0]。这是双保险：某些情况下 Windows 会从lpCommandLine里解析可执行文件路径，如果那里没有正确引号，带空格的路径（比如C:\Program Files\...）会被截断成C:\Program，然后报"找不到文件"。

bInheritHandles传 FALSE。服务里可能有一堆不该被继承的句柄（日志文件、命名管道、事件对象），继承下去会在用户进程里造成句柄泄漏，最典型的症状是服务停止时日志文件删不掉——因为用户进程还开着它。

3.3 四种"用默认方式打开"的写法对比

"以默认打开文件的方式打开文件"这句话的准确含义是走 Shell 的文件关联，等价于用户在资源管理器里双击该文件。硬编码AcroRd32.exe "xxx.pdf"不算，因为用户可能装的是别的阅读器甚至用浏览器看 PDF。

我现在的默认选择是第一种 + 第四种组合：常态下用 explorer 转发，简单可靠；需要结果反馈的场景部署一个几十行的 Launcher，内部就是CoInitializeEx+ShellExecuteExW，lpVerb传L"open"，fMask带上SEE_MASK_NOCLOSEPROCESS，拿到hProcess之后回传给服务。

关于cmd /c start，有个细节必须提醒：start命令的第一个带引号参数会被当作窗口标题，所以必须写成start "" "文件路径"，中间那个空引号不能省。省了的话，路径会被当成标题，实际什么都没打开，而且cmd返回 0，你会以为成功了。

explorer 转发还有一个"反常识"的点：如果目标会话里已经有 explorer 在跑（正常情况都有），你新启动的这个 explorer 进程会检测到已有实例，把打开请求通过 Shell 的 IPC 转给老实例，然后自己立刻退出。这意味着WaitForSingleObject(pi.hProcess, ...)会瞬间返回，你没法用它判断"文件到底打开了没有"。想验证效果，别盯进程，盯屏幕。

3.4 命令行拼接、缓冲区与超时参数怎么定

命令行长度上限是 32767 个字符（CreateProcess的硬限制），正常文件路径远达不到。但如果你要把多个文件拼进一次调用，或者路径里有超长目录名，就得留意。我的做法是单次只打开一个文件，需要批量就循环调用，避免在长度上做文章。

缓冲区方面，GetSystemDirectoryW传MAX_PATH够用，但为了兼容长路径，可以先用GetSystemDirectoryW(NULL, 0)拿所需长度再动态分配。WTSQuerySessionInformation也是同样的套路：先传 NULL 拿长度，再分配，再查，最后WTSFreeMemory。

超时的设定分两种场景。如果是 fire-and-forget（explorer 转发），根本不需要等，创建成功就返回，超时设为 0。如果是 Launcher 模式等待用户关闭文件，超时值要按业务定：打开一份 PDF 让用户看，等 30 分钟都合理；打开一份日志让用户扫一眼，5 分钟足够。我的经验是永远设超时，永远不要无限等，因为用户很可能开着窗口去开会了，服务线程被占死，最后整个服务假死。

还有一个容易被忽略的参数：CreateProcessAsUser的dwCreationFlags里，如果不需要控制台窗口，加上CREATE_NO_WINDOW；如果目标程序需要可见的控制台（比如某些命令行工具），加CREATE_NEW_CONSOLE。explorer 转发模式下这两个都不用加，explorer 自己会处理。

4. 踩坑实录：返回成功却没界面，以及一堆 1314

4.1 错误码与现象速查表

这张表是我这几年攒下来的，遇到问题先对一遍，能省掉大量瞎猜。

1314 这个错误码出现的频率高到离谱，以至于我现在看到它第一反应不是查文档，而是直接去看服务账户配置。补充一个排查技巧：在服务里调WhoAmI类似的逻辑，把当前账户名、令牌类型、特权列表打到日志里，出问题时一眼就能看出来。

4.2 explorer.exe 秒退与"看不到窗口"

第一次跑通代码时我盯着日志看了半天：CreateProcessAsUser返回 TRUE，GetLastError是 0，进程 ID 也拿到了，但屏幕上就是没动静。后来才想明白 explorer 的转发机制——它把请求转给已有实例就退出了，这是设计如此，不是失败。

验证方式很简单：把filePath换成一个不存在的路径，如果行为有变化（比如弹出了"找不到文件"的提示），说明整条链路是通的，只是你打开的东西不对。如果换成不存在的路径也毫无反应，那才是链路问题，回去检查lpDesktop。

另一个"看不到窗口"的变体是文件打开了，但窗口在屏幕外或者被最小化。这通常发生在多显示器切换之后，Windows 记住了程序上次的窗口位置，而那个位置现在没有显示器。这不是你代码的问题，但用户会投诉。想规避的话，只能换成 Launcher 模式，在ShellExecuteEx成功后用SetWindowPos把窗口拉回主屏——不过说实话，这个动作有点越界，我一般不做，只在文档里写明"如果窗口不见了，试试 Win+Shift+方向键"。

还有一类现象值得单列：用 SYSTEM 启动的进程，界面风格不一致。你可能会看到打开的窗口标题栏是经典样式、DPI 缩放不对、字体模糊。原因是进程的 DPI 感知上下文和用户会话里的 explorer 不同。解决办法是在STARTUPINFO之外，让目标程序自己处理 DPI，或者干脆走 explorer 转发，让 shell 来决定。

4.3 文件关联、UWP 应用与 32/64 位重定向

Windows 10 之后，图片、视频、音乐、邮件这些类型的默认打开方式基本都指向 UWP 应用（照片、电影和电视、邮件）。UWP 的激活不走普通的CreateProcess，而是走IApplicationActivationManager或者 Shell 的 COM 激活器。这意味着：

• 用 explorer 转发（explorer.exe "C:\pic.jpg"）能正常拉起"照片"应用，因为请求到了 shell 上下文里。
• 直接CreateProcessAsUser启动某个 exe 是打不开 UWP 的。
• 在服务里自己调ShellExecuteEx，即使模拟了用户令牌，也可能失败，因为服务进程里没有完整的 shell COM 环境。

所以如果你的业务涉及打开图片、播放视频，必须走 explorer 转发或者部署 Launcher 到用户会话，没有第三条路。这个结论我在一个巡检项目里验证过：服务里ShellExecuteEx打开 jpg，返回SE_ERR_NOASSOC（错误码 1155 附近），换成 explorer 转发立刻正常。

32/64 位重定向的问题前面提过，这里补一个具体表现：AssocQueryString在 32 位服务里查.pdf，返回的可能是Wow6432Node下的注册项，那个项可能指向一个早就卸载的阅读器，或者压根不存在。你照着这个结果去启动，当然失败。所以我一贯主张：不要在服务里查关联、不要自己拼程序路径，把文件路径原样交给 shell。shell 比你知道得多。

还有一个隐蔽的坑：文件路径里的%字符。如果你用cmd /c start的方式，路径中带%会被当作环境变量展开，变成空字符串。explorer 转发没有这个问题。这也是我不推荐cmd start的原因之一。

5. 长期跑的稳定性：回收、并发与安全边界

5.1 Job Object 与子进程回收

服务有个特点：它可能在任何时候被停止、重启、或者被系统因为更新而终止。如果服务启动的用户进程没有被正确管理，就会变成孤儿进程，用户屏幕上飘着几个不知道从哪来的窗口，关掉还会再弹——因为服务重启后又拉起来了。

标准解法是用 Job Object。创建 job 时设置JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE，把每个启动的子进程AssignProcessToJobObject进去，job 句柄在服务退出时自动关闭，其下所有进程被系统一并干掉。

HANDLE CreateKillOnCloseJob() { HANDLE hJob = CreateJobObjectW(nullptr, nullptr); if (!hJob) return nullptr; JOBOBJECT_EXTENDED_LIMIT_INFORMATION info = { 0 }; info.BasicLimitInformation.LimitFlags = JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE; SetInformationJobObject(hJob, JobObjectExtendedLimitInformation, &info, sizeof(info)); return hJob; }

这里有个坑：如果服务进程本身已经在某个 job 里（某些宿主环境会这么做），子进程默认会继承这个 job，你AssignProcessToJobObject到自己的 job 会失败，错误码 5。解决办法是在CreateProcessAsUser时加CREATE_BREAKAWAY_FROM_JOB标志，让子进程先脱离父 job，再分配。加这个标志前最好用IsProcessInJob判断一下，不然在某些配置下反而会创建失败。

另外提醒一句：explorer 转发模式下，你启动的 explorer 进程是秒退的，job 里几乎立刻就空了，这个机制对它意义不大。Job Object 主要对 Launcher 模式和那些真正长驻的 UI 程序有效。

5.2 会话切换、多用户并发与轮询策略

单用户单会话的环境好办，多用户并发（比如一台机器上三个人分别远程连进来）就复杂了：你得知道"这次打开文件应该投给谁"。

判断依据来自业务本身。如果是"用户在界面上点了按钮"，那触发请求的通道（命名管道、TCP、共享内存）本身就能带上会话信息，服务端解析出来直接用。如果是"设备插入触发"，那就要看设备归属——某些场景下可以查设备被哪个会话挂载，但这属于比较深的系统知识，一般项目用不上。

没有明确归属时，我的默认策略是：优先控制台会话，其次第一个WTSActive会话，都没有就排队等待。排队这件事必须实现，因为用户锁屏是常态，你不能因为锁屏就丢掉请求。队列加上过期时间（比如 10 分钟），过期就丢弃并记日志，避免服务重启后一次性弹出十几个窗口。

轮询会话状态建议 3~5 秒一次，别太密。WTSEnumerateSessions本身开销不大，但服务里如果还有别的定时任务，堆在一起会有可感知的 CPU 波动。有条件的可以用WTSRegisterSessionNotification，不过那个需要窗口句柄，纯服务里用起来别扭，我一般还是老实用定时器。

5.3 别把 SYSTEM 变成任意程序的发射架

这一节必须单独说，因为它关系到安全边界。你写出来的这个功能，本质上是"一个拥有 SYSTEM 权限的进程，能以一个普通用户的身份启动任意程序"。如果文件路径来自外部输入且没做校验，这就是一条现成的提权通道：攻击者构造一个路径，让服务去打开，利用某些程序的特性执行任意代码。

具体的防护措施，我总结了三条：

• 路径白名单或目录白名单。服务只允许打开特定目录下的文件，路径做规范化（GetFullPathName）之后比对前缀，并且校验不含..。软链接和目录联接（junction）也要防，用GetFinalPathNameByHandle解析真实路径再比对。
• 不接受外部传入的可执行文件路径。如果业务是"打开某个文档"，就限定扩展名白名单（.pdf、.txt、.log、.csv这类）；如果业务是"运行某个程序"，那程序路径必须是服务自己拼出来的，不能来自请求方。
• 启动的进程以用户身份而非 SYSTEM 身份运行。这点靠令牌复制天然保证，但如果你图省事用了CreateProcessAsUser却传了服务自己的令牌，那就等于把 SYSTEM 权限交给了用户进程，用户随便开个任务管理器就能结束受保护进程。检查方法：打开任务管理器看进程的"用户名"列，必须是登录用户名，不能是 SYSTEM。

注意：日志里不要把完整的文件路径和用户信息一起明文打出来，尤其当路径里可能包含用户名、项目名这类信息时。脱敏规则按你所在环境的规范来。

另外，服务端对请求方也要做身份校验。如果请求通道是命名管道，用GetNamedPipeClientProcessId拿到客户端 PID，再查它所属的会话和用户，确认跟目标会话一致。这一步能挡住大部分"越权投递"的情况。

6. 我个人在实际操作中的几点体会

这套东西我从第一次踩坑到形成稳定模板，前后改了四五个版本。最大的体会是：别在"打开文件"这个动作上做文章，要在"谁去打开"上做文章。我见过不少同行一直在调ShellExecute的参数，试遍了lpVerb、lpParameters、nShow的所有组合，最后还是打不开——因为问题根本不在那一层。

第二个体会是关于代码组织的。我现在会把这个功能封装成一个独立的模块，对外只暴露一个OpenFileAsUser(const std::wstring& path, DWORD sessionId, DWORD timeoutMs)，内部实现可以是令牌复制、可以是计划任务、也可以是 IPC，调用方不用关心。这样将来某台机器上令牌方案走不通，换实现只改一个文件，业务代码零改动。这个抽象在三个项目里救过我。

第三个体会比较实际：先写测试用例，再写实现。我会准备这么几个测试文件——纯英文短路径、带空格的中文路径、超长路径、无关联扩展名的文件（比如.xyz）、指向 UWP 应用的图片。这五个用例跑通，基本就覆盖了 90% 的现场问题。特别是那个无关联扩展名的，很多人不测，上线后用户点了一个.dat文件，服务返回成功，屏幕毫无反应，投诉就来了。这种情况应该主动提示"该文件类型没有默认打开方式"，而不是假装成功。

最后一个技巧，关于排查现场问题。在服务里加一个隐藏的诊断开关，打开后每次调用都把会话 ID、令牌用户名、命令行、返回码、GetLastError全部写进一个轮转日志文件。用户报"打不开"的时候，让他打开这个开关复现一次，把日志发过来，八成能直接定位。比远程连过去猜要高效得多。这个开关我一般做成配置文件里的一行，改完重启服务生效，不需要重新编译部署。

后续如果业务上要扩展到"打开文件后自动聚焦窗口""打开多个文件按顺序展示""打开失败时弹出友好提示"，思路都是一样的：把动作下沉到用户会话里的那个 Launcher 进程去做，服务只负责投递。边界划清楚了，加功能就不会把架构搞乱。