The trace dumped is :

Traceback (most recent call last):
  File "C:\src\depot_tools\win_tools-2_7_6_bin\python\bin\lib\multiprocessing\util.py", line 268, in _run_finalizers
    finalizer()
  File "C:\src\depot_tools\win_tools-2_7_6_bin\python\bin\lib\multiprocessing\util.py", line 201, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "C:\src\depot_tools\win_tools-2_7_6_bin\python\bin\lib\multiprocessing\pool.py", line 500, in _terminate_pool
    p.terminate()
  File "C:\src\depot_tools\win_tools-2_7_6_bin\python\bin\lib\multiprocessing\process.py", line 137, in terminate
    self._popen.terminate()
  File "C:\src\depot_tools\win_tools-2_7_6_bin\python\bin\lib\multiprocessing\forking.py", line 312, in terminate
    _subprocess.TerminateProcess(int(self._handle), TERMINATE)
WindowsError: [Error 5] Access is denied


Looks like the issue is that p.terminate() in pool.py is racing with processes wrapping up on their own and therefore it's possible the process doesn't exist once it loops around to (and terminating an non-existing process results in "WindowsError: [Error 5] Access is denied").

IMO just need to ignore such errors when terminating processes (the process is already dead, as desired)

This happens after the upload is complete and therefore it still "works" but it's annoying because it feels like an error (and also hides potential real error messages).

I've also seen it prevent execution of -d flag (i.e. doesn't kick off dry-run).