http://bugs.winehq.org/show_bug.cgi?id=55705 --- Comment #20 from Filip Řeháček <filip.rehacek@outlook.cz> --- I can confirm this bug and provide a working workaround, with log evidence. Affected software: PDF-XChange Editor 11.1.0.0 under Wine 11.19, AUR package pdf-xchange. Crash sequence captured in a 216k-line debug log (log available on request): after roughly 40 minutes of use the app dies with: 0120:err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 0454:err:rpc:RpcAssoc_BindConnection receive failed with error 1726 0024:err:sync:RtlpWaitForCriticalSection ... rpc_server.c: server_cs ... blocked by 012c, retrying (60 sec) 0024:err:sync:RtlpWaitForCriticalSection ... combase/rpc.c: dcom registered server interfaces ... blocked by 012c ... 0024:err:seh:call_seh_handlers invalid frame ... 0024:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception. This is the same "wait handle count 65" failure described in bug 60334: WaitForMultipleObjectsEx only accepts MAXIMUM_WAIT_OBJECTS (64) handles, once more than 63 named-pipe listeners are registered on one protseq the wait fails with error 87. RPCRT4_server_thread() then shuts down, a thread holds server_cs / "dcom registered server interfaces" forever, and every COM marshaling call deadlocks until the main thread dies. Workaround attached: wait on the listeners in chunks of at most 64 handles and cycle through them, instead of letting the wait overflow and kill the RPC server thread. Confirmed stable over long sessions; no change in behavior when under 64 listeners. Some earlier workarounds in this thread touched the io_status.Status check in the same function; on current wine that check already handles STATUS_PIPE_CONNECTED, so the remaining bug is the wait-handle overflow. Please consider this as a confirmation + working workaround. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.