Windows Server 2019下Process.Start启动进程但无应用界面问题

• 根本原因是Windows自带的Session 0隔离机制：从Windows Server 2008、Vista版本开始，所有系统服务、IIS托管的应用默认运行在编号为0的非交互式会话中，这个会话是系统专门给后台服务预留的，本身就不支持渲染可交互UI，会话内的进程窗口也不会被投递到任何登录用户的可见桌面。
• 你配置的应用池运行账号和登录服务器的服务账号一致，只能解决权限匹配问题，绕不开会话隔离：同一个账号可以同时在多个会话中存在，你看到的保持登录状态的服务账户运行在交互式会话（单用户登录时一般是Session 1，多用户远程登录时ID会递增），和IIS所在的Session 0是完全隔离的两个运行环境。你通过Process.Start("notepad.exe","", uname, Password, domain)启动的notepad.exe实际是跑在Session 0的虚拟桌面上，所以只能在任务管理器看到进程，看不到实体窗口。
• 额外提醒：如果后续要启动带VBA宏的Office类程序，微软官方本身就不支持在服务端非交互式场景下运行Office组件，就算绕开会话隔离，也很容易出现宏加载失败、进程僵死不退出的问题。

按稳定性和安全性从高到低排序：

• 方案1（生产环境首选）：拆分启动逻辑，不要直接从IIS托管的Blazor进程里启动带UI的程序。单独开发一个轻量的常驻代理程序，把它加到服务账户的开机启动项里，让它跟着服务账户登录自动启动，直接运行在当前交互式会话中。Blazor服务端只需要通过本地命名管道、本地环回HTTP请求这类跨进程通信方式给代理发启动指令，由代理负责拉起VBA脚本、宏程序。这个方案完全不碰系统底层的会话隔离限制，不需要给应用开高权限，稳定性最高，后续维护成本最低。
• 方案2（快速验证可用，不推荐生产长期使用）：如果必须从IIS进程直接发起启动，不能用默认的Process.Start方法，需要调用Windows原生API实现跨会话创建进程：
  1. 调用WTSGetActiveConsoleSessionId获取当前活跃的交互式会话ID
  2. 调用WTSQueryUserToken获取对应会话的用户访问令牌
  3. 填充STARTUPINFO结构体，将桌面参数明确指定为winsta0\default
  4. 调用CreateProcessAsUser传入令牌、目标程序路径、启动参数、启动信息创建进程
     注意这个方案需要给IIS应用池的运行账号授予替换进程级令牌、调整进程内存配额等多个敏感系统权限，会大幅放大服务器的安全风险，遇到系统安全加固时很容易出现权限不足的问题。
• 方案3（仅适合本地测试场景）：放弃IIS部署，直接将Blazor应用以服务账户身份自托管为控制台程序，让Blazor进程本身运行在交互式会话中。这种场景下你原来的Process.Start代码可以直接正常工作，启动的程序会和手动点开一样弹出窗口。但自托管模式没有IIS提供的进程守护、自动重启、请求限流等能力，服务稳定性差，不建议在生产环境使用。

额外注意：首次在服务账户环境下运行带VBA的Office程序前，一定要先在该账户的登录会话里手动打开一次对应Office组件，走完首次初始化向导、配置好宏安全规则，把所有首次启动的弹窗都处理完，不然就算进程正常启动，也会卡在初始化步骤没法正常执行宏。

内容的提问来源于stack exchange，提问作者Mr-DillinG