> Sorry, you're wrong: the proactor event loop heavily uses the _overlapped module which is implemented in C. A crash in the garbage collector is more likely a bug in asyncio/your application, than a bug in Python itself.

I'm aware of that. I assumed the original crash reported in this thread was the same as mine but I can't be sure of that. And that crash was on Linux, where asyncio is pure Python AFAIK.

> Please enable asyncio debug mode, ResourceWarning, enable DEBUG log level, and check if you get some errors. For example, "GetQueuedCompletionStatus() returned an unexpected event" usually means that you will quickly get a memory corruption...

I've already done that but admittedly not for very long because the server ran so slowly that it was unresponsive. I didn't see any error or warning messages, but I did see numerous "Executing <Handle _ProactorReadPipeTransport._loop_reading(<_OverlappedF...events.py:451>)" messages.

> Would it be possible to test again with fewer clients (500 clients or less to not hit the select() limit on Windows) with selector event loop?

I'll see if I can try that, but I guess reproducing the crash can take much longer with 500 clients.

> Can you check if asyncio.windows_events._BaseWaitHandleFuture is used? This class is used by IocpProactor.wait_for_handle() which is called by _WindowsSubprocessTransport. But you wrote you the server (where the crash occurs) doesn't run subprocesses.

It's not used. I put print statements and an exit() in the constructor of _BaseWaitHandleFuture and it wasn't triggered.

> Are you using asyncio code outside the main thread?

No.

> asyncio is not thread-safe at all :-p Are you using a single event loop or one event loop per thread?

A single event loop, and I've made sure that all code running outside the main thread doesn't call any asyncio functions.