Bug: Stop-Process does not issue SIGTERM as expected.

Steps to reproduce

taskkill /IM "App With Tray Icon.exe"

Without moving mouse, tray icon disappears from tray immediately.

Stop-Process "App With Tray Icon"

Without moving mouse, tray icon is stays visible. Additionally, starting the process again will display a duplicate icon, the old one disappears when hovering over it.

Expected behavior

Stop-Process by default should be SIGTERM, graceful. SIGKILL should only be used after timeout or -FORCE is used.

Actual behavior

The old tray icon stays visible because app is killed. (This is not actually PowerShell specific, but a technical caveat when processes are killed.)

Workaround

Use taskkill in place of stop-process for processes that have tray icons.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.20215
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[manokara]

I’m on Windows with PowerShell 7.1.5. This behavior is quite unintuitive, because there is a -Force switch but Stop-Process always acts as if it was on, killing a process without mercy instead of gracefully shutting it down. I’ve noticed this also happens with Task Manager - it doesn’t give you an option to request a process to terminate, allowing for cleanup routines to be run. Being mostly a Linux user, I’m used to SIGTERMing processes and only SIGKILLing them as a last resort. Seems like SIGKILL is the default expected behavior on Windows.

In my use case, I’m dealing with console processes on a CI deployment pipeline so CloseMainWindow() doesn’t apply. Using taskkill instead as OP mentioned works as expected.

[iSazonov]

Even if we address all the problems above - i.e. if we truly give all all targeted processes a chance to terminate gracefully - enforcing (ultimate) termination should (a) be opt-in and (b) can, as stated, only be achieved by waiting for actual termination based on a timeout, given that SIGTERM / CTRL_CLOSE_EVENT handlers can refuse to terminate in response to a request.

I believe we should do the cmdlet too smart and complex. It is currently impossible to send an event or signal to a process so that it terminates gracefully.

The suggestion is to just add such a feature - just send the signal and nothing else.

All other smart things the user can do himself (or we can add later after receiving feedback).

---

We can implement this on Unix too https://stackoverflow.com/questions/41041730/net-core-app-how-to-send-sigterm-to-child-processes

<div>Stack Overflow</div><div>.net-core app: how to send SIGTERM to child processes?</div><div>Is it possible for .net-core app running on Linux to send SIGTERM signal to a child process?

We’re thinking to port our .net app to .net-core and run it on Linux, to avoid current signal implement…</div>