背景
我正在设计一个Inno Setup安装程序来安装Cygwin服务，我对Windows Restart Manager API的行为感到困惑。
具体而言，当服务正在运行(使用cygrunsrv实用程序启动)时，RmGetList API函数为其lpdwRebootReasons输出参数返回2(RmRebootReasonSessionMismatch)。此输出参数是RM_REBOOT_REASON类型的枚举，MSDN上对RmRebootReasonSessionMismatch值的描述为：
One or more processes are running in another Terminal Services session.
Inno Setup日志文件包含如下行：
RestartManager found an application using one of our files: <executable name>
RestartManager found an application using one of our files: <service name>
Can use RestartManager to avoid reboot? No (2: Session Mismatch)
Inno Setup随后继续尝试替换正在使用的文件，就好像根本没有使用Restart Manager一样。
我对这个输出值感到困惑，因为在我测试的两台不同的机器上(Windows 10 1909 x64和Windows Server 2012 R2)，没有终端服务器/远程桌面用户登录。
如果我停止服务并启动另一个可执行文件(在安装程序要替换的文件集中)，RmGetList会为lpdwRebootReasons返回0(RmRebootReasonNone)，Inno Setup会显示正在使用的文件的正常对话框，并允许用户选择自动关闭它们。
Process Explorer显示在会话0和System完整性级别运行的两个进程(cygrunsrv.exe及其启动的进程)。两者都是控制台子系统的可执行文件。
问题
RmGetList在什么条件下为其
lpdwRebootReasons输出参数返回2(RmRebootReasonSessionMismatch)？(我试图理解为什么在服务运行时会发生这种情况。)此值是否会导致整个Restart Manager会话失败，或者即使Restart Manager认为应用程序正在一个或多个不同的会话中运行，它也可以继续？
对于问题2，在文档RM_PROCESS_INFO中
b可重启
TRUE如果重新启动管理器可以重新启动应用程序；否则，FALSE。如果过程是服务如果进程是关键的，则此成员总是FALSE系统进程。
此值指示重新启动管理器是否可以重新启动应用程序。
对于问题1，请注意，服务正在会话0中运行。如果占用资源的进程(在RmRegisterResources中注册)是服务a，则同样在服务进程B中运行的RmGetList函数将返回lpdwRebootReasons = RmRebootReasonNone、bRestartable = TRUE。
但如果A不是服务，那么A&B在不同的会话中运行，lpdwRebootReasons = RmRebootReasonSessionMismatch和bRestartable = FALSE
其他结果：(B以提升的权限运行)
- A&B是控制台，并且在同一会话中：
lpdwRebootReasons = RmRebootReasonNone、bRestartable = TRUE、ApplicationType = RmConsole - A&B是控制台，并且在不同的会话中：
lpdwRebootReasons = RmRebootReasonSessionMismatch、bRestartable = FALSE、ApplicationType = RmConsole - A： 服务，B:控制台：
lpdwRebootReasons = RmRebootReasonNone、bRestartable = TRUE、ApplicationType = RmService
(B没有以提升的权限运行)：
- A&B是控制台，在不同的会话中：
lpdwRebootReasons = RmRebootReasonCriticalProcess、bRestartable = FALSE、ApplicationType = RmCritical - A： 服务，B:控制台：
lpdwRebootReasons = RmRebootReasonPermissionDenied、bRestartable = FALSE、ApplicationType = RmCritical
根据文件bRestartable依赖于ApplicationType。然后，我们可以看到，如果bRestartable = TRUE，那么lpdwRebootReasons = RmRebootReasonNone。但当bRestartable = FALSE时，它取决于其他成员RM_PROCESS_INFO。
RestartManager PowerShell模块的线索RestartManager PowerShell模块(特别感谢Heath Stewart)为RestartManager提供了一个简单的PowerShell接口。我的命令如下：
Set-Location <path to Cygwin root directory>
Start-RestartManagerSession
Get-ChildItem . -File -Include *.exe,*.dll -Recurse | RegisterRestartManagerResource
Get-RestartManagerProcess
Stop-RestartManagerProcess
这些命令产生以下输出：
Id : <process ID>
StartTime : <process start time>
Description : <executable started by cygrunsrv>
ServiceName :
ApplicationType : Console
ApplicationStatus : Running
IsRestartable : False
RebootReason : SessionMismatch
Id : <cygrunsrv process id>
StartTime : <cygrunsrv process start time>
Description : <description of service>
ServiceName : <service name>
ApplicationType : Service
ApplicationStatus : Running
IsRestartable : True
RebootReason : SessionMismatch
出于某种原因，Restart Manager将cygrunsrv.exe服务进程视为可重新启动，但它生成的可执行文件不可重新启动。(我仍然很好奇为什么会发生这种情况。)
一次不完美的变通尝试
基于观察到的这种行为，我首先尝试了以下解决方法：
在Inno Setup脚本的
[Setup]部分中，设置以下内容：CloseApplications=yes CloseApplicationsFilter=*.chm,*.pdf RestartApplications=yesCloseApplicationsFilter指令指定要向Restart Manager注册的文件。注意，此处未指定*.exe或*.dll；我只想在[Code]部分手动指定某些.exe文件。对于设置中不会由
cygrunsrv派生的每个.exe文件，调用Inno SetupRegisterExtraCloseApplicationsResource函数一次，并将它们放入RegisterExtraCloseApplicationsResources事件过程中。示例：[Code] procedure RegisterExtraCloseApplicationsResources(); begin RegisterExtraCloseApplicationsResource(false, ExpandConstant('{app}bincygrunsrv.exe')); end;
重要的是不要注册cygrunsrv.exe或任何Cygwin DLL文件派生的任何可执行文件，因为这将阻止Restart Manager在Inno Setup中生效。
此解决方案远非完美，因为通常由cygrunsrv启动的可执行文件，如果单独启动，则不会被Restart Manager(例如sshd.exe)检测到。例如，在Restart Manager无法重新启动的可执行文件中生成新的SSH会话。
更好的解决方案
我决定，一个更好的解决方案是从代码中检测任何正在运行的可执行文件，并提示用户不要使用Restart Manager功能(简单地说，这对Cygwin服务不起作用)。