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

[Bug 59757] New: SteelSeries GG 110.0 crashes on startup in .NET System.Security.Cryptography.X509Certificates.StorePal.Export
by WineHQ Bugzilla May 17, 2026

May 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=59757 Bug ID: 59757 Summary: SteelSeries GG 110.0 crashes on startup in .NET System.Security.Cryptography.X509Certificates.StorePal .Export Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: toadking(a)toadking.com Distribution: --- Created attachment 80951 --> http://bugs.winehq.org/attachment.cgi?id=80951 WINEDEBUG=trace+crypt trace Follow-up to bug 59746. A trace is attached. The crash seems to be inside crypt32.PFXExportCertStore/PFXExportCertStoreEx. -- 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 59756] New: Abiworld 2.9.4: Black background in menu's icons
by WineHQ Bugzilla May 17, 2026

May 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=59756 Bug ID: 59756 Summary: Abiworld 2.9.4: Black background in menu's icons Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Created attachment 80945 --> http://bugs.winehq.org/attachment.cgi?id=80945 screenshot Abiworld 2.9.4 from https://web.archive.org/web/20160630022900/http://www.nl.abisource.com/down… Black background in menu's icons (see screenshot) -- 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 59519] New: ole32: OLE clipboard caches stale window handle after STA thread terminates, breaking subsequent OleSetClipboard calls
by WineHQ Bugzilla May 17, 2026

May 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=59519 Bug ID: 59519 Summary: ole32: OLE clipboard caches stale window handle after STA thread terminates, breaking subsequent OleSetClipboard calls Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)list.winehq.org Reporter: ayourk(a)gmail.com Distribution: --- Created attachment 80543 --> http://bugs.winehq.org/attachment.cgi?id=80543 reproducer source This bug is really starting to bug me ;) so I figured it was time to report it and squash it! I know that in REAL Windows, this works fine, but as you can test from the attached sample app, the clipboard copy only really works once before the application has to be restarted for it to work again. OleSetClipboard fails with CLIPBRD_E_CANT_OPEN (0x800401D0) on the second and all subsequent calls when each call is made from a new STA thread and the main thread has OLE initialized. This pattern is used by .NET WinForms applications. Clipboard.SetText() internally spawns a new STA thread, calls OleSetClipboard, then exits the thread. The main thread keeps OLE initialized (.NET runtime), so OLE_moduleLockCount never drops to 0 and clipbrd_uninitialize() never runs on the copy threads. The cached clipboard window HWND from the first (now-dead) thread is never cleared. This is deterministic, not a race condition. 100% reproducible on Wine 9.0 through 11.0. I even tested it on the latest development branch. The buggy caching pattern has been present since the OLE clipboard was first implemented (commit 557ff419bea, July 18, 1999), so this affects every Wine version ever released. It went unnoticed because the trigger pattern (main thread keeps OLE alive + new STA threads for each clipboard operation) is specific to .NET WinForms applications. Affected application: Space Engineers (Steam App ID 244850) — Ctrl+C works once, then freezes for ~1 second on every subsequent Ctrl+C. The clipboard never updates past the first copy. This is also reported at https://github.com/ValveSoftware/Proton/issues/1792 STEPS TO REPRODUCE ================== Prerequisites: Main thread has OLE initialized (OleInitialize), as in any .NET application. 1. Spawn STA Thread A: OleInitialize(NULL) -> OleSetClipboard(NULL) -> OleSetClipboard(data1) -> OleFlushClipboard() -> OleUninitialize() -> thread exits Wait for Thread A to complete. 2. Paste: OpenClipboard(NULL) -> GetClipboardData(CF_TEXT) -> "first" Result: correct. 3. Spawn STA Thread B: OleInitialize(NULL) -> OleSetClipboard(NULL) Result: returns 0x800401D0 (CLIPBRD_E_CANT_OPEN) All 10 retries fail with the same error. 4. Paste: GetClipboardData(CF_TEXT) -> still "first" Expected: "second" 5. All subsequent copy attempts from new threads fail the same way. EXPECTED BEHAVIOR (Windows) =========================== Each copy succeeds immediately. After step 3, the clipboard contains "second". Tested on Windows 7, 10, and 11 -- all succeed. ACTUAL BEHAVIOR (Wine 9.0 through 11.0) ======================================== First copy succeeds. All subsequent copies fail with CLIPBRD_E_CANT_OPEN. The clipboard permanently retains the first copied text. Each failed copy takes ~1 second (10 retries x 100ms). ROOT CAUSE ========== In dlls/ole32/clipboard.c, get_clipbrd_window() caches a single HWND per process: static inline HRESULT get_clipbrd_window(ole_clipbrd *clipbrd, HWND *wnd) { if ( !clipbrd->window ) clipbrd->window = create_clipbrd_window(); *wnd = clipbrd->window; return *wnd ? S_OK : E_FAIL; } When the STA thread that created this window terminates, the window is destroyed but the stale HWND remains cached. clipbrd_uninitialize() (which clears it) only runs when OLE_moduleLockCount drops to 0, which never happens in a .NET app because the main thread keeps OLE alive. PROPOSED FIX ============ Add an IsWindow() check to get_clipbrd_window(): if ( clipbrd->window && !IsWindow(clipbrd->window) ) clipbrd->window = NULL; This detects the stale handle and forces creation of a fresh window on the current thread. Patch is attached. REPRODUCER ========== A standalone GUI test app is attached (clipboard_test.c + .exe). It has two modes: Mode A (Bug): Replicates the exact .NET OLE clipboard path. - Main thread calls OleInitialize (simulates .NET environment) - Each copy spawns a new STA thread: OleInitialize -> OleSetClipboard(NULL) -> OleSetClipboard(data) -> OleFlushClipboard -> OleUninitialize -> exit - 10-retry loop with 100ms delays (matches .NET Clipboard.SetText exactly) - Three copy/paste cycles with "first", "second", "third" - Copy 1 succeeds; Copy 2 and 3 fail with 0x800401D0 Mode B (Fix): Same OLE operations but manages the clipboard window lifetime correctly, demonstrating the fix works. - All three copies succeed. Build: x86_64-w64-mingw32-gcc -o clipboard_test.exe clipboard_test.c \ -lgdi32 -lole32 -luuid -mwindows Run: wine clipboard_test.exe Log output (clipboard_test.log) is attached showing the failure. -- 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 57473] New: Virtual DJ 2024: Main interface animation flickers
by WineHQ Bugzilla May 17, 2026

May 17, 2026

https://bugs.winehq.org/show_bug.cgi?id=57473 Bug ID: 57473 Summary: Virtual DJ 2024: Main interface animation flickers Product: Wine Version: 9.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: rizalmart98(a)gmail.com Distribution: --- The main interface was shaking and flickers The terminal shows this error message: 01f0:fixme:d2d:d2d_text_renderer_DrawGlyphRun Ignoring options 0x6. -- 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 9

[Bug 59710] New: Age of Empires II crashes on startup, has since version 5 of wine, continue in 8, 10, and 11 (latest). I will NOT allow you to #wontfix this, even if I have to FORCE you to address it. No matter WHAT the consequences. Zoomer fucking dipshits. Regressions
by WineHQ Bugzilla May 16, 2026

May 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59710 Bug ID: 59710 Summary: Age of Empires II crashes on startup, has since version 5 of wine, continue in 8, 10, and 11 (latest). I will NOT allow you to #wontfix this, even if I have to FORCE you to address it. No matter WHAT the consequences. Zoomer fucking dipshits. Regressions Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: xcrt3(a)bobmail.info Distribution: --- Created attachment 80846 --> http://bugs.winehq.org/attachment.cgi?id=80846 Age of Empires II crashes on startup Age of Empires II crashes on startup, has since version 5 of wine, continue in 8, 10, and 11 (latest). I will NOT allow you to #wontfix this, even if I have to FORCE you to address it. No matter WHAT the consequences. Zoomer fucking dipshits. Regressions -- 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 59709] New: Age of Empires II doesn't work (I will NOT allow you to "WONTFIX" this you fucking feminist pieces of SHIT
by WineHQ Bugzilla May 16, 2026

May 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59709 Bug ID: 59709 Summary: Age of Empires II doesn't work (I will NOT allow you to "WONTFIX" this you fucking feminist pieces of SHIT Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: xcrt2(a)mailinator.com Distribution: --- Age of Empires II doesn't work on: Wine 11, Wine 10 Wine 8, Wine 5, It just crashes You've made an enemy you fucking pieces of SHIT It used to work on 1.x https://bugs.winehq.org/show_bug.cgi?id=59701 -- 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 10

[Bug 55518] New: VelbusLink: terminates immediately after creating a window
by WineHQ Bugzilla May 16, 2026

May 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=55518 Bug ID: 55518 Summary: VelbusLink: terminates immediately after creating a window Product: Wine Version: 8.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winehq(a)kazlauskas.me Distribution: --- Created attachment 75080 --> https://bugs.winehq.org/attachment.cgi?id=75080 stdout/err of the failing command When launching the application, the application window will briefly flash and disappear as the application terminates. I made few attempts to catch the moment this happens with `winedbg` to no avail. I’m using wine-staging 8.14 to test it, although I’ve tried various versions including 8.0. To reproduce this issue: 1. Download an installer for VelbusLink: $ curl 'https://www.velleman.eu/downloads/velbus/velbuslink/velbuslink-10.8.6.0.exe' -Lo ~/Downloads/velbuslink-10.8.6.0.exe $ sha256sum ~/Downloads/velbuslink-10.8.6.0.exe 39630e960fe5be289232a6f2409c92ffe0c81e1794f166919aaffddf33eb9814 ~/Downloads/velbuslink-10.8.6.0.exe 2. Install it via: `wine ~/Downloads/velbuslink-10.8.6.0.exe '/VERYSILENT'` 3. Run `wine ~/.wine/drive_c/Program\ Files\ $x86$/Velbus/VelbusLink/VelbusLink.exe`. --- Side notes: * With Wine 8.0 the application fails with an assertion as seen in Bug 50282. In Wine 8.14, there is no assertion failure, but the application fails to launch regardles. * Some version of steam proton manages to run the application, but it is rendered incorrectly with the window frame/background appearing in front of the application contents, making application effectively 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.

2 6

[Bug 59705] New: Age of Empires II does not work with wine 8 on linux through lutris either.
by WineHQ Bugzilla May 16, 2026

May 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59705 Bug ID: 59705 Summary: Age of Empires II does not work with wine 8 on linux through lutris either. Product: Wine Version: 8.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: chaosesqueteam5(a)sogetthis.com Distribution: --- MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0 Monitored process exited. Initial process has exited (return code: 7424) All monitored processes have exited. Exit with returncode 7424 2026-04-29 02:42:42,606: Game still running (state: running) 2026-04-29 02:42:42,607: Stopping AoEIIattempt (wine) So I tried: Debian LTS wine 5x Mac OSX wine 10.1 and Lutris, Wine 8, debian. NONE work. THIS USED TO WORK THIS USED TO FKING WORK -- 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 59668] New: WCS-7300-U installs but crashes upon startup
by WineHQ Bugzilla May 16, 2026

May 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59668 Bug ID: 59668 Summary: WCS-7300-U installs but crashes upon startup Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: jimtinlin(a)gmail.com Distribution: --- Created attachment 80758 --> http://bugs.winehq.org/attachment.cgi?id=80758 trace file provided by wine after program crashes WCS-7300-U is programming software for the ICOM 7300 radio. The label says it works in Windows 8/8.1 or 10 (32 or 64 bit), Win 11. I tried using Windows 10, 11 in winecfg as well as 8.1, with no change in process. I contacted RTsystems troubleshooting for help and they said they don't provide help with Linux installation. Thanks! -- 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 17

[Bug 59723] New: SetSecurityInfo does not persist DACL changes
by WineHQ Bugzilla May 16, 2026

May 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59723 Bug ID: 59723 Summary: SetSecurityInfo does not persist DACL changes Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: joel(a)airwebreathe.org.uk Distribution: --- Created attachment 80869 --> http://bugs.winehq.org/attachment.cgi?id=80869 reproducer.c (Found by AI testing) `SetSecurityInfo()` reports `ERROR_SUCCESS` when called to replace a file's DACL, but the DACL is not actually modified. Reading the DACL back (via either `GetSecurityInfo()` or `GetNamedSecurityInfoW()`) returns the original unchanged DACL. This also affects `SetNamedSecurityInfoW()`. ## Impact on MSYS2 The MSYS2/Cygwin runtime implements `chmod()` by translating POSIX mode bits into Windows ACL entries and calling `NtSetSecurityObject()` (which `SetSecurityInfo` wraps). Because the DACL is never actually updated: - `chmod()` appears to succeed but has no effect - `stat()` reads back the original permissions, not the ones set - `access()` checks against the wrong permissions - `umask()` has no observable effect on file creation modes This is the root cause for at least 6 test failures in the MSYS2 test suite: | Test | Symptom | |------|---------| | chmod01 | `chmod(0000)` → `stat()` still shows 0444; all 8 mode changes fail | | stat02 | `stat()` reports wrong mode after `chmod()` | | access01 | `access(file, X_OK)` wrong result because permissions unchanged | | access05 | `access()` returns 0 instead of -1 for file with read removed | | umask03 | Created files have wrong mode — umask bits not applied via ACL | | unlink08 | Directory permission changes don't take effect (partial overlap) | ## Reproducer ``` x86_64-w64-mingw32-gcc -o reproducer.exe reproducer.c -ladvapi32 wine reproducer.exe ``` ### Expected output (real Windows) ``` --- Step 2: Set DACL to single ACE (owner read-only) --- PASS: SetEntriesInAcl (1 ACE, read-only) PASS: SetSecurityInfo (protected DACL) --- Step 3: Read back DACL via handle --- PASS: GetSecurityInfo (re-read) After SetSecurityInfo: 1 ACEs [0] type=0 flags=0x00 mask=0x00120089 sid=S-1-5-21-...-1000 PASS: DACL has exactly 1 ACE PASS: ACE[0] is ACCESS_ALLOWED PASS: ACE[0] mask includes FILE_GENERIC_READ PASS: ACE[0] mask does NOT include GENERIC_WRITE bits ``` ### Actual output (Wine 11.4) ``` --- Step 2: Set DACL to single ACE (owner read-only) --- PASS: SetEntriesInAcl (1 ACE, read-only) PASS: SetSecurityInfo (protected DACL) --- Step 3: Read back DACL via handle --- PASS: GetSecurityInfo (re-read) After SetSecurityInfo: 3 ACEs [0] type=0 flags=0x00 mask=0x001f01ff sid=S-1-5-18 [1] type=0 flags=0x00 mask=0x001f01ff sid=S-1-5-21-0-0-0-1000 [2] type=0 flags=0x00 mask=0x001200a9 sid=S-1-1-0 FAIL: DACL has exactly 1 ACE (GetLastError=0) ``` The DACL still has 3 ACEs with the original permissions after the set call. ## Environment - Wine: 11.4 - Host: Linux x86_64 - Filesystem: ext4 (via wineprefix) ## Analysis The bug is in Wine's implementation of `NtSetSecurityObject()` (or the `SetSecurityInfo()` / `SetNamedSecurityInfoW()` wrappers). The function accepts the new security descriptor without error but does not write the new DACL to the underlying file's extended attributes or other backing store that Wine uses for ACL persistence. -- 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