[Bug 60334] New: Steam: UI stops responding after repeatedly launching games due to rpcrt4 wait handle limit
http://bugs.winehq.org/show_bug.cgi?id=60334 Bug ID: 60334 Summary: Steam: UI stops responding after repeatedly launching games due to rpcrt4 wait handle limit Product: Wine Version: 11.17 Hardware: x86-64 URL: https://cdn.akamai.steamstatic.com/client/installer/St eamSetup.exe OS: Linux Status: NEW Severity: normal Priority: P2 Component: rpc Assignee: wine-bugs@list.winehq.org Reporter: gyebro69@gmail.com Target Milestone: --- Distribution: ArchLinux *The analysis in this bug report was assisted by ChatGPT, and all results were verified through my own testing.* This may be related to bug #46871, which contains the same 'rpcrt4_protseq_np_wait_for_new_connection' error for a different application. I am filing this separately because the affected application, the user-visible failure and the reproduction steps are different and in this case I was able to confirm that the wait handle count reaches 65. I have been experiencing this bug for years with vanilla Wine as well, not just Wine-Staging. During the operation of the Windows Steam client, after launching and closing about 11–13 games consecutively, the Steam UI stops responding to left-clicks. In every instance, the following error appears in the terminal: 017c:err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 Interestingly, the top menu bar options can still be opened with the mouse, but none of the menu items can be clicked or activated. If the bug occurs while a game is currently running, the game itself is unaffected. However, after exiting the game, Steam continues to show the status as "Running" because the window no longer updates. No new game could be launched anymore because Steam became unresponsive. The only workaround at this point is to terminate the entire Wine environment along with Steam using the wineserver -k command. Restarting Steam/Wine resets the problem temporarily, but it returns after repeatedly launching and exiting games. Tested with wine-11.17-250-g14947569cf7. To reproduce: The Steam Overlay was disabled globally in the Steam client. I also disabled both GameOverlayRenderer.dll and GameOverlayRenderer64.dll through DLL overrides. I repeatedly launched and exited the same game, with only one game running at a time. After every exit, I waited 5–10 seconds for the game process to terminate completely and for Steam Cloud synchronization to finish. After exiting the game for the 13th time, the following error appeared and the Steam UI stopped responding: 33434.271:0020:017c:err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 I started Steam with: WINEDEBUG=-all,+pid,+timestamp,err+rpc \ WINEPREFIX=... wine steam.exe &> steam-rpc-error.log *Analysis* The process ID in the log is 0020. wine tasklist confirmed that Windows PID 32 (0x20) belongs to steam.exe, so the error is emitted by the main Steam process rather than by a game or steamwebhelper.exe. The number of steamwebhelper.exe processes did not increase after launching and exiting games. The game processes also terminated correctly. To determine the number of handles passed to WaitForMultipleObjectsEx(), I temporarily changed this line in dlls/rpcrt4/rpc_transport.c ERR("wait failed with error %ld\n", GetLastError()); to: ERR("wait failed with error %ld, wait handle count %u\n", GetLastError(), count); The resulting output was: 33434.271:0020:017c:err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87, wait handle count 65 The failure occurs when the RPC named-pipe wait array in steam.exe reaches 65 handles, exceeding MAXIMUM_WAIT_OBJECTS (64). Wine's rpcrt4_protseq_np_wait_for_new_connection() passes the complete array to a single WaitForMultipleObjectsEx() call, which then returns ERROR_INVALID_PARAMETER (87) This appears to be an accumulation of RPC named-pipe listeners in the long-running Steam process combined with Wine's inability to wait for more than 64 of them in this code path. Once the wait fails, the RPC server thread terminates and the Steam client becomes unusable. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60334 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60334 --- Comment #1 from mokopel352@limtu.com ---
err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87, wait handle count 65 I think you have found the root cause also of bug 55705. It looks like these two bugs are related. After changing the error reporting code as described, the same error message with the same wait handle count is the first error message to display when that bug begins to happen.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=60334 Alistair Leslie-Hughes <leslie_alistair@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com --- Comment #2 from Alistair Leslie-Hughes <leslie_alistair@hotmail.com> --- (In reply to Béla Gyebrószki from comment #0)
The failure occurs when the RPC named-pipe wait array in steam.exe reaches 65 handles, exceeding MAXIMUM_WAIT_OBJECTS (64). Wine's rpcrt4_protseq_np_wait_for_new_connection() passes the complete array to a single WaitForMultipleObjectsEx() call, which then returns ERROR_INVALID_PARAMETER (87) This appears to be an accumulation of RPC named-pipe listeners in the long-running Steam process combined with Wine's inability to wait for more than 64 of them in this code path. Once the wait fails, the RPC server thread terminates and the Steam client becomes unusable.
MSDN states that 64 is the limit for this function and suggest a workaround on the client side to use a thread for each block of 64 wait objects. This really just the result of something else going on or not. What's causing more named pipes to be created? Why aren't they being closed/reset/reused? Missing callback call? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60334 Filip Řeháček <filip.rehacek@outlook.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |filip.rehacek@outlook.cz --- Comment #3 from Filip Řeháček <filip.rehacek@outlook.cz> --- Cross-reference: I confirmed the same "wait failed with error 87" (64-handle limit, "wait handle count 65") failure on PDF-XChange Editor's in-process COM server - see bug 55705. Attached there is a chunked-wait workaround for rpcrt4_protseq_np_wait_for_new_connection that prevents the RPC server thread from shutting down. This affects any app registering many named-pipe listeners on one protseq, so it is likely also relevant for the Steam case here. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=60334 --- Comment #4 from Béla Gyebrószki <gyebro69@gmail.com> --- (In reply to Filip Řeháček from comment #3)
Cross-reference: I confirmed the same "wait failed with error 87" (64-handle limit, "wait handle count 65") failure on PDF-XChange Editor's in-process COM server - see bug 55705. Attached there is a chunked-wait workaround for rpcrt4_protseq_np_wait_for_new_connection that prevents the RPC server thread from shutting down. This affects any app registering many named-pipe listeners on one protseq, so it is likely also relevant for the Steam case here. I've tested the patch using the Steam client: during a single session lasting over an hour, I launched and closed different games at least 50 times and the freeze that used to happen consistently did not recur."
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=60334 --- Comment #5 from Béla Gyebrószki <gyebro69@gmail.com> --- (In reply to Alistair Leslie-Hughes from comment #2)
MSDN states that 64 is the limit for this function and suggest a workaround on the client side to use a thread for each block of 64 wait objects.
This really just the result of something else going on or not.
What's causing more named pipes to be created? Why aren't they being closed/reset/reused? Missing callback call? I investigated this locally with AI-assisted analysis. These observations are from tests I ran on my machine with Wine a15ee2ccf20.
The additional listeners correlate with temporary STA host apartments created for the DestinationList COM class (Jump Lists). In a five-launch/exit test, 24 such host apartments were created and destroyed. Their threads completed CoUninitialize and exited, but all 24 associated named-pipe listeners remained in the RPC wait array. Marshalling the hosted objects with MSHCTX_INPROC triggered endpoint registration. All 96 logged COM calls to these apartments selected Wine’s local window-dispatch path; no listener accepted a connection in the Steam process during that run. So the observed accumulation persists after apartment teardown, even though those pipe listeners were unused in this workload. I have not identified a missing callback or established what Windows does with the corresponding endpoints. As a local experiment, deferring pipe registration for in-process STA marshals prevented the accumulation. With the original rpcrt4 waiting code, 20 launch/exit cycles completed successfully and the wait array stayed at two handles: one listener and the manager event. This experiment has not validated general COM compatibility or subsequent cross-process proxy forwarding. Does this point to combase’s endpoint-registration/lifetime handling as the next place to investigate? -- 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.
participants (1)
-
WineHQ Bugzilla