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

[Bug 60206] New: SteelSeries GG 117.0 crashes on startup in .NET ABI.Windows.Storage.IApplicationDataMethods.get_LocalFolder
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60206 Bug ID: 60206 Summary: SteelSeries GG 117.0 crashes on startup in .NET ABI.Windows.Storage.IApplicationDataMethods.get_LocalF older Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: toadking(a)toadking.com Target Milestone: --- Distribution: --- Created attachment 81892 --> http://bugs.winehq.org/attachment.cgi?id=81892 Debug log Looks like it may be from the application_data_get_LocalFolder stub. -- 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 1

[Bug 58075] New: DATE A LIVE: Rio Reincarnation: Problem with imm32
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

https://bugs.winehq.org/show_bug.cgi?id=58075 Bug ID: 58075 Summary: DATE A LIVE: Rio Reincarnation: Problem with imm32 Product: Wine Version: unspecified Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: imm32 Assignee: wine-bugs(a)winehq.org Reporter: Alexander88207(a)Protonmail.com Created attachment 78334 --> https://bugs.winehq.org/attachment.cgi?id=78334 Error-and-winedebug-log Hello, when i start the game then a tiny window opens and resizes very quickly a few times and then stays tiny and black with an separate error message. When trying to interact with the black window then it jumps to the right corner of the screen, unless the error message is touched again. However i do suspect imm32 as in the wine debug logs there is mentioned: fixme:imm:ime_ui_window_proc hwnd 000A00C0, himc 000900C2, msg WM_IME_CONTROL, wparam IMC_CLOSESTATUSWINDOW, lparam 0 stub! With that hint i did did override imm32.dll with an native DLL and now the game works. Maybe useful: The game works in proton. -- 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 6

[Bug 60179] New: Regression (11.12 → 11.13): mouse clicks on a newly-shown owned/modal dialog are misrouted to the owner window, or silently fail to trigger the clicked control's notification
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60179 Bug ID: 60179 Summary: Regression (11.12 → 11.13): mouse clicks on a newly-shown owned/modal dialog are misrouted to the owner window, or silently fail to trigger the clicked control's notification Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: kahlil88mph(a)protonmail.com Target Milestone: --- Distribution: ArchLinux Created attachment 81843 --> http://bugs.winehq.org/attachment.cgi?id=81843 Trimmed WINEDEBUG traces Between Wine 11.12 and 11.13, mouse click handling for a modal dialog shown on top of its owner window regressed. Two related but distinct symptoms are reproducible, both tied to the same window/owner relationship at the moment a new top-level dialog appears: 1. Clicks landing within the dialog's screen bounds are sometimes dispatched to a control on the **owner window underneath** instead of the dialog, even though the dialog is the window actually visible/topmost on screen. 2. When the click **does** reach the correct control (e.g. a "Close" button on the dialog), the button goes through a fully normal-looking `WM_LBUTTONDOWN → WM_SETFOCUS → WM_LBUTTONUP → WM_CAPTURECHANGED` sequence, but never sends the resulting `WM_COMMAND` (`BN_CLICKED`) notification to the dialog, so the click has no effect. Activating the same button via keyboard (Space bar) works every time, since that path skips whatever position check is failing on mouse-up. A user-discovered workaround: briefly "shading" and un-shading the dialog window (or resizing/maximizing-then-restoring the owner window) temporarily restores correct click behavior, consistent with a stale cached window rect/z-order being recalculated on any geometry-change event. Specifically, the program in question is Duplicate Cleaner Free 3.2.7 (DigitalVolcano Software) — a .NET WinForms application (owner-drawn buttons via `WM_DRAWITEM`, runs under wine-mono). Likely reproducible with any WinForms app that shows an owned dialog immediately after a background operation completes. -- 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 9

[Bug 4123] Picasa: "Open with..." menu item grayed out.
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=4123 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |0.9.52. -- 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 0

[Bug 60205] New: accept() sockets are unconditionally inheritable
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60205 Bug ID: 60205 Summary: accept() sockets are unconditionally inheritable Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)list.winehq.org Reporter: me(a)purplesyringa.moe Target Milestone: --- Distribution: --- In Wine, executing accept() on a socket always produces a socket with the inheritable flag set [1]. Windows behaves differently; from testing, the accepted socket is marked inheritable if and only if the listener socket was inheritable during the original WSASocket() invocation [2]. This affects e.g. all Rust programs due to a combination of two factors: Rust spawns child processes without an inheritance allowlist, and it doesn't explicitly make accepted sockets non-inheritable because SetHandleInformation doesn't work in UWP apps, and normally they're already non-inheritable so there's no need to do it anyway. Security implications aside, this can at least keep connections open for longer than intended in some programs, though I didn't look for any real-world victims. I'm not sure how comfortable Wine is with replicating undocumented behavior, but I'd assume in this case it's not baseless because Rust already implicitly makes this assumption. [1]: https://gitlab.winehq.org/wine/wine/-/blob/9306b8e8de4efe3a6035bc5df878e750… [2]: https://purplesyringa.moe/blog/accept-and-socket-inheritance/ -- 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 0

[Bug 60201] New: Implement SIO_AF_UNIX_GETPEERPID ioctl
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60201 Bug ID: 60201 Summary: Implement SIO_AF_UNIX_GETPEERPID ioctl Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: winsock Assignee: wine-bugs(a)list.winehq.org Reporter: me(a)purplesyringa.moe Target Milestone: --- Distribution: --- Windows allows programs to retrieve the PID of the other side connected to a Unix-domain socket with the SIO_AF_UNIX_GETPEERPID socket ioctl. This is roughly equivalent to getsockopt(SO_PEERCRED) on Unix. It'd be nice to see this ioctl implemented. I'm not exactly sure how this option behaves if the socket is transferred to another process, but as far as I can tell, Linux retains the old PID, and I'd assume Windows behaves similarly, since otherwise there is no correct answer if a socket handle is open in two processes at the same time. -- 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 55017] New: shell32:systray fails on gitlab-win10-21h2 (GitLab CI)
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

https://bugs.winehq.org/show_bug.cgi?id=55017 Bug ID: 55017 Summary: shell32:systray fails on gitlab-win10-21h2 (GitLab CI) Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com shell32:systray fails on gitlab-win10-21h2: systray.c:49: Test failed: NIM_ADD failed! systray.c:50: Test failed: GetLastError() = 2147500037 systray.c:75: Test failed: NIM_ADD failed! systray.c:76: Test failed: GetLastError() = 2147500037 See https://test.winehq.org/data/patterns.html#shell32:systray This failure only happens on gitlab-win10-21h2 and there is no obvious commit that could be causing it. Did something change in the GitLab CI VM? -- 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 4

[Bug 10506] New: wine crypt32 needs DSS provider to support more . NET apps which use cryptography API
by wine-bugs＠winehq.org Aug. 20, 2026

Aug. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=10506 Summary: wine crypt32 needs DSS provider to support more .NET apps which use cryptography API Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-crypt32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, while playing around with .NET apps I found various shortcomings when it comes to native backends for certains parts of .NET One is the state of cryptographic providers (crypt32). Many .NET apps use either default RSA or DSS provider. Currently the DSS and enhanced DSS provider are missing, resulting in failure of several .NET apps. Would be nice if wine gets DSS provider too. Trace log showing failure of typical .NET app trying to query DSS provider: --- snip --- trace:crypt:CryptAcquireContextW (0x33d6b8, (null), L"Microsoft Enhanced Cryptographic Provider v1.0", 1, f0000000) trace:crypt:RSAENH_CPAcquireContext (phProv=0x1771b8, pszContainer=(null), dwFlags=f0000000, pVTable=0x1771c8) trace:crypt:CryptReleaseContext (0x1771a8, 00000000) trace:crypt:RSAENH_CPReleaseContext (hProv=00000002, dwFlags=00000000) trace:crypt:CryptAcquireContextW (0x33d72c, (null), L"Microsoft Enhanced Cryptographic Provider v1.0", 1, f0000000) trace:crypt:RSAENH_CPAcquireContext (phProv=0x177450, pszContainer=(null), dwFlags=f0000000, pVTable=0x175f98) trace:crypt:CryptCreateHash (0x177440, 0x8004, 0x0, 00000000, 0x33d83c) trace:crypt:RSAENH_CPCreateHash (hProv=00000002, Algid=00008004, hKey=00000000, dwFlags=00000000, phHash=0x175e04) trace:crypt:CryptAcquireContextW (0x33d6f4, (null), (null), 13, f0000000) trace:crypt:CryptAcquireContextW Did not find registry entry of crypto provider for L"Software\\Microsoft\\Cryptography\\Defaults\\Provider Types\\Type 013". trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b841300 trace:seh:raise_exception info[0]=80090017 trace:seh:raise_exception eax=7b82c455 ebx=7b8ad1e4 ecx=00000000 edx=0033d348 esi=0033d348 edi=e0434f4d trace:seh:raise_exception ebp=0033d310 esp=0033d2ac cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00000212 --- snip --- resulting in CLR exception: --- snip --- Unhandled Exception: System.InvalidOperationException: An error occurred creating the form. See Exception.InnerException for details. The error is: The type initializer for 'Sunisoft.IrisSkin.SkinEngine' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Sunisoft.IrisSkin.SkinEngine' threw an exception. ---> System.Security.Cryptography.CryptographicException: Unknown error "-2146893801". at System.Security.Cryptography.CryptographicException.ThrowCryptogaphicException(Int32 hr) at System.Security.Cryptography.Utils._AcquireCSP(CspParameters param, SafeProvHandle& hProv) at System.Security.Cryptography.Utils.AcquireProvHandle(CspParameters parameters) at System.Security.Cryptography.Utils.get_StaticDssProvHandle() at System.Security.Cryptography.DSACryptoServiceProvider.ImportParameters(DSAParameters parameters) at System.Security.Cryptography.DSA.FromXmlString(String xmlString) at Sunisoft.IrisSkin.SkinEngine..cctor() --- snip --- Type 001 "RSA Full (Signature and Key Exchange)" and Type 012 "RSA SChannel" are currently implemented in wine Additionally needed: Type 003 "DSS Signature" (base DSS provider) Type 013 "DSS Signature with Diffie-Hellman Key Exchange" (enhanced DSS provider) Type 018 "Diffie-Hellman SChannel" (optional?) Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

3 31

[Bug 60202] New: Implement NtQueryInformationProcess(ProcessSequenceNumber)
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

http://bugs.winehq.org/show_bug.cgi?id=60202 Bug ID: 60202 Summary: Implement NtQueryInformationProcess(ProcessSequenceNumber) Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: me(a)purplesyringa.moe Target Milestone: --- Distribution: --- A process sequence number is a unique-per-boot monotonic ID not suffering from the issue of PID reuse. It's used by ProcessHacker [1], there is discussion about using it in Python psutil [2], and it's the only way to correctly handle PID use in presence of NTP adjustment [3]. There are two ways to obtain the sequence number: - NtQueryInformationProcess with ProcessSequenceNumber, which outputs a single 64-bit value. - NtQueryInformationProcess with ProcessTelemetryIdInformation, which outputs a structure containing it as one of the fields. The first approach is more recent, but looks smaller in scope, easier to implement, and immediately useful, so I'm only requesting it in this bug. [1]: https://github.com/winsiderss/systeminformer/issues/425#issuecomment-500168… [2]: https://github.com/giampaolo/psutil/issues/2702 [3]: https://community.osr.com/t/parent-process-information-error/50703/2 -- 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 1

[Bug 52568] New: Support for AF_UNIX is missing
by WineHQ Bugzilla Aug. 20, 2026

Aug. 20, 2026

https://bugs.winehq.org/show_bug.cgi?id=52568 Bug ID: 52568 Summary: Support for AF_UNIX is missing Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: ralf.habacker(a)freenet.de Distribution: --- Newer Windows 10 builds supports AF_UNIX, see https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ for details. There have been unfinished attempts to incorporate such support into wine, see https://www.winehq.org/pipermail/wine-devel/2021-May/187049.html. -- 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 18