NSSM
v2.25
NSSM是类似于Srvany和Cygrunsrv的服务助手程序。它可以启动任何应用程序（例如控制台）作为NT服务，如果由于任何原因失败，它将重新启动该服务。
NSSM还具有图形服务安装程序和删除剂。
这是NSSM的叉子
您可以在此处发行中找到二进制文件
原始代码：https：//git.nssm.cc/nssm/nssm by iain Patterson
文档：用法，命令
在下面的用法注释中，该程序的论点可以用角括号和/或方括号编写。表示您必须插入适当的字符串，并且表示字符串是可选的。请参阅下面的示例...
请注意，到处出现您可以替换服务的显示名称。
要安装服务，请运行
nssm install <servicename>
将提示您输入要运行的应用程序的完整路径，并进入任何命令行选项，以传递到该应用程序。
使用System Service Manager（Services.MSC）控制高级服务属性，例如启动方法和桌面交互。 NSSM可能会在以后支持这些选项...
要安装服务，请运行
nssm install <servicename> <application> [<options>]
然后，NSSM将尝试安装使用给定选项运行命名应用程序的服务（如果指定任何选项）。
如果包含空间，请不要忘记将路径封闭在“引号”中！
如果您想在选项中包含引号，则需要“”“ Quote”“引号。
当您发送启动信号时，NSSM将启动注册表中列出的应用程序，并在发送停止信号时终止它。到目前为止，非常像Srvany。但是NSSM是非吸毒服务经理，如果应用程序死亡，可以采取行动。
如果您注意到应用程序死亡，但您没有将其发送给停止信号，则NSSM将尝试重新启动自身。 NSSM将继续尝试，在每次尝试之间暂停，直到成功启动该服务或向其发送停止信号。
如果服务未能及时开始，最多可达四分钟，则NSSM将在随后的重新启动尝试之间暂停越来越长的时间。因此，它不会消耗过多的CPU时间，试图一遍又一遍地启动失败的应用程序。如果您确定了失败的原因，并且不想等待，则可以使用Windows Service Console（将在暂停状态显示服务）将继续信号发送给NSSM，并且它将在几秒钟内重试。
默认情况下，NSSM将“及时的方式”定义为在1500毫秒内。您可以通过将毫秒的数量设置为hklm system currentControlset services <服务> parameters appthrottle中的注册表中的reg_dword值来更改服务的阈值。
另外，NSSM可以在尝试重新启动应用程序之前暂停可配置的时间，即使该应用程序在AppThrottle指定的时间量中成功运行。 NSSM将在HKLM System CurrentControlset Services <Service> parameters AssentArtDelay上查阅REG_DWORD值，以获取在尝试重新启动之前等待的毫秒数。如果设置了AscrantArtDelay并确定应用程序要进行节流，则NSSM将暂停该服务，而该服务的更长是已配置的重新启动延迟和计算得出的油门周期。
如果AverestartDelay缺少或无效，则仅应用节流。
NSSM将在HKLM System currentControlset Services <服务> parameters appExit下查看注册表中的字符串（reg_expand_sz）值，与应用程序的退出代码相对应。例如，如果使用代码1退出的应用程序将在Appexit下寻找一个名为“ 1”的字符串值，或者，如果没有找到它，则将返回到AppExit（默认）值。您可以通过咨询系统事件日志来找出应用程序的退出代码。应用程序退出时，NSSM将记录退出代码。
根据注册表中发现的数据，NSSM将采取三个动作之一：
如果值数据为“重新启动”，则NSSM将尝试按照上述重新启动应用程序。这是其默认行为。
如果值数据为“忽略”，则NSSM不会尝试重新启动应用程序，但会继续运行自身。这模仿了斯里瓦尼的（通常是不受欢迎的）行为。 Windows Services Console即使已退出了该应用程序，也将显示该服务仍在运行。
如果值数据为“退出”，则NSSM将优雅地退出。 Windows Services Console将显示该服务如停止。如果您希望提供对服务恢复的较细粒度控制，则应使用此代码并手动编辑故障操作。请注意，Vista之前的Windows版本不会将这种出口视为故障。在较旧版本的Windows上，您应该使用“自杀”。
如果价值数据是“自杀”，则NSSM将在不通知服务经理的情况下模拟崩溃并退出。此选项仅适用于您希望采用服务恢复措施的vista Pre-Vista系统。请注意，如果受监视的应用程序使用代码0退出，则只有在明确配置出口代码0的注册表密钥时，NSSM才会尊重自杀请求。如果只有将默认操作设置为自杀NSSM，则会优雅地退出。
NSSM可以设置托管应用程序的优先类。 NSSM将在HKLM System CurrentControlset Services <服务> 参数下查看注册表中的REG_DWORD输入AppPriority。有效值对应于SetPriorityClass（）的参数。如果缺少AppPriority（）或无效的应用程序将以正常的优先级启动。
NSSM可以设置托管应用程序的CPU亲和力。 NSSM将在HKLM System CurrentControlset Services <服务> 参数下查看注册表中的注册表。它应指定零索引处理器ID的逗号分隔列表。可以选择使用仪表板指定一系列处理器。字符串中不允许其他字符。
例如，指定第一个；第二;第三和第五CPU，适当的Appaftility将为0-2,4。
如果AppAftigation丢失或无效，NSSM将不会尝试将应用程序限制为特定的CPU。
请注意，NSSM的64位版本可以以这种方式配置64个CPU，并且即使在64位窗口运行时，32位版本也可以配置32 CPU的最大值。
停止服务时，NSSM将尝试几种不同的方法来杀死受监视的应用程序，每种应用都可以在必要时禁用。
首先，NSSM将尝试生成Control-C事件并将其发送到应用程序的控制台。批处理脚本或控制台应用程序可能会拦截事件并优雅地关闭自己。 GUI应用程序没有控制台，也不会响应此方法。
其次，NSSM将列举应用程序创建的所有窗口，并向他们发送WM_Close消息，要求优美的出口。
第三，NSSM将枚举应用程序创建的所有线程，并向它们发送WM_QUIT消息，要求优美的出口。并非所有应用程序的线程都有消息队列；那些不会对此方法响应的人。
最后，NSSM将调用TerminateProcess（）要求操作系统强行终止应用程序。终止程序（）不能被困或忽略，因此在大多数情况下，申请将被杀死。但是，不能保证它将有机会在退出之前执行任何整理操作。
上面的任何或全部方法都可以禁用。 NSSM将寻找HKLM System CurrentControlset Services <Services <Service> parameters appStopmethodskip注册表值，该值应为类型reg_dword设置为type typer toge indit fort，描述不应应用哪些方法。
如果AppStopMethodsKip包含1个，则不会生成Control-C事件。如果AppStopmethodskip包含2个，则不会发布WM_Close消息。如果AppStopmethodskip包含4个，则不会发布WM_QUIT消息。如果AppStopmethodskip包括8，则不会调用terminateProcess（）。
例如，如果您知道应用程序没有响应Control-C事件并且没有线程消息队列，则可以将AppStopmethodskip设置为5，而NSSM不会尝试使用这些方法来停止应用程序。
在AppStopmethodskip的价值中包括8个时，请格外小心。如果NSSM未调用terminateProcess（），则可能在服务停止时不会退出。
默认情况下，NSSM将允许进程1500ms响应上述每种方法，然后再进行下一个方法。可以通过在HKLM System CurrentControlset Services <Service> parameters中在注册表中创建REG_DWORD条目来以每方法为基础配置超时。
AppStopmethodconsole AppStopmethodwindow AppStopmethodthreads
每个值应设置为要等待的毫秒数。请注意，超时适用于应用程序过程树中的每个过程，因此，如果应用程序催生了多个子过程，则实际关闭时间可能比所有已配置的超时的总和更长。
要跳过将上述停止方法应用于应用程序过程树中的所有进程，将它们仅应用于原始应用程序过程，请设置HKLM System currentControlset Services Services <Service <Service> parameters appKillProcesstree注册表值，该值应该是REG_DWORD类型，为0。
默认情况下，NSSM将创建一个控制台窗口，以便能够读取用户输入的应用程序可以做到这一点 - 视允许服务与桌面交互的服务。
可以通过将整数（reg_dword）HKLM System CurrentControlset Services <服务> parameters AppNoconsole注册表值设置为1来抑制控制台的创建。
NSSM可以将托管应用程序的I/O重定向到由CreateFile（）打开的任何路径。例如，这可以捕获应用程序的日志输出，否则该应用程序只能写入控制台或接受串行端口的输入。
NSSM将在HKLM System CurrentControlset Services <服务> 参数下查看注册表，用于与createFile（）参数相对应的键。所有都是可选的。如果没有针对特定流的路径，则不会重定向。如果给出了路径，但是省略了其他任何值，它们将被收到明智的默认值。
Appstdin：接收输入的路径。 AppStdout：接收输出的路径。 AppStderr：接收错误输出的路径。
CreateFile（）的参数提供了“ AppStdinShareMode”，“ AppStdinCreationDisposition”和“ AppStdinflagSandAttributes”值（以及STDOUT和STDERR）。
通常，如果您希望该服务将其输出记录，请将AppStdout和AppStderr设置为相同的路径，例如C： Users public public service.log，它应该起作用。但是，请记住，运行服务的用户必须访问该路径。
使用I/O重定向时，NSSM可以在打开Stdout和/或stderr之前旋转现有的输出文件。现有文件将根据文件的最后一个写入时间重命名为后缀，以毫秒精度。例如，文件nssm.log可以旋转到NSSM-20131221T113939.457.log。
NSSM将在HKLM System CurrentControlset Services <服务> 参数下查看注册表中的REG_DWORD条目，以控制旋转方式。
如果缺少批准文件或设置为0，则禁用旋转。任何非零值都可以旋转。
如果批准欧元为非零，则如果文件的最后一个写入时间小于过去的秒数，则不会旋转文件。
如果批准BOINS不零，则如果文件小于给定的字节数小，则不会旋转文件。可以通过设置批准Bythigh的非零值来处理64位文件尺寸。
如果批准的ELARY为非零，则旋转后给定数量的毫秒数将暂停NSSM。
如果AppStDoutCopyAndTruncate或AppStderrcopyantruncate不为零，则将通过首先获取文件的副本，然后将原始文件截断为零大小来旋转stdout（或stderr）文件。这允许NSSM旋转通过其他过程打开的文件，从而阻止通常的MoveFile（）成功。请注意，如果文件大，复制过程可能需要一些时间，并且暂时消耗的磁盘空间是原始文件的两倍。还要注意，读取日志文件的应用程序可能不会注意到文件大小更改。在这种情况下，将此选项与批准的Eljunction结合使用可能会有所帮助。
旋转独立于用于打开文件的CreateFile（）参数。无论NSSM是否会附加或更换它们，它们都会旋转它们。
NSSM还可以旋转在服务运行时击中配置大小阈值的文件。此外，您可以通过运行命令来触发按需旋转
nssm rotate <servicename>
在从托管应用程序中读取下一条数据之后，就会发生按需旋转，而不管批准的价值如何。请注意，如果应用程序不是特别冗长，则可能在一段时间内不会发生旋转。
要启用在线和按需旋转，请将批准条件设置为非零值。
请注意，在线旋转需要NSSM拦截应用程序的I/O并代表其创建输出文件。这比在启动应用程序之前简单地重定向I/O流更为复杂和容易出错。因此，默认情况下不启用在线旋转。
当重定向输出时，NSSM可以将每行输出线以毫秒的时间戳前缀：例如：
2016-09-06 10:17:09.451 Pipeline main started
要启用时间戳前缀，请将AppTimestAmplog设置为非零值。
前缀适用于Stdout和Stderr。前缀需要以与在线旋转相同的方式拦截应用I/O。如果启用了日志旋转和时间戳前缀，则旋转将在线。
NSSM可以替换或附加到托管应用程序的环境中。在HKLM System CurrentControlset Services <Service <Service> parameters中识别了两个多值字符串（REG_MULTI_SZ）注册表值。
Appenvironment定义了环境变量列表，这些变量将覆盖服务的环境。 AppenVironmentExtra定义了环境变量列表，这些变量将添加到服务的环境中。
列表中的每个条目应为“键=值”。可以省略该值，但=符号是强制性的。
Appenvironment和AppenvironmentExtra中列出的环境变量均经过正常的扩展，因此，例如，可以通过设置“路径= C： bin;％路径％”在AppenVironmentExtra中更新系统路径。变量按照出现的顺序进行扩展，因此，如果要在另一个变量中包含一个变量的值，则应首先声明依赖关系。
由于Appenvironment中定义的变量覆盖了现有环境，因此无法参考以前定义的任何变量。
例如，以下Appenvironment块：
PATH=C:WindowsSystem32;C:Windows
PATH=C:bin;%PATH%
如预期，将导致“ C： bin; c： windows system32; c： windows”的路径。
而以下Appenvironment块：
PATH=C:bin;%PATH%
将导致仅包含C： bin的路径，并可能导致应用程序无法启动。
大多数人都希望专门使用AppenVironmentExtra。 Srvany仅支持Appenvinment。
从2.25版开始，NSSM解析了Appenvironment和AppenvironmentExtra本身，然后才能阅读任何其他注册表值。结果，现在可以参考应用程序，AppDirectory和其他参数中的自定义环境变量。
所有Windows服务都可以通过创建一个名为HLKM System currentControlset Services <Service <Service> Environal来传递其他环境变量。
在服务启动之前，该环境块的内容将合并到系统环境中。
但是，请注意，在处理之前，合并的环境将按字母顺序排序。这意味着在实践中，您无法在环境块中设置dir =％programFiles％，因为传递给服务的环境将在定义％dir％的情况下定义％programfiles％。 AppenvironmentExtra中定义的环境变量不会受到此限制。
从2.25版开始，NSSM可以使用类似的命令获取并设置环境块：
nssm get <servicename> Environment
值得重申的是，环境块可用于所有Windows服务，而不仅仅是NSSM服务。
环境NSSM传递到应用程序取决于如何配置各种注册表值。以下流程描述了环境如何修改。
默认情况下：该服务继承了系统环境。
如果定义了环境：环境的内容已合并到环境中。
如果定义了参数 appenvironment：该服务继承了Appenvironment中指定的环境。
如果 parameters appenvironmentExtra被定义：AppenvironmentExtra的内容被附加到环境中。
请注意，Appenvirnment覆盖了系统环境和合并环境块。还要注意，如果定义了AppenVironmentExtra，则保证将其附加到启动环境中。
NSSM可以对应用程序事件运行用户可配置命令。这些命令称为下面的“钩子”。
所有钩子都是可选的。运行的任何钩子都将使用为服务配置的环境启动。 NSSM将将其他变量放入环境中，可以查询这些变量以了解如何和原因。
挂钩按事件和动作进行分类。有些钩子同步运行，有些钩子不同步。带有 *星号前缀的钩子同步运行。 NSSM将等待这些钩子完成，然后再继续其工作。但是，请注意，所有钩子都会在截止日期之前杀死它们，无论它们是否异步运行。
事件：开始 - 当要求开始服务时触发。 *操作：在NSSM尝试启动应用程序之前，请先调用。操作：帖子 - 应用程序成功启动后调用。
事件：停止 - 要求服务停止时触发。 *行动：在NSSM尝试杀死应用程序之前，请先调用。
事件：退出 - 申请退出时触发。 *操作：帖子 - 在NSSM清理了该应用程序之后。
事件：旋转 - 请求在线日志旋转时触发。 *动作：在NSSM旋转日志之前，请先调用。操作：帖子 - NSSM旋转日志后调用。
事件：电源动作：更改 - 系统电源状态发生变化时调用。动作：简历 - 系统从备用中恢复时调用。
请注意，没有停止/后挂钩。这是因为当申请退出时，出口/邮政被调用，无论是否响应服务关闭请求而进行。停止/pre仅在优雅的关闭尝试之前被调用。
NSSM将环境变量nssm_hook_version设置为正数。钩子可以检查数字的值以确定哪些其他环境变量可供选择。
如果NSSM_HOUK_Version为1或更高，则提供了这些变量：
NSSM_EXE-通往NSSM本身的路径。 NSSM_Configuration-构建NSSM可执行文件的信息，例如64位调试。 NSSM_Version- NSSM可执行文件的版本。 NSSM_BUILD_DATE-构建NSSM的日期。 NSSM_PID-运行NSSM可执行文件的进程ID。 NSSM_DEADLINE-毫秒的截止日期数，然后NSSM仍将杀死该挂钩。 NSSM_SERVICE_NAME- NSSM控制的服务名称。 NSSM_SERVICE_DISPLAYNAME-显示服务的名称。 NSSM_COMMAND_LINE-用于启动应用程序的命令行。 NSSM_APPLICATION_PID-主要应用程序过程的进程ID。如果该过程不运行，则可能是空白的。 NSSM_EVENT-事件类触发钩子。 NSSM_ACTION-事件操作触发钩子。 NSSM_TRIGGER-服务控制触发钩子。如果没有通过服务控件触发钩子，例如退出/邮政，则可能是空白的。 NSSM_LAST_CONTROL- NSSM处理的最后一个服务控制。 NSSM_START_REQUESTED_COUNT-要求启动应用程序的次数。 NSSM_START_COUNT-应用程序成功启动的次数。 NSSM_THROTTLE_COUNT-应用程序运行少于油门周期的次数。成功开始时或明确未大规模的服务时，将其重置为零。 NSSM_EXIT_COUNT-退出应用程序的次数。 NSSM_EXITCODE-应用程序的退出代码。如果应用程序仍在运行或尚未启动，则可能是空白的。 NSSM_Runtime- NSSM可执行文件已运行的毫秒数。 NSSM_APPLICATION_RUNTIME-该应用程序自上次启动以来一直在运行的毫秒数。如果尚未启动该应用程序，则可能是空白的。
NSSM的未来版本可能会提供更多的环境变量，在这种情况下，nssm_hook_version将设置为更高的数字。
挂钩是通过以挂钩操作命名的注册表中创建字符串（reg_expand_sz）值来配置的，并将其放置在HKLM System currentControlset Services Services <Serive> parameters parameters appevents <epts <epts>。
例如，可以通过将Appevents Power 简历设置为：
%NSSM_EXE% restart %NSSM_SERVICE_NAME%
要在命令行上设置钩子，请使用
nssm set <servicename> AppEvents <event>/<action> <command>
请注意，如果启动/前挂钩返回99的出口代码，则NSSM将中止应用程序的启动。
服务通常按以下顺序运行挂钩：
开始/启动/启动/邮政停止/前退出/邮政
如果应用程序崩溃并由NSSM重新启动，则该订单可能是：
开始/pre start/post ext/post start/pre start/post stop/pre Pre Exit/post
如果NSSM正在重定向stdout或stderr，则可以配置为重定向其运行的任何挂钩的输出。将批准的hooks设置为1，以启用该功能。钩子当然可以独立于NSSM重定向自己的I/O。
NSSM可以使用用于安装它们的相同的GUI编辑现有服务的设置。跑步
nssm edit <servicename>
提起gui。
NSSM为运行NSSM本身的服务提供了有限的编辑功能。当要求NSSM编辑没有上述应用程序*注册表设置的服务时，GUI将仅允许编辑系统设置，例如服务显示名称和描述。
NSSM可以从命令行检索或设置单个服务参数。总的来说，语法如下，尽管请参见下文。
nssm get <servicename> <parameter>
nssm set <servicename> <parameter> <value>
参数也可以重置为其默认值。
nssm reset <servicename> <parameter>
NSSM识别的参数名称与上述注册表条目名称相同，例如AppDirectory。
NSSM为运行NSSM本身的服务提供了有限的编辑功能。确认的参数如下：
描述：服务描述。 DisplayName：服务显示名称。环境：服务合并环境。 imagePath：服务可执行文件的路径。 ObjectName：运行服务的用户帐户。名称：服务密钥名称。开始：服务启动类型。类型：服务类型。
这些对应于该服务的密钥HKLM System CurrentControlset Services <服务>下的注册表值。
请注意，NSSM将与命令行上传递的所有参数与空格中的所有参数相连，以形成要设置的值。因此，以下两个调用将具有相同的效果。
nssm set <servicename> Description "NSSM managed service"
nssm set <servicename> Description NSSM managed service
在查询环境时，Appenvironment，AppenvironmentExtra和环境参数会识别出一个其他参数。以下语法将打印为服务配置的所有额外环境变量
nssm get <servicename> AppEnvironmentExtra
而下面的语法将仅在ClassPath变量中进行配置，如果在环境块中配置了classPath变量的值，或者如果未配置为空字符串。
nssm get <servicename> AppEnvironmentExtra CLASSPATH
设置环境块时，应在单独的命令行参数中指定每个变量为键=值对。例如：
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes TEMP=C:Temp
或者，可以将键的键与A +或 - 符号前缀，以分别从块中添加或删除一对。
以下两行设置了classpath和temp：
nssm set <servicename> AppEnvironment CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
如果键已经存在，则指定 +键将覆盖该值，同时保留密钥的顺序：
nssm set <servicename> AppEnvironment +CLASSPATH=C:NewClasses
以下语法从块中删除一个变量，同时将任何其他变量留在适当的位置。
nssm set <servicename> AppEnvironment -TEMP
指定-Key =值仅在现有值匹配时才删除变量。
以下语法不会删除temp = c： temp
nssm set <servicename> AppEnvironment -TEMP=C:WorkTemporary
+和 - 符号是环境变量中的有效字符。语法：键=值等于key = value，可用于设置以+/-或明确重置脚本中的块开头的变量：
nssm set <servicename> AppEnvironment :CLASSPATH=C:Classes
nssm set <servicename> AppEnvironment +TEMP=C:Temp
Appexit参数需要一个附加参数，以指定要获取或设置的退出代码。可以使用字符串默认值指定默认操作。
例如，要获取服务的默认退出操作，请运行
nssm get <servicename> AppExit Default
要在使用退出代码2退出时获取退出操作，请运行
nssm get <servicename> AppExit 2
请注意，如果未为指定的退出代码配置明确操作，则NSSM将打印默认的退出操作。
要设置配置服务以停止应用程序时停止，以2为2的退出代码，请运行
nssm set <servicename> AppExit 2 Exit
AppPriority参数用于设置托管应用程序的优先级类。有效的优先级如下：
REALTIME_PRIORITY_CLASS HIGH_PRIORITY_CLASS上方
依赖组和依赖服务参数用于查询或设置服务的依赖项。设置依赖项时，应在单独的命令行参数中指定每个服务或服务组（之前 +符号之前）。例如：
nssm set <servicename> DependOnService RpcSs LanmanWorkstation
或者，依赖项名称可以用A +或 - 符号前缀以分别添加或删除依赖关系。
以下两行设置了RPCSS和LanmanWorkstation的依赖关系：
nssm set <servicename> DependOnService RpcSs
nssm set <servicename> DependOnService +LanmanWorkstation
Follwing语法消除了对RPCSS的依赖性：
nssm set <servicename> DependOnService -RpcSs
严格来说，服务组应与 +符号前缀。要指定对组的单个依赖性， +符号可以以：符号为前缀。
以下行是等效的，每个行仅设定对NetBiosGroup的依赖性：
nssm set <servicename> DependOnGroup NetBIOSGroup
nssm set <servicename> DependOnGroup :NetBIOSGroup
nssm set <servicename> DependOnGroup :+NetBIOSGroup
尽管这些行增加了任何现有依赖性：
nssm set <servicename> DependOnGroup +NetBIOSGroup
nssm set <servicename> DependOnGroup ++NetBIOSGroup
名称参数只能查询，而不是设置。它返回服务的注册表密钥名称。这可能会知道您是否可以利用这一事实，即您可以在语法要求的任何地方替换服务的显示名称。
ObjectName参数仅在设置用户名时才需要附加参数。附加参数是用户的密码。
要检索用户名，请运行
nssm get <servicename> ObjectName
要设置用户名和密码，请运行
nssm set <servicename> ObjectName <username> <password>
请注意，论点串联规则仍然适用。以下调用是有效的，并且会产生预期效果。
nssm set <servicename> ObjectName <username> correct horse battery staple
以下知名用户名不需要密码。使用密码参数时可以省略：
“ localsystem” aka“ aka” aka“ nt权威系统”“ a localservice” aka“ aka”本地服务aka“ aka” nt aka“ nt nternetservice”“ networkService”“ networkService” aka“ aka aka” aka aka aka“ nt ewertion network Service Network Service”虚拟服务“虚拟服务”
开始参数用于查询或设置服务的启动类型。有效的服务启动类型如下：
service_auto_start：启动时自动启动。 service_delayed_start：启动时延迟启动。 service_demand_start：手动服务启动。 service_disabled：服务已禁用。
请注意，在Vista之前的Windows版本上不支持Service_delayed_start。如果延迟启动不可用，NSSM将将服务设置为自动启动。
类型参数用于查询或设置服务类型。 NSSM识别当前已记录的所有服务类型，但仅允许设置两种类型之一：
Service_win32_own_process：独立服务。这是默认值。 service_interactive_process：可以与桌面交互的服务。
请注意，仅当服务在当地系统帐户下运行时，才能将其配置为交互式。配置交互式服务的安全方法分为两个阶段，如下。
nssm reset <servicename> ObjectName
nssm set <servicename> Type SERVICE_INTERACTIVE_PROCESS
NSSM提供基本的服务控制功能。
nssm start <servicename>
nssm restart <servicename>
nssm stop <servicename>
nssm status <servicename>
nssm statuscode <servicename>
“ NSSM状态”和“ NSSM状态代码”的输出是代表服务状态的字符串，例如Service_Running。
如果状态获得成功检索，则“ NSSM状态”的退出代码为0。如果退出代码不是零，则存在错误。
“ NSSM状态代码”的退出代码将是服务状态的数字值，例如Service_Running。零不是有效的服务状态代码。如果出口代码为零，则存在错误。
NSSM也可以删除服务。跑步
nssm remove <servicename>
删除服务。您将提示在删除服务之前确认。尽量不要删除基本系统服务...
要删除无GUI确认的服务，请运行
nssm remove <servicename> confirm
尽量不要删除基本系统服务...
NSSM日志到Windows事件日志。它将其自身注册为事件日志源，并为其日志的每种消息使用唯一的事件ID。新版本可能会添加事件类型，但现有的事件ID将永远不会更改。
由于NSSM寄存器本身的方式，您应该知道，如果您打开事件查看器，并且如果它们不是相同的版本，则可能无法替换NSSM二进制文件，并且从不同位置运行多个NSSM的实例可能会造成混淆。
以下命令将打印NSSM管理的所有服务的名称：
nssm list
要查看系统上的所有服务，而不仅仅是NSSM的服务，请全部使用：
nssm list all
以下命令将打印由给定服务启动的过程ID和可执行过程的可执行过程：
nssm processes <servicename>
请注意，如果在运行较旧版本的Windows的64位系统上运行32位NSSM，则将无法查询64位进程的路径。
NSSM可以转储将重新创建服务配置的命令。可以将输出粘贴到批处理脚本中以备份服务或传输到另一台计算机。
nssm dump <servicename>
由于服务配置可能包含需要从命令提示符引用或逃脱的字符，因此NSSM试图通过添加引号和Caret Escap aff Pusply在运行脚本时正确地产生输出。
为了促进复制服务，转储命令接受第二个参数，该参数指定了要在输出中使用的服务名称。
nssm dump <servicename> <newname>
转储中的行将在显示配置时引用服务。
安装虚幻的锦标赛服务器：
nssm install UT2004 c:gamesut2004systemucc.exe server
作为“游戏”用户运行服务器：
nssm set UT2004 ObjectName games password
将服务器配置为登录到文件：
nssm set UT2004 AppStdout c:gamesut2004service.log
To restrict the server to a single CPU:
nssm set UT2004 AppAffinity 0
To remove the server:
nssm remove UT2004 confirm
To find out the service name of a service with a display name:
nssm get "Background Intelligent Transfer Service" Name
NSSM is known to compile with Visual Studio 2008 and later. Older Visual Studio releases may or may not work if you install an appropriate SDK and edit the nssm.vcproj and nssm.sln files to set a lower version number. They are known not to work with default settings.
NSSM will also compile with Visual Studio 2010 but the resulting executable will not run on versions of Windows older than XP SP2. If you require compatiblity with older Windows releases you should change the Platform Toolset to v90 in the General section of the project's Configuration Properties.
Thanks to Bernard Loh for finding a bug with service recovery. Thanks to Benjamin Mayrargue (www.softlion.com) for adding 64-bit support. Thanks to Joel Reingold for spotting a command line truncation bug. Thanks to Arve Knudsen for spotting that child processes of the monitored application could be left running on service shutdown, and that a missing registry value for AppDirectory confused NSSM. Thanks to Peter Wagemans and Laszlo Keresztfalvi for suggesting throttling restarts. Thanks to Eugene Lifshitz for finding an edge case in CreateProcess() and for advising how to build messages.mc correctly in paths containing spaces. Thanks to Rob Sharp for pointing out that NSSM did not respect the AppEnvironment registry value used by srvany. Thanks to Szymon Nowak for help with Windows 2000 compatibility. Thanks to François-Régis Tardy and Gildas le Nadan for French translation. Thanks to Emilio Frini for spotting that French was inadvertently set as the default language when the user's display language was not translated. Thanks to Riccardo Gusmeroli and Marco Certelli for Italian translation. Thanks to Eric Cheldelin for the inspiration to generate a Control-C event on shutdown. Thanks to Brian Baxter for suggesting how to escape quotes from the command prompt. Thanks to Russ Holmann for suggesting that the shutdown timeout be configurable. Thanks to Paul Spause for spotting a bug with default registry entries. Thanks to BUGHUNTER for spotting more GUI bugs. Thanks to Doug Watson for suggesting file rotation. Thanks to Арслан Сайдуганов for suggesting setting process priority. Thanks to Robert Middleton for suggestion and draft implementation of process affinity support. Thanks to Andrew RedzMax for suggesting an unconditional restart delay. Thanks to Bryan Senseman for noticing that applications with redirected stdout and/or stderr which attempt to read from stdin would fail. Thanks to Czenda Czendov for help with Visual Studio 2013 and Server 2012R2. Thanks to Alessandro Gherardi for reporting and draft fix of the bug whereby the second restart of the application would have a corrupted environment. Thanks to Hadrien Kohl for suggesting to disable the console window's menu. Thanks to Allen Vailliencourt for noticing bugs with configuring the service to run under a local user account. Thanks to Sam Townsend for noticing a regression with TerminateProcess(). Thanks to Barrett Lewis for suggesting the option to skip terminating the application's child processes. Thanks to Miguel Angel Terrón for suggesting copy/truncate rotation. Thanks to Yuriy Lesiuk for suggesting setting the environment before querying the registry for parameters. Thanks to Gerald Haider for noticing that installing a service with NSSM in a path containing spaces was technically a security vulnerability. Thanks to Scott Ware for reporting a crash saving the environment on XP 32-bit. Thanks to Stefan and Michael Scherer for reporting a bug writing the event messages source. Thanks to Paul Baxter for help with Visual Studio 2015. Thanks to Mathias Breiner for help with Visual Studio and some registry fixes. Thanks to David Bremner for general tidyups. Thanks to Nabil Redmann for suggesting redirecting hooks' output. Thanks to Bader Aldurai for suggesting the process tree. Thanks to Christian Long for suggesting virtual accounts. Thanks to Marcin Lewandowski for spotting a bug appending to large files. Thanks to Nicolas Ducrocq for suggesting timestamping redirected output. Thanks to Meang Akira Tanaka for suggestion and initial implementation of the statuscode command. Thanks to Kirill Kovalenko for reporting a crash with NANO server. Thanks to Connor Reynolds for spotting a potential buffer overflow. Thanks to foi for spotting a hang with 64 cores.
NSSM is public domain. You may unconditionally use it and/or its source code for any purpose you wish.
