I've been working with various approaches for running and terminating subprocesses on Windows and I've obtained surprisingly different results if I used different modules and ways of termination. Here is the script I wrote, it uses the `subprocess` and the `multiprocessing` modules for starting new subprocesses, and process termination is performed either by the modules' own `terminate` functions or by `os.kill`.

```py
import multiprocessing
import os
import signal
import subprocess
import sys
import time

def kill_with_os_kill(proc):
    print('kill with os.kill(pid,SIGTERM)')
    os.kill(proc.pid, signal.SIGTERM)

def kill_with_terminate(proc):
    print('kill child with proc.terminate()')
    proc.terminate()

def run_and_kill_subprocess(killfn, procarg):
    print('run subprocess child with %s' % procarg)
    with subprocess.Popen([sys.executable, __file__, procarg]) as proc:
        time.sleep(1)
        killfn(proc)
        proc.wait()
    print('child terminated with %s' % proc.returncode)

def run_and_kill_multiprocessing(killfn, procarg):
    print('run multiprocessing child with %s' % procarg)
    proc = multiprocessing.Process(target=childmain, args=(procarg,))
    proc.start()
    time.sleep(1)
    killfn(proc)
    proc.join()
    print('child terminated with %s' % proc.exitcode)

def childmain(arg):
    print('child process started with %s' % arg)
    while True:
        pass

if __name__ == '__main__':
    if len(sys.argv) < 2:
        print('parent process started')
        run_and_kill_subprocess(kill_with_os_kill, 'subprocess-oskill')
        run_and_kill_subprocess(kill_with_terminate, 'subprocess-terminate')
        run_and_kill_multiprocessing(kill_with_os_kill, 'multiprocessing-oskill')
        run_and_kill_multiprocessing(kill_with_terminate, 'multiprocessing-terminate')
    else:
        childmain(sys.argv[1])
```

On macOS, everything works as expected (and I think that Linux will behave alike):

```
$ python3 killtest.py 
parent process started
run subprocess child with subprocess-oskill
child process started with subprocess-oskill
kill with os.kill(pid,SIGTERM)
child terminated with -15
run subprocess child with subprocess-terminate
child process started with subprocess-terminate
kill child with proc.terminate()
child terminated with -15
run multiprocessing child with multiprocessing-oskill
child process started with multiprocessing-oskill
kill with os.kill(pid,SIGTERM)
child terminated with -15
run multiprocessing child with multiprocessing-terminate
child process started with multiprocessing-terminate
kill child with proc.terminate()
child terminated with -15
```

But on Windows, I got:

```
>py -3 killtest.py
parent process started
run subprocess child with subprocess-oskill
child process started with subprocess-oskill
kill with os.kill(pid,SIGTERM)
child terminated with 15
run subprocess child with subprocess-terminate
child process started with subprocess-terminate
kill child with proc.terminate()
child terminated with 1
run multiprocessing child with multiprocessing-oskill
child process started with multiprocessing-oskill
kill with os.kill(pid,SIGTERM)
child terminated with 15
run multiprocessing child with multiprocessing-terminate
child process started with multiprocessing-terminate
kill child with proc.terminate()
child terminated with -15
```

Notes:
- On Windows with `os.kill(pid, sig)`, "sig will cause the process to be unconditionally killed by the TerminateProcess API, and the exit code will be set to sig." I.e., it is not possible to detect on Windows whether a process was terminated by a signal or it exited properly, because `kill` does not actually raise a signal and no Windows API allows to differentiate between proper or forced termination.
- The `multiprocessing` module has a workaround for this by terminating the process with a designated exit code (`TERMINATE = 0x10000`) and checking for that value afterwards, rewriting it to `-SIGTERM` if found. The related documentation is a bit misleading, as `exitcode` is meant to have "negative value -N [which] indicates that the child was terminated by signal N" -- however, if the process was indeed killed with `SIGTERM` (and not via `terminate`), then `exitcode` will be `SIGTERM` and not `-SIGTERM` (see above). (The documentation of `terminate` does not clarify the situation much by stating that "on Windows TerminateProcess() is used", since it does not mention the special exit code -- and well, it's not even a signal after all, so it's not obvious whether negative or positive exit code is to be expected.)
- The `subprocess` module choses the quite arbitrary exit code of 1 and documents that "negative value -N indicates that the child was terminated by signal N" is POSIX only, not mentioning anything about what to expect on Windows.

Long story short: on Windows, the observable exit code of a forcibly terminated child process is quite inconsistent even across standard modules and termination methods, unlike on other (Linux/macOS) platforms. I think that having results consistent with `os.kill(,SIGTERM)` would be desirable even if that means non-negative values.

I'm willing to post a PR if the issue is deemed to be valid.

Setting the exit code to the negative of a C signal value isn't generally meaningful in Windows. It seems multiprocessing doesn't have a significant use for this, other than getting a formatted exit code in the repr via its _exitcode_to_name dict. For example:

    p = multiprocessing.Process(target=time.sleep, args=(30,))
    p.start()
    p.terminate()

    >>> p
    <Process(Process-1, stopped[SIGTERM])>

This may mislead people into thinking incorrectly that Windows implements POSIX signals. Python uses the C runtime's emulation of the basic set of required signals. SIGSEGV, SIGFPE, and SIGILL are based on exceptions. SIGINT and SIGBREAK are based on console control events. SIGABRT and SIGTERM are for use with C `raise`. Additionally it implements os.kill via TerminateProcess and GenerateConsoleCntrlEvent. (The latter takes process group IDs, so it should have been used to implement os.killpg instead. Its use in os.kill is wrong and confusing.)

The normal exit code for a forced shutdown is 1, which you can confirm via Task Manager or `taskkill /F`. subprocess is correct here. I think multiprocessing should follow suit.

`taskkill /F` sets exit code to 1, indeed. (Confirmed by experiment. Cannot find this behaviour documented, though.)

On the other hand, MS Docs state (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/signal#remarks) that termination by a signal "terminates the calling program with exit code 3". (So, there may be other "valid" exit codes, too.)

A follow-up: in addition to `taskkill`, I've taken a look at another "official" way for killing processes, the `Stop-Process` PowerShell cmdlet (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/stop-process?view=powershell-5.1). Yet again, documentation is scarce on what the exit code of the terminated process will be. But PowerShell and .NET code base is open sourced, so I've dug a bit deeper and found that `Stop-Process` is based on `System.Diagnostics.Process.Kill()` (https://github.com/PowerShell/PowerShell/blob/master/src/Microsoft.PowerShell.Commands.Management/commands/management/Process.cs#L1240), while `Process.Kill()` uses the `TerminateProcess` Win32 API (https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/System/Diagnostics/Process.Windows.cs#L93). Interestingly, `TerminateProcess` is called with -1 (this was surprising, to me at least, as exit code is unsigned on Windows AFAIK).

Therefore, I've added two new "kill" implementations to my original code experiment (wont repeat the whole code here, just the additions):

```py
def kill_with_taskkill(proc):
    print('kill child with taskkill /F')
    subprocess.run(['taskkill', '/F', '/pid', '%s' % proc.pid], check=True)

def kill_with_stopprocess(proc):
    print('kill child with powershell stop-process')
    subprocess.run(['powershell', 'stop-process', '%s' % proc.pid], check=True)
```

And I got:

```
run subprocess child with subprocess-taskkill
child process started with subprocess-taskkill
kill child with taskkill /F
SUCCESS: The process with PID 4024 has been terminated.
child terminated with 1
run subprocess child with subprocess-stopprocess
child process started with subprocess-stopprocess
kill child with powershell stop-process
child terminated with 4294967295

run multiprocessing child with multiprocessing-taskkill
child process started with multiprocessing-taskkill
kill child with taskkill /F
SUCCESS: The process with PID 5988 has been terminated.
child terminated with 1
run multiprocessing child with multiprocessing-stopprocess
child process started with multiprocessing-stopprocess
kill child with powershell stop-process
child terminated with 4294967295
```

My takeaways from the above are that
1) Windows is not consistent across itself,
2) 1 is not the only "valid" "terminated forcibly" exit code, and
3) negative exit code does not work, even if MS itself tries to use it.

BTW, I really think that killing a process with a code of 1 is questionable, as quite some apps return 1 themselves just to signal error (but proper termination). This makes it hard to tell applications' own error signaling and forced kills apart. But that's a personal opinion.

A C/C++ program returns EXIT_FAILURE for a generic failure. Microsoft defines this macro value as 1. Most tools that a user might use to forcibly terminate a process don't allow specifying the reason; they just use the generic value of 1. This includes Task Manager, taskkill.exe /f, the WDK's kill.exe -f, and Sysinternals pskill.exe and Process Explorer. subprocess and multiprocessing should also use 1 to be consistent.

The system itself doesn't distinguish a forced termination from a normal exit. Ultimately every thread and process gets terminated by the system calls NtTerminateThread and NtTerminateProcess (or the equivalent Process Manager private functions PspTerminateThreadByPointer, PspTerminateProcess, etc). Windows API TerminateThread and TerminateProcess are light wrappers around the corresponding system calls.

ExitThread and ExitProcess (actually implemented as RtlExitUserThread and RtlExitUserProcess in ntdll.dll) are within-process calls that integrate with the loader's LdrShutdownThread and LdrShutdownProcess routines. This allows the loader to call the entry points for loaded DLLs with DLL_THREAD_DETACH or DLL_PROCESS_DETACH, respectively. ExitThread also handles deallocating the thread's stack. Beyond that, the bulk of the work is handled by NtTerminateThread and NtTerminateProcess. For ExitProcess, NtTerminateProcess is actually called twice -- the first time it's called with a NULL process handle to kill the other threads in the current process. After LdrShutdownProcess returns, NtTerminateProcess is called again to truly terminate the process.

> PowerShell and .NET ... `System.Diagnostics.Process.Kill()` ... 
> `TerminateProcess` is called with -1

.NET is in its own (cross-platform) managed-code universe. I don't know why the developers decided to make Kill() use -1 (0xFFFFFFFF) as the exit code. I can guess that they negated the conventional EXIT_FAILURE value to indicate a signal-like kill. I think it's an odd decision, and I'm not inclined to favor it over behaviors that predate the existence of .NET. 

Making the ExitCode property a signed integer in .NET is easy to understand, and not a cause for concern since it's only a matter of interpretation. Note that the return value from wmain() or wWinMain() is a signed integer. Also, the two fundamental status result types in Windows -- NTSTATUS [1] and HRESULT [2] -- are 32-bit signed integers (warnings and errors are negative). Internally, the NT Process object's EPROCESS structure defines ExitStatus as an NTSTATUS value. You can see in a kernel debugger that it's a 32-bit signed integer (Int4B):

    lkd> dt nt!_eprocess ExitStatus
       +0x624 ExitStatus : Int4B

Python also wants the exit code to be a signed value. If we try to exit with an unsigned value that exceeds 0x7FFF_FFFF, it instead uses a default code of -1 (0xFFFF_FFFF). For example:

    >>> hex(subprocess.call('python -c "raise SystemExit(0x8000_0000)"'))
    '0xffffffff'

Using the corresponding signed integer works fine:

    >>> 0x8000_0000 - 2**32
    -2147483648
    >>> hex(subprocess.call('python -c "raise SystemExit(-2_147_483_648)"'))
    '0x80000000'

[1]: https://msdn.microsoft.com/en-us/library/cc231200
[2]: https://msdn.microsoft.com/en-us/library/cc231198


> termination by a signal "terminates the calling program with 
> exit code 3"

MS C raise() defaults to calling exit(3). I don't know why it uses the value 3; it's a legacy value from the MS-DOS era. Python doesn't directly expose C raise(), so this exit code only occurs in rare circumstances.

Note that SIGINT and SIGBREAK are based on console control events, and in this case the default behavior (i.e. SIG_DFL) is not to call exit(3) but rather to continue to the next registered console control handler. This is normally the Windows default handler (i.e. kernelbase!DefaultHandler), which calls ExitProcess with STATUS_CONTROL_C_EXIT. When closing the console itself (i.e. CTRL_CLOSE_EVENT), if a control handler in a console client returns TRUE, the default handler doesn't get called, but (starting with NT 6.0) the process still has to be terminated. In this case the session server, csrss.exe, calls NtTerminateProcess with STATUS_CONTROL_C_EXIT.

The exit code also isn't normally 3 for SIGABRT when abort() (i.e. os.abort in Python) gets called. In a release build, abort() defaults to using the __fastfail intrinsic (i.e. INT 0x29 on x64 systems) with the code FAST_FAIL_FATAL_APP_EXIT. This terminates the process with a STATUS_STACK_BUFFER_OVERRUN exception. By design, a __fastfail exception cannot be handled. An attached debugger only sees it as a second-chance exception. (Ideally they should have split this functionality into multiple status codes, since a __fastfail isn't necessarily due to a stack buffer overrun.) The error-reporting dialog may change the exit status to 255 in this case, but you can suppress this dialog via SetErrorMode(SEM_NOGPFAULTERRORBOX) or by using a Job object that's flagged to suppress it. You can also override the CRT's default abort() behavior to skip __fastfail. Either set a SIGABRT handler that exits the process. Or call _set_abort_behavior to unset _CALL_REPORTFAULT, in which case the exit code will be 3.

And I thought that my analysis was thorough... Exit code 1 is the way to go, I agree now.

If a multiprocessing Process gets terminated by any means other than its terminate() method, it won't get this special TERMINATE (0x10000) exit code that allows the object to pretend the exit status is POSIX -SIGTERM. In general, the exit code will be 1. IMO, Process.terminate should be consistent with typical exit code of 1 and thus consistent with Popen.terminate. However, I'm adding Davin and Antoine to the nosy list in case they disagree -- before you go to the trouble of creating a PR.

I would like to know what our resident Windows users think about this (Paul, Steve, Zach).

Reading the above arguments, I'd be inclined to settle on 15 (that is, the non-negative "signal" number).  While it is not consistent with what "taskkill" or other APIs do, it makes it clear that the process was terminated in a certain way.  Certainly, there is a slight chance that 15 is a legitimate error code returned by the process, but that is far less likely than returning 1 as a legitimate error code, which I presume is extremely common.

In any case, this can't go in a bugfix release, so marking as 3.7-only.

I'm not actually sure what the proposal here is. Are we suggesting that all Python's means of terminating a process should use the same exit code?

Note that doing so would be a backward compatibility break, as os.kill() is documented as having the behaviour seen here (it's just that SIGTERM isn't a particularly meaningful value to use on Windows). subprocess terminate() doesn't document the exit code sent on Windows, and maybe should - but 1 seems a reasonable value (it's the C EXIT_FAILURE code after all). I don't fully understand the issue multiprocessing is trying to solve, but it seems to be around signals, which are very different between Windows and Unix anyway.

So, in summary - I'd need to see a specific proposal, but my instinct is that this is only an issue if you're trying to cover over the differences between Unix and Windows, and this isn't a case where I think that's advisable (the current situation is "good enough" if you don't care, and if you do, you have the means to do it right, you just need to cater for the platform differences yourself, in a way that suits your application.).

> I'm not actually sure what the proposal here is. Are we suggesting 
> that all Python's means of terminating a process should use the 
> same exit code?

That's how I read it, but I don't agree if it means always pretending that a process was killed by a SIGTERM POSIX signal. That's fighting an uphill battle against the platform and its conventions.

I singled out the case where multiprocessing tries to pretend that Windows has Unix signals. It documents that `exitcode` will be negative if terminated by a signal. It doesn't qualify that this is only in Unix.

    exitcode
        The child’s exit code. This will be None if the process has not
        yet terminated. A negative value -N indicates that the child
        was terminated by signal N.

A negative exit code in Windows (i.e. 0x8000_0000 and above) has many possible meanings. Generally it indicates an abnormal error of some sort that terminated the process, and generally the code is an NTSTATUS or HRESULT value, such as STATUS_CONTROL_C_EXIT or E_FAIL (0x8000_4005). However, there isn't a convention to use an NTSTATUS or HRESULT error code when manually terminating a process. Instead, the convention is to use EXIT_FAILURE (1).

multiprocessing pretends that terminate() is implemented with a SIGTERM signal. To do so, it terminates with an exit code that's just above the system 16-bit range:

    TERMINATE = 0x10000

    def terminate(self):
        if self.returncode is None:
            try:
                _winapi.TerminateProcess(int(self._handle), TERMINATE)
            except OSError:
                if self.wait(timeout=1.0) is None:
                    raise

and maps this code to -signal.SIGTERM:

    def wait(self, timeout=None):
        if self.returncode is None:
            if timeout is None:
                msecs = _winapi.INFINITE
            else:
                msecs = max(0, int(timeout * 1000 + 0.5))

            res = _winapi.WaitForSingleObject(int(self._handle), msecs)
            if res == _winapi.WAIT_OBJECT_0:
                code = _winapi.GetExitCodeProcess(self._handle)
                if code == TERMINATE:
                    code = -signal.SIGTERM
                self.returncode = code

        return self.returncode

I don't know why it doesn't simply use -SIGTERM instead of involving the intermediate error code. 

It's apparently trying to close a loop for scripts that call terminate() and look for this case, or for logging, but the platform convention in Windows doesn't allow distinguishing when a process was forcibly terminated. We don't know whether an exit status of 1 means the process failed internally or was forcibly terminated by another tool. So we can't rely on the exit code in Windows in the same way that it can be relied on in POSIX. All we know is that the process failed. Terminating with an exit code of 15 or -15 in some cases does nothing to solve the problem in general.