I have a logon task that launches a Node server through a hidden script-host chain: wscript starts a VBScript, which starts cmd and then node.exe. During updates, I used Stop-ScheduledTask, copied in the new files, and started the task again. The task changed to Ready, but the original Node process was still alive and holding its port. The new process then failed with EADDRINUSE, while a basic health check mistakenly confirmed that the old version was still responding.
My current workaround is to stop the task, find node.exe by matching the exact server.js path in its command line, terminate that process, wait for the port to be released, and only then start the updated task. I also verify that the process listening on the port belongs to the new copy. I avoid stopping by process name because other Node processes may be running, and command-line access can be null without elevation.
The same update script also needs to handle native command results explicitly: PowerShell does not automatically throw when powershell.exe fails, and robocopy exit codes from 1 through 7 indicate success rather than failure.
Is this expected behavior when a scheduled task launches a script host that creates descendants? Also, is there a clean replacement for the hidden VBScript launcher that still starts a visible desktop application at logon without a console flash?
4 Answers
The other two behaviors are common scripting gotchas. A native PowerShell command such as powershell.exe can fail without throwing a PowerShell exception, so check $LASTEXITCODE immediately afterward. Robocopy uses a bitmask-style exit code: values below 8 generally mean success or success with differences, while 8 or higher indicates a failure.
Those checks are separate from the scheduled-task issue, but they matter because an update script can otherwise continue after either the registration step or the file copy went wrong.
The port check is a good idea, but checking only the first listener can be misleading when another component is also using that port. Query the owning PID, then inspect that PID's executable and command line, ideally also confirming the expected address and protocol. A successful HTTP response alone only proves that something is answering, not that the newly deployed copy is serving it.
For the update flow, I would use: stop the targeted process, wait for process and port shutdown, move the old release aside, copy the new release, start it, verify its PID and command line, and roll back if validation fails.
Yes, the important distinction is between stopping the task and stopping every process created by its action. Task Scheduler can end the process it launched, but that does not reliably mean descendants such as cmd.exe or node.exe are terminated. Once the parent exits, the child can continue independently and keep its port open.
Matching the complete command line or executable path is much safer than killing every node.exe process. After terminating it, wait for the PID to disappear and confirm the port is free before copying or starting the replacement.
The scheduled-task approach is understandable here because the program needs to launch desktop windows in the logged-in user's session. A normal service runs in session 0, so anything it starts generally will not appear on the user's desktop. A service wrapper would be a better fit for a headless server, but it would be awkward for an interactive agent like this.
That said, VBScript and wscript are legacy components and are being phased out. PowerShell may be a replacement, although hiding a console window at logon can still produce a brief flash. A small compiled launcher or another process configured for a hidden window may be cleaner long term.
That is the trade-off I ran into: replacing wscript would improve the launcher, but it would not fix the shutdown behavior by itself. The update still needs to stop the actual Node process and verify that the correct process owns the port.