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

[Bug 59708] New: d3d9: missing MSVC vtable byte-pattern
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59708 Bug ID: 59708 Summary: d3d9: missing MSVC vtable byte-pattern Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: danielginovker(a)gmail.com Distribution: --- Created attachment 80842 --> http://bugs.winehq.org/attachment.cgi?id=80842 Proposed patch (git format-patch). Adds an 18-byte MSVC-pattern marker after d3d9_device_vtbl in dlls/d3d9/device.c plus a conformance test in dlls/d3d9/tests/device.c. Wine's d3d9.dll is MinGW GCC-built and doesn't contain the MSVC C++ vtable-init byte sequence (c7 06 ?? 89 86 ?? 89 86) that some closed-source overlay/hook libraries scan for to locate the IDirect3DDevice9 vtable. Concrete affected case: bfmeladder.com's BFME Online Arena. Its dinput8.dll proxy fails to install hooks on Wine, so the Arena's 30-second Automated Matchmaking Test times out with "the overlay didn't load in 30 seconds." Repro: install https://bfmeladder.com/download under Wine staging, sign in, pick any game and patch, watch the test fail. Proposed patch attached: 18-byte packed const struct after d3d9_device_vtbl in .rdata, reproducing the pattern with &d3d9_device_vtbl as imm32. Not referenced by any Wine code. Conformance test included. -- 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 56281] New: String number converted to ascii value instead of parsed value
by WineHQ Bugzilla May 15, 2026

May 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=56281 Bug ID: 56281 Summary: String number converted to ascii value instead of parsed value Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: francisdb(a)gmail.com Distribution: --- > cat test.vbs Dim x x = "0" If IsNumeric(x) Then WScript.Echo "Numeric" Else WScript.Echo "Not Numeric" End If If x > 30 Then WScript.Echo "> 30" Else WScript.Echo "Not > 30" End If > wine cscript test.vbs 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 Numeric > 30 Windows > cscript test.vbs Microsoft (R) Windows Script Host Version 5.812 Copyright (C) Microsoft Corporation. All rights reserved. Numeric Not > 30 -- 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 53877] New: vbscript compile_assignment assertion when assigning multidimensional array by indices
by WineHQ Bugzilla May 15, 2026

May 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=53877 Bug ID: 53877 Summary: vbscript compile_assignment assertion when assigning multidimensional array by indices Product: Wine Version: 7.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: jsm174(a)gmail.com Distribution: --- The following works in real vbscript: Dim x Redim x(10) x(1) = Array(5, 6, 7) WScript.echo x(1)(0) WScript.echo x(1)(2) x(1)(0) = x(1)(2) WScript.echo x(1)(0) Output: 5 7 7 When running through Wine vbscript an assertion happens when processing x(1)(0) = x(1)(2) case EXPR_CALL: call_expr = (call_expression_t*)left; assert(call_expr->call_expr->type == EXPR_MEMBER); Stepping through the debugger, call_expr->call_expr->type appears to be EXPR_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.

2 7

[Bug 58925] New: GOM Player: UI elements not responding to mouse clicks
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=58925 Bug ID: 58925 Summary: GOM Player: UI elements not responding to mouse clicks Product: Wine Version: 10.18 Hardware: x86-64 URL: https://www.gomlab.com/en/gomplayer-media-player OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tobbi.bugs(a)googlemail.com Distribution: --- I installed GOM Player from the website mentioned. I noticed that the GOM Player is not responding to mouse clicks. Steps to reproduce: 1. Download GOM from https://www.gomlab.com/en/gomplayer-media-player (button Windows Download) 2. Install GOM using the downloaded .exe file. 3. Start GOM from C:/Program Files (x86)/GOM/GOMPlayer/GOMPlayer.exe 4. Notice how the program is not responding to any mouse clicks. % openssl sha256 GOMPLAYERGLOBALSETUP_NEW.EXE SHA2-256(GOMPLAYERGLOBALSETUP_NEW.EXE)= 841694b497b295b9f42d3f669828334cf59f582ff77f7a9e4b80f99ef084c9e7 % wine --version wine-10.18 I also notice that on first start, there's a "Close" button. Clicking that button somehow opens gomapp://close/ in Wine's Internet Explorer. I don't know if this is a separate bug or if the UI elements are unresponsive because of the non-dismissable message. -- 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 3

[Bug 59408] New: Ultimate Custom Night has severe performance issues
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59408 Bug ID: 59408 Summary: Ultimate Custom Night has severe performance issues Product: Wine Version: 11.2 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: afifsworld132(a)gmail.com Created attachment 80376 --> http://bugs.winehq.org/attachment.cgi?id=80376 Ultimate Custom Night logs macOS 14.1.1, Wine Staging 11.2 from Homebrew, Game is D3D9, Installed from Steam. The game barely reaches 10fps. Everything else seemingly works fine and game renders. -- 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 59543] New: Control Ultimate Edition renders a black screen in DX12 mode
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59543 Bug ID: 59543 Summary: Control Ultimate Edition renders a black screen in DX12 mode Product: vkd3d Version: 1.19 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: vkd3d-shader Assignee: wine-bugs(a)list.winehq.org Reporter: andrey.goosev(a)gmail.com CC: hverbeet(a)gmail.com Regression SHA1: 7bb268784e05a072ec82a7342952b713fefe7096 Distribution: --- Output message. Previously was also present. vkd3d:0228:fixme:spirv_compiler_emit_global_flags Unhandled global flags 0x100. -- 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 59555] New: Star Wars: Knights of the Old Republic - Rendering failure with active framebuffer effects
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59555 Bug ID: 59555 Summary: Star Wars: Knights of the Old Republic - Rendering failure with active framebuffer effects Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: accounts.winehq(a)vv221.fr Distribution: --- Up to WINE 10.0, framebuffer effects could be enabled in Star Wars: Knights of the Old Republic with no adverse effect on rendering. With WINE 11.5 it leads to a failure to render the game world (including any geometry, models, etc.). Text dialogues and other 2D interface pieces can be seen, with some heavy flickering effect. When trying to take a screenshot I only get a solid black image, even when text dialogue could be seen on the actual game screen. The actual gameplay seems to work fine, this is almost certainly only a rendering error. I have not tested other WINE builds yet, but I am going to do that to get a better idea of where the regression is hiding. -- 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 11

[Bug 59521] New: Ubisoft Connect shows a dark window after launching
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59521 Bug ID: 59521 Summary: Ubisoft Connect shows a dark window after launching Product: Wine Version: 10.16 Hardware: x86-64 URL: https://ubistatic3-a.akamaihd.net/orbit/launcher_insta ller/UbisoftConnectInstaller.exe OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: andrey.goosev(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: c78edbc06238c11744e86cf0c8ed704dda1b1dee Distribution: --- Step with initial login window after updates searching. -- 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 59673] New: Densha De Go! Professional 2 crashes on launch since commit 6048ac5dfeb
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59673 Bug ID: 59673 Summary: Densha De Go! Professional 2 crashes on launch since commit 6048ac5dfeb 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: duuqnd(a)stacken.kth.se Distribution: --- Created attachment 80764 --> http://bugs.winehq.org/attachment.cgi?id=80764 backtrace Since commit 6048ac5dfeb, found by performing a git bisect, the game Densha De Go! Professional 2 crashes on startup due to a NULL pointer dereference. I've attached a backtrace, though in previous commits it used to crash in a different function. The backtrace was made from a build compiled from the master branch as of 2026-04-18 (which happens to be tagged wine-11.7). As mentioned, the culprit is as far as I can tell the change introduced in commit 6048ac5dfeb, but I'll admit that I don't know why those changes were made nor why they cause the problem. They absolutely seem related though. It doesn't seem like it should be difficult to figure out for those who are familiar with that part of the code, but I could be wrong on that. -- 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 59519] New: ole32: OLE clipboard caches stale window handle after STA thread terminates, breaking subsequent OleSetClipboard calls
by WineHQ Bugzilla May 14, 2026

May 14, 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 4