我正在将node-windows与Node v10.0.0一起使用，以创建将目标app.js作为Windows服务运行的Windows服务。在较高级别，此lib创建一个 shell .exe文件，该文件注册为Windows服务，然后生成node作为具有某些命令行参数的子进程。将外壳程序.exe安装为Windows服务后，您可以像常规app.js应用程序一样构建node，只需重新启动Windows服务即可反映所做的更改。 （非常酷！）
通常，子node进程的命令行如下所示：
node --harmony <other node command line args, which are optional> app.js
由于此命令行中没有调试标志，因此我决定使用VSCode's Attach by ProcessID功能并按如下所示设置调试启动配置：
{
"type": "node",
"request": "attach",
"name": "Attach by Process ID",
"processId": "${command:PickProcess}",
"stopOnEntry": true,
"protocol": "auto"
}
我还确保我以管理员身份运行VSCode，并且足够肯定的是，当我启动Windows服务并启动“按进程ID附加”调试器时，VSCode会向我显示一个列出了节点进程的选择器。
但是，当我尝试附加到该节点进程时，出现错误：
Attach to process: cannot enable debug mode for process'5744'(Error: Command failed:
node -e process._debugProcess(5744)
[eval]:1
process.debugProcess(5744)
^
Error: Access is denied
at [eval]:1:9
....
....
我尝试通过将node子进程作为分离的进程生成来进行此操作，但这没有任何区别。我的直觉是Windows进程以某种方式在node进程上保持 lock 的种类，从而防止任何其他进程与其交互。
如果我将Windows服务部署配置为实际上通过以下命令行产生子进程：
node --harmony --inspect app.js
然后，我可以对端口9229（VSCode默认调试端口）进行常规连接并能够单步执行代码，但是app.js失败，因为Windows服务尝试多次启动它并超时。这是node-windows的一项功能，以防止您尝试作为Windows服务托管的app.js出现错误时进行永久重试。
请注意，app.js没什么问题，并且没有--inspect标志，Windows服务正常运行，并且app.js的所有功能均按预期工作（这是简单的express服务（如果您必须知道的话）将具有一个根响应路径，并以“ Hello World”作为响应。）
此外，即使我未尝试附加，如果我在子进程命令行中使用--inspect标志，Windows服务也无法启动。
我从Visual Studio / C＃时代回忆起，曾经有一个调试选项，当用户处于调试会话中时，该选项实际上会禁用所有计时器，以解决此类问题，但是不确定是否会之所以可以在这里工作，是因为我们实际上是在尝试加入一个node进程，该进程独立于托管Windows进程。
所以我只想与社区分享，看看其他人是否可以成功解决此问题。