As developed in a long thread starting at http://mail.zope.org/pipermail/zope/2005-July/160433.html there appears to be a race bug in the Microsoft Windows socket implementation, rarely visible (but disastrously when so) when multiple processes try to create an "asyncore trigger" simultaneously. Unfortunately, the relevant code appears to have originated in Medusa, and then got copy/paste'd all over creation. ZEO's copy is in ZEO/zrpc/trigger.py, and I've fixed it for ZODBs 3.2.10, 3.4.1 and 3.5. Zope-2_7-branch is using a 3.2.10 pre-release now, but no other version of Zope has stitched in a repaired ZODB yet. The original Medusa code appears to be in lib/python/ZServer/medusa/thread/select_trigger.py I've repaired that in CVS Zope-2_7-branch, and am in the process of repairing the same file in SVN Zope trunk and SVN Zope 2.8 branch. SVN Zope trunk and Zope 2.8 branch appear to inherit yet a 3rd copy of this code, in their lib/python/zope/server/trigger.py which appears to come from an older Zope3 snapshot. Zope3 trunk does not appear to contain any Medusa code (at least not under that name), but does contain zope/server/trigger.py which appears more to be a copy of an older version of ZEO's trigger.py than of Medusa's select_trigger.py. The short course here is that I'm repairing all but only the copies of this code that do _not_ appear in anybody's zope/server/trigger.py That file appears to have been introduced in Zope3, and I've lost track of which branches of Zope3 are still active now. I'll open a Zope3 collector issue on this, and will be happy to help repair it, but because I spend most of my Zope time trying to help Zopes 2.7 and 2.8 along, those are the only Zope versions where I'm confident about changing the right stuff in the right places. I'll repair Zope3 trunk's zope/server/trigger.py unless someone can tell me it's no longer used, but someone else will have to port that change to the still-active Zope3 branches (including the one(s) used by Zope 2.8 and Zope trunk).