This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients William.Schwartz, eryksun, ncoghlan, paul.moore, steve.dower, tim.golden, zach.ware
Date 2021-01-18.23:22:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 4. In console A, type the PID from console B and execute the command.

In Windows, os.kill() is a rather confused function. In particular, it confuses a process ID (pid) with a process group ID (pgid). If the signal is CTRL_C_EVENT or CTRL_BREAK_EVENT, it first tries WinAPI GenerateConsoleCtrlEvent(). This function takes a pgid for a process group in the console session. Passing it a pid of a process in the console session that's not a pgid has undefined behavior (usually it acts like passing 0 as the pgid, but it's complicated; I have an open issue on Microsoft's GitHub repo for this that's been languishing for a couple years). Passing it a pid of a process that's not in the console session will fail as an invalid parameter. 

In the latter case, os.kill() sets an error but still tries the regular pid (not pgid) path of OpenProcess() and TerminateProcess(). If the latter succeeds, it returns success. However, it doesn't clear the error that was set as a result of the GenerateConsoleCtrlEvent() call, which causes SystemError to be raised.

>  Oddly, `echo %errorlevel%` will print `0` rather than `-1073741510` 

There's nothing odd about that. The value of CTRL_C_EVENT is 0. GenerateConsoleCtrlEvent() does not work across different console sessions. So os.kill() has simply opened a handle to the process and called TerminateProcess(handle, 0).
Date User Action Args
2021-01-18 23:22:48eryksunsetrecipients: + eryksun, paul.moore, ncoghlan, tim.golden, zach.ware, William.Schwartz, steve.dower
2021-01-18 23:22:48eryksunsetmessageid: <>
2021-01-18 23:22:48eryksunlinkissue42962 messages
2021-01-18 23:22:48eryksuncreate