Additional logging on failures is always welcome.  Might I suggest that, in this case, regrtest treats this action as a hard fail so as to not got lost in the other transient failures (test_asyncio).

By that I mean, either to not re-run, or to still be "failed" even after a successful re-run as this test_concurrent mishap is rare enough that I doubt it would happen twice in one build.

Now for a brain dump.

The process tree at this time:

python.exe (buildbot)
. cmd.exe (test step)
.. python_d.exe (regrtest main)
... typepref.exe (load)
... <already terminated process>
.... typepref.exe (load for test_concurrent_futures)
.... python_d.exe (multiprocessing pool)
.... python_d.exe (multiprocessing pool)
.... python_d.exe (multiprocessing pool)
.... python_d.exe (multiprocessing pool)
.... python_d.exe (multiprocessing pool)


1. To see how process termination played out, I killed the main regrtest process.  This did not let the buildbot complete, but just sit there without any output.  Also the typepref.exe process (and the failed multiprocessing pool processes) still lingered.

2. I then terminated the children* of the already terminated process.  No change to the buildbot.

 [*] Windows doesn't really have the concept of a process tree

3. I then terminated the final typepref.exe process.  The buildbot finally finished its test step.

Given that typepref.exe also prevents completion, I believe the problem is in how we are spawning subprocesses.  Maybe a process handle is being inherited by the spawned processes preventing it from fully terminating?

I mention the process handle as it was listed as an open handle in Process Explorer for the regrtest process even though it had been terminated prior.