October 2026 - Wine-Bugs - list.winehq.org

[Bug 60334] New: Steam: UI stops responding after repeatedly launching games due to rpcrt4 wait handle limit
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

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(a)list.winehq.org Reporter: gyebro69(a)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.

1 6

[Bug 36958] New: Wine emulates file creation time instead of fetching it from the underlying filesystem
by wine-bugs＠winehq.org Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=36958 Bug ID: 36958 Summary: Wine emulates file creation time instead of fetching it from the underlying filesystem Product: Wine Version: 1.7.22 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P5 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: t.artem(a)mailcity.com Created attachment 49071 --> http://bugs.winehq.org/attachment.cgi?id=49071 Far2 showing file modification/creation/lass access times. In Linux at least ext4 supports file creation time field (crtime), but Wine doesn't use it. Instead it uses mtime. Please, implement crtime for filesystems which impelement this field. -- 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.

3 14

[Bug 57031] New: Mouse "tremble" in Robin Hood: The Legend of Sherwood (GoG).
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

https://bugs.winehq.org/show_bug.cgi?id=57031 Bug ID: 57031 Summary: Mouse "tremble" in Robin Hood: The Legend of Sherwood (GoG). Product: Wine-staging Version: 9.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: flaubertSt(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Installed GoG version of Robin Hood: The Legend of Sherwood. All works, but mouse tremble when in game (it DOESN'T with menu screens). Tried "mouse warp override -all options-but it didnt solve. Strangely, I changed from WINE-9.1-staging to 9.0 stable version and it doesn't tremble anymore, but now it has some lag when exit from pause: see Bug 39513). -- 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.

2 16

[Bug 60189] New: Built-in d3dx9 causes visual artifacts in Lego Star Wars 3 III (GoG version)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60189 Bug ID: 60189 Summary: Built-in d3dx9 causes visual artifacts in Lego Star Wars 3 III (GoG version) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: fcasas(a)codeweavers.com Target Milestone: --- Distribution: --- Created attachment 81874 --> http://bugs.winehq.org/attachment.cgi?id=81874 Screenshot with highlighted artifacts. Recent upstream vkd3d-shader updates allow the game shaders to compile correctly. However I noticed that updating Wine itself (on a Wine with custom vkd3d build) introduces small, previously unseen, visual artifacts. These artifacts consist in some flickering black stains that can be easily seen in the characters in the intro animation. They are easier to spot in motion but I attach a screenshot highlighting them. I ran a bisection and concluded that this bug is introduced in commit 306c3af83faca8bd384df24d370a863cab5ed394 d3dx9: No longer prefer native. So it might be considered a regression. -- 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.

1 8

[Bug 60487] New: wbemprox: Win32_Service lacks Description, PathName, StartName and ChangeStartMode()
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60487 Bug ID: 60487 Summary: wbemprox: Win32_Service lacks Description, PathName, StartName and ChangeStartMode() Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- Programs that manage Windows services through WMI (System.Management in .NET) fail: - reading Win32_Service.Description, .PathName or .StartName returns WBEM_E_NOT_FOUND (0x80041002); - invoking Win32_Service.ChangeStartMode returns WBEM_E_METHOD_NOT_IMPLEMENTED (0x80041055). Steps (.NET 4.8): foreach (ManagementObject s in new ManagementObjectSearcher( "SELECT * FROM Win32_Service WHERE Name='Spooler'").Get()) { Console.WriteLine(s["PathName"]); // 0x80041002 s.InvokeMethod("ChangeStartMode", new object[] { "Manual" }); // 0x80041055 } Suggested patch attached (tested on Wine 11.19, applies to master): - new columns Description (QueryServiceConfig2W(SERVICE_CONFIG_DESCRIPTION)), PathName (lpBinaryPathName) and StartName (lpServiceStartName, "LocalSystem" when empty, as Windows reports it); - new method ChangeStartMode(in StartMode, out ReturnValue) using ChangeServiceConfigW(); unknown mode returns 21, other errors go through map_error(). wbemprox conformance tests: unchanged (the one query failure seen is present without the patch too). Open points: Description costs an extra OpenService()+QueryServiceConfig2W() per service during table fill; Change(), DelayedAutoStart, ErrorControl, ExitCode etc. are still missing; no new tests yet. -- 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.

1 4

[Bug 60488] New: httpapi: only one URL per URL group, HttpWaitForDisconnectEx() unimplemented (HTTP Server API 2.0 servers fail)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60488 Bug ID: 60488 Summary: httpapi: only one URL per URL group, HttpWaitForDisconnectEx() unimplemented (HTTP Server API 2.0 servers fail) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: httpapi Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- Self-hosted HTTP servers built on HTTP Server API 2.0 (for example ASP.NET Core 1.x WebListener on .NET Framework 4.8) do not work: 1. A second HttpAddUrlToUrlGroup() on the same URL group returns ERROR_CALL_NOT_IMPLEMENTED, so a server listening on more than one prefix refuses to start. 2. HttpSetUrlGroupProperty(HttpServerTimeoutsProperty) returns ERROR_CALL_NOT_IMPLEMENTED (bug 49819); other tuning properties likewise. 3. HttpWaitForDisconnectEx() is only a spec-file stub; the server calls it for every request to build its "request aborted" token, the stub raises, and every request answers HTTP 500. HttpCancelHttpRequest(), HttpShutdownRequestQueue() and the Http*Query*Property() functions are missing as well. Suggested patch attached (tested on Wine 11.19, applies to master): - URL groups keep an array of (URL, context) and add/remove/bind all of them; - HttpSetUrlGroupProperty / HttpSetServerSessionProperty / HttpSetRequestQueueProperty: FIXME and succeed for properties that only tune behaviour; - HttpWaitForDisconnect(Ex): semi-stub - with OVERLAPPED return ERROR_IO_PENDING and never complete, otherwise ERROR_NOT_SUPPORTED; - HttpCancelHttpRequest / HttpShutdownRequestQueue: stubs returning success; Http*Query*Property: stubs returning ERROR_CALL_NOT_IMPLEMENTED; - removes 7 todo_wine in tests/httpapi.c that now pass (additional invalid/duplicate URLs in a group return the same errors as on Windows). httpapi tests: 0 todo, 0 failures on i386 and x86_64. This is a suggestion, not upstream-ready: a real HttpWaitForDisconnectEx() needs an http.sys IOCTL that completes when the connection closes (the semi-stub leaves one pending operation per connection until the queue closes); silently accepting properties may hide differences; the 32-URL array is arbitrary. -- 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.

1 2

[Bug 60486] New: crypt32: PFXExportCertStoreEx() and PFXImportCertStore() do not support ECDSA (CNG) keys
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60486 Bug ID: 60486 Summary: crypt32: PFXExportCertStoreEx() and PFXImportCertStore() do not support ECDSA (CNG) keys Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- Exporting or importing a PFX whose private key is an ECDSA key fails. 1. Export: X509Certificate2.Export(X509ContentType.Pfx) in .NET Framework 4.8 for a certificate with a CNG ECDSA P-256 key crashes. PFXExportCertStoreEx() always asks NCrypt for BCRYPT_RSAFULLPRIVATE_BLOB, which ends in bcrypt's RSA export code with an EC key (page fault inside the RSA key accessor). 2. Import: new X509Certificate2(pfxBytes, password, flags) with an EC key fails with CRYPT_E_BAD_ENCODE (0x80092002). The unix side (open_cert_store) rejects every key that is not GNUTLS_PK_RSA, and the PE side only knows how to import RSA keys into a CAPI provider. Steps (any .NET 4.8 program, 32- or 64-bit): var ec = ECDsa.Create(ECCurve.NamedCurves.nistP256); var req = new CertificateRequest("CN=test", ec, HashAlgorithmName.SHA256); var cert = req.CreateSelfSigned(DateTimeOffset.Now, DateTimeOffset.Now.AddYears(1)); var pfx = cert.Export(X509ContentType.Pfx, "pw"); // crash var back = new X509Certificate2(pfx, "pw", X509KeyStorageFlags.Exportable); // 0x80092002 (CreateSelfSigned itself needs the ncrypt changes from bug 60443.) A suggested patch is attached (tested on Wine 11.19, applies to master too): - PFXExportCertStoreEx(): read NCRYPT_ALGORITHM_GROUP_PROPERTY and export BCRYPT_ECCPRIVATE_BLOB for ECDSA/ECDH; unix export_cert_store builds the key with gnutls_x509_privkey_import_ecc_raw(GNUTLS_ECC_CURVE_SECP256R1). - open_cert_store accepts GNUTLS_PK_ECDSA; import returns a BCRYPT_ECCPRIVATE_BLOB built with gnutls_x509_privkey_export_ecc_raw(). - PFXImportCertStore(): ECC blobs are imported with NCryptOpenStorageProvider(MS_KEY_STORAGE_PROVIDER) + NCryptImportKey() and attached with CERT_NCRYPT_KEY_HANDLE_PROP_ID plus a CNG CERT_KEY_PROV_INFO, so HasPrivateKey is true and CryptAcquireCertificatePrivateKey() returns the NCrypt handle. RSA keeps the existing CAPI path. With it, export/import round trip and signing with the imported key work (32- and 64-bit); crypt32 conformance tests are unchanged. Limitations, why this is a suggestion rather than a finished patch: P-256 only; the CERT_KEY_PROV_INFO names a container that does not exist (Wine has no persisted NCrypt keys); PKCS12_ALWAYS_CNG_KSP is still ignored; no new tests yet. Possibly related: bug 59038. -- 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.

1 3

[Bug 60489] New: http.sys: responses larger than 4 MiB are truncated (short send() on non-blocking socket ignored)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60489 Bug ID: 60489 Summary: http.sys: responses larger than 4 MiB are truncated (short send() on non-blocking socket ignored) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: httpapi Assignee: wine-bugs(a)list.winehq.org Reporter: mailtomendoza(a)gmail.com Target Milestone: --- Distribution: --- With HttpSendHttpResponse()/HttpSendResponseEntityBody(), responses larger than about 4 MiB arrive truncated: Content-Length is correct but the body stops at exactly 4,194,304 bytes and the client waits until it times out. Cause: the connection socket in http.sys is non-blocking (WSAEventSelect()), and http_send_response() does a single send() and ignores a short write. Suggested patch attached (tested on Wine 11.19, applies to master): loop until the whole buffer is sent; on WSAEWOULDBLOCK wait with select() (30 s) and continue; on timeout or error fail as before. With it a 4.4 MB file is served completely. Open point: the wait happens while holding http_cs, so a slow client can stall the other connections for up to the timeout. A cleaner design would queue unsent data on the connection and resume on FD_WRITE before completing the IRP. No new test yet (suggestion: send a several-MiB response and check the received length). -- 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.

1 5

[Bug 60473] New: ncrypt: NCryptEncrypt rejects NCRYPT_PAD_OAEP_FLAG (NTE_NOT_SUPPORTED), NCryptDecrypt is a stub
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60473 Bug ID: 60473 Summary: ncrypt: NCryptEncrypt rejects NCRYPT_PAD_OAEP_FLAG (NTE_NOT_SUPPORTED), NCryptDecrypt is a stub Product: Wine Version: 11.19 Hardware: x86-64 URL: https://github.com/re-codesys/codesys-wine OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bcrypt Assignee: wine-bugs(a)list.winehq.org Reporter: strucc.c(a)gmail.com Target Milestone: --- Distribution: Debian Symptom: Recent versions of CODESYS IDE are using encrypted communication to the Gateway and PLC devices. On WINE however, initiating online connection fails with Unknown error "-2146893783". Affected application: CODESYS V3.5 SP22 Patch 4 (64-bit, .NET Framework 4.8; installer "CODESYS 64 3.5.22.40.exe") Download: https://store.codesys.com/en/codesys.html Description On Windows11 NCryptEncrypt with an RSA key and NCRYPT_PAD_OAEP_FLAG (0x4) encrypts with RSA-OAEP. In WINE NCryptEncrypt rejects the flag with NTE_NOT_SUPPORTED (0x80090029), and NCryptDecrypt is a stub that fails the same way, so RSA-OAEP through the CNG key storage API is not usable. Trace (WINEDEBUG=+ncrypt): trace:ncrypt:NCryptImportKey (..., L"RSAPUBLICBLOB", ..., 283, 0) trace:ncrypt:NCryptEncrypt (..., 60, ..., 0x4) fixme:ncrypt:NCryptEncrypt No padding and oaep padding not supported Code: dlls/ncrypt/main.c (wine-11.19, same on master) Bcrypt handles RSA-OAEP since 11.5 (https://bugs.winehq.org/show_bug.cgi?id=58342) so ncrypt seems to lack only the pass-through of the OAEP padding information (BCRYPT_OAEP_PADDING_INFO) to BCryptEncrypt and BCryptDecrypt. Additional information See: https://github.com/Re-CODESYS/codesys-wine for details. -- 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.

1 4

[Bug 60474] New: shell32: IShellLinkDataList::RemoveDataBlock is a stub (E_NOTIMPL)
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60474 Bug ID: 60474 Summary: shell32: IShellLinkDataList::RemoveDataBlock is a stub (E_NOTIMPL) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs(a)list.winehq.org Reporter: strucc.c(a)gmail.com Target Milestone: --- Distribution: Debian Symptom: Programs that build a shortcut through IShellLink and then remove one of its data blocks fail with "The method or operation is not implemented" (.NET: NotImplementedException from IShellLinkDataList.RemoveDataBlock). Affected application: CODESYS V3.5 SP22 Patch 4. PackageManagerCLI.exe (3.5.22.40 Description: When package installer (PackageManagerCLI.exe) creates "Start menu" links for Executables from add-on packages, it's calling RemoveDataBlock(EXP_SZ_ICON_SIG) on each link. The package installation stops at the first link, or without --cancelOnException. The links are not created. On Windows IShellLinkDataList::RemoveDataBlock removes the extra data block with the given signature from the link (S_FALSE when there is none). In WINE it returns E_NOTIMPL. Trace (WINEDEBUG=fixme+shell): fixme:shell:ShellLink_RemoveDataBlock (...)->(2684354567): stub 2684354567 = 0xA0000007 (EXP_SZ_ICON_SIG). Code: dlls/shell32/shelllink.c Additional information, fix See: https://github.com/Re-CODESYS/codesys-wine for details. -- 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.

1 3