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

[Bug 24352] New: Virtual desktop does not respect modeless child window Z-order
by wine-bugs＠winehq.org July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=24352 Summary: Virtual desktop does not respect modeless child window Z-order Product: Wine Version: 1.3.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: multitude(a)internode.on.net 1. Run 'winecfg' and ensure the 'Graphics -> Emulate a virtual desktop' option is off. 2. Press the OK button to apply any changes and close 'winecfg'. 2. Run 'wine notepad' and search for text (Ctrl-F). 3. Leaving the 'Find' window open, mouse click the main 'Notepad' window. CORRECT RESULT: The 'Notepad' window becomes active, the 'Find' child window becomes inactive and remains in front of the main 'Notepad' window. 4. Exit 'notepad', run 'winecfg' and enable the 'Graphics -> Emulate a virtual desktop' option. 5. Press the OK button to apply the change and close 'winecfg'. 6. Run 'wine notepad' again and search for text (Ctrl-F). 7. Leaving the 'Find' window open, mouse click the main 'Notepad' window. INCORRECT RESULT: When the 'Notepad' window becomes active the 'Find' window disappears behind the 'Notepad' window. Confirmed in Wine 1.3.2 and Wine 1.2. Bug found when testing Chessmaster Grandmaster Edition. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 19

[Bug 59478] New: SolidWorks 2025: owner-drawn buttons inside large (10000x10000) child window receive WM_LBUTTONDOWN but BN_CLICKED is never sent
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59478 Bug ID: 59478 Summary: SolidWorks 2025: owner-drawn buttons inside large (10000x10000) child window receive WM_LBUTTONDOWN but BN_CLICKED is never sent Product: Wine Version: 11.0 Hardware: arm OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: junkwalkers(a)gmail.com Created attachment 80468 --> http://bugs.winehq.org/attachment.cgi?id=80468 Window hierarchy dump from inspector tool SolidWorks 2025 Education Edition hosts PropertyManager controls inside a child window titled "Dve sheet" sized 10000x10000 pixels. Owner-drawn buttons (BS_OWNERDRAW, style 0x5001000B) inside this window visually depress when clicked (WM_LBUTTONDOWN is delivered) but the BN_CLICKED notification (WM_COMMAND) is never sent to the parent window on mouse release. Steps to reproduce: 1. Install SolidWorks 2025 in a clean wineprefix 2. Open a part and enter sketch edit mode (e.g., draw a circle) 3. The PropertyManager sidebar displays controls inside a "Dve sheet" window (10000x10000) 4. Click any owner-drawn button: the confirm checkmark, cancel X, or circle type selectors Expected: Button fires its action (BN_CLICKED sent via WM_COMMAND to parent) Actual: Button visually depresses and releases but no action occurs Additional observations: - Standard buttons in normal-sized windows (Command Manager toolbar, viewport overlay buttons) work correctly - Text fields, dropdowns, and checkboxes in the same PropertyManager panel work - A custom window inspector confirms the buttons are BS_OWNERDRAW (style 0x5001000B) children of the "Dve sheet" window - Manually posting WM_COMMAND with BN_CLICKED to the button's parent via an external helper process makes the buttons function correctly, confirming the parent is listening for the notification This suggests the issue is in Wine's button control or mouse capture handling when the owning window has very large dimensions (10000x10000). Window hierarchy (from EnumChildWindows inspection): "Dve sheet" [AfxWnd140u] size=10000x10000 "Circle" [Button] style=0x5001000B size=242x24 ← broken "dvePage ScrollView" [AfxFrameOrView140u] size=243x798 [#32770] style=0x52000044 size=240x407 (various controls: buttons, checkboxes, labels) [Button] style=0x5001000B size=24x24 ← broken (confirm/cancel) System: macOS 26.3, Apple Silicon (M-series), Wine 11.0 stable, Rosetta 2 translation This may also affect the X11 driver — not tested. -- 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 59477] New: SolidWorks 2025: GDI-rendered child window (Feature Manager tree) invisible behind sibling OpenGL child window on macOS
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59477 Bug ID: 59477 Summary: SolidWorks 2025: GDI-rendered child window (Feature Manager tree) invisible behind sibling OpenGL child window on macOS Product: Wine Version: 11.0 Hardware: arm OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: junkwalkers(a)gmail.com Created attachment 80466 --> http://bugs.winehq.org/attachment.cgi?id=80466 Wine terminal output with WINEDEBUG=+win,+key showing F9 toggle for featuremanager SolidWorks 2025 Education Edition has a GDI-rendered Feature Manager tree panel (SysTreeView32) as a sibling child window to an OpenGL-rendered 3D viewport. On macOS with the winemac driver, the OpenGL content renders on top of the tree panel, making it completely invisible. The tree control is fully functional — items populate, right-click context menus work, selections register — but nothing is visible on screen. The tree becomes briefly visible when closing a document (OpenGL surface is destroyed) and a black rectangle appears in its place when dragging the document window. This appears to be the macOS equivalent of bug 2398 ("OpenGL is only used on top level windows so child windows get overdrawn"), which was fixed for the X11 driver in Wine 0.9.57. The Mac driver uses separate Core Animation layers for OpenGL surfaces, and these layers always render on top of GDI-rendered sibling windows regardless of WS_CLIPSIBLINGS. Steps to reproduce: 1. Install SolidWorks 2025 in a clean wineprefix on macOS (Apple Silicon via Rosetta 2). As the solidworks installer does not work this must be done manually either from the offline installer or from an existing installation. 2. Launch SolidWorks and open any part document 3. Observe that the left panel area (Feature Manager tree) is blank/invisible 4. Right-click the blank area — correct context menus appear, confirming the tree exists Expected: Tree panel visible alongside the 3D viewport, with viewport clipped by WS_CLIPSIBLINGS Actual: OpenGL viewport's CALayer covers the entire tree panel area Wine debug output (+win) shows: - Tree panel window uses parent surface (apply_window_pos reports surface 0x0 -> 0x0) - Viewport window rect (-1,150)-(1709,1090) overlaps tree at (0,150)-(240,1090) - Both windows receive paint messages and render correctly to their respective surfaces The OpenGLSurfaceMode registry setting partially confirms this: - "transparent": tree becomes visible when viewport is undocked, but opaque GL rendering still covers tree when docked - "behind": viewport becomes invisible (GL behind all content) System: macOS 26.3, Apple Silicon (M-series), Wine 11.0 stable, Rosetta 2 translation Attachments to include: - Wine terminal output with WINEDEBUG=+win,+key showing F9 toggle (attach as .txt.gz) - Screenshot showing blank tree area with working right-click menu -- 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 59825] New: focus tracking not quite correct when focus-follows-mouse
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59825 Bug ID: 59825 Summary: focus tracking not quite correct when focus-follows-mouse Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- This might be just a different variant of bug 57682, but till proven otherwise, I treat it as a separate problem. It might also just be an openbox specific issue. Anyway, getting to point. Window manager is set to focus-follows-mouse with focus delay of 800ms. As an example, I'm using two f2p games to demonstrate the problem, but simply cause it's easiest to show it with these two. The mentioned games are Unnamed Space Idle and Synergism (both in their Windows versions). USI is Godot, Synergism is Electron. After putting Synergism on top of the other in a cascade like manner, I'm able to do the following: I move the mouse cursor from outside of the windows through uncovered portion of USI window to the Synergism window quickly enough that focus delay doesn't raise USI window then stop there. Window manager gives the focus to Synergism window and that should be it... Yet, as I move mouse over the Synergism window, I can see that despite USI window not having focus, it displays mouse tooltips for the elements it hovers over, despite being mostly covered and technically unfocused. As USI doesn't have (IIRC) any 'trigger by hover' actions, in this case it's mostly cosmetic, but if it did, I strongly suspect it would be more than 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 1

[Bug 27419] New: Mouse problem in Heroes of Might and Magic 3
by wine-bugs＠winehq.org July 7, 2026

July 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=27419 Summary: Mouse problem in Heroes of Might and Magic 3 Product: Wine Version: 1.3.21 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: cdar07(a)gmail.com When I go into the castle, then fort and click on a unit picture, new window appear in which I can decide how many of those I want to buy. I click on the maximum button and nothing is happening. From that moment, mouse click is not working. Moving cursor is just fine, only click makes problems. Everything is ok on wine 1.3.5 from http://wine.budgetdedicated.com/archive/binary/. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 50

[Bug 59967] New: Delete account
by WineHQ Bugzilla July 7, 2026

July 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=59967 Bug ID: 59967 Summary: Delete account Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: ovari123(a)zoho.com Target Milestone: --- Distribution: --- Please delete this account on all winehq.org sites. For example, bugs.winehq.org and WineHQ AppDB appdb.winehq.org. Thank you -- 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 52556] New: Dragon's Lair 3D page fault when starting the game
by WineHQ Bugzilla July 7, 2026

July 7, 2026

https://bugs.winehq.org/show_bug.cgi?id=52556 Bug ID: 52556 Summary: Dragon's Lair 3D page fault when starting the game Product: Wine Version: 7.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: matej.pivec93(a)gmail.com Distribution: --- Created attachment 71870 --> https://bugs.winehq.org/attachment.cgi?id=71870 Highly compressed WINEDEBUG dumps and the page fault report Dragon's Lair 3D is a 2002 game. Interestingly, it uses OpenGL natively. In any case, the game seems to crash on boot with a page fault: 0160:err:ole:CoUninitialize Mismatched CoUninitialize wine: Unhandled page fault on read access to 0060A000 at address 100548ED (thread 0134), starting debugger... According to WineHQ reports, the last reported working version was in the Wine 1.x era. Unfortunately, running the game with WINEDEBUG=+relay won't produce the same error, the game silently exits in this case. I have added these dumps regardless, they might help you. I tried figuring out which part of wine is problematic myself, but I'm just not versed enough in the WINAPI C stuff. I remember trying to run this throughout the wine 4.x-7.x versions, but I always get the same error. I also remember trying some native C libraries a while ago, but same result. I tried compiling ancient wine versions to see where the regression happened, but this proved too troublesome, since they require headers/packages not really provided by modern distributions anymore. Finally, I decided it is best to just report this bug. My setup: Arch Linux Ryzen 3600X 32GB RAM AMD RX590 In the attachment I have added these dumps: -WINEDEBUG=+loaddll,+relay,+seh,+tid -WINEDEBUG=+all -The wine page fault report I can provide other dumps or try some things other things if you want as well. An interesting observation is running this game in a 64-bit prefix will produce a secdrv loading error. Same thing with a 32-bit WIN98 prefix. A 32-bit Windows XP prefix does NOT produce this error, however (this is the version I used to make these reports). -- 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 1

[Bug 55149] New: Nancy Drew: Danger by Design exits on game start
by WineHQ Bugzilla July 7, 2026

July 7, 2026

https://bugs.winehq.org/show_bug.cgi?id=55149 Bug ID: 55149 Summary: Nancy Drew: Danger by Design exits on game start Product: Wine Version: 8.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tiger12506(a)gmail.com Distribution: --- Created attachment 74715 --> https://bugs.winehq.org/attachment.cgi?id=74715 warn+all,+seh,+ddraw Nancy Drew: Danger By Design is 2 disc cd game. I have ISOs created from original discs that I am installing from. Setup.exe works fine -- I choose to change the install location to C:\ND\DangerbyDesign\ because previous attempts to run game from the default location result in it looking for a CIFTree file in the C:\ND\DangerbyDesign directory. That's not the issue. When installed correctly, the game appears to start, the screen goes black, resolution changes to the game's chosen 640x480, and then the game quits (leaving my linux desktop resolution in 640x480 mode). This is the issue. I assume this is a crash, but I either haven't found, or don't understand the outputs of the WINEDEBUG logs well enough to diagnose the issue. Any way that I can help you help me would be appreciated. -- 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 59965] New: x11drv UI elements become unclickable after switching windows due to unexpected WM_CANCELMODE during mouse grab
by WineHQ Bugzilla July 7, 2026

July 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=59965 Bug ID: 59965 Summary: x11drv UI elements become unclickable after switching windows due to unexpected WM_CANCELMODE during mouse grab Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com CC: julliard(a)winehq.org, rbernon(a)codeweavers.com Target Milestone: --- Distribution: --- When switching focus between applications via Alt+Tab, the application's buttons and UI elements sometimes become completely unresponsive to mouse clicks. Steps to Reproduce (occurs from time to time): Open an application. Interact with the UI (e.g., click down on a scrollbar, a custom button, or start a drag operation). While the application is in this state, switch focus to another window (Alt+Tab). Switch back to the affected application. Sometimes the bug occurs. Actual Results: The UI ignores mouse clicks. The application is not frozen (it might still respond to keyboard input), but the internal mouse capture/UI state is broken. Workaround: The only way to restore mouse functionality is to minimize the affected window, switch to another app, and then restore the window. Minimizing forces a hard state reset and ReleaseCapture, while restoring forces a full WM_PAINT. This fixes the unclickable UI. Expected Results: Switching windows should not permanently break the application's internal mouse capture or UI state machine. Buttons should remain clickable after returning to the application. Technical Details & Proposed Fix: The issue occurs because winex11.drv sends a WM_CANCELMODE message to the foreground window when it loses focus, even if the application currently holds an X11 mouse grab (x11drv_thread_data()->grab_hwnd). This causes a desync: the application resets its internal state (cancels menus/captures due to WM_CANCELMODE), but the X11-level grab might persist or the app's internal framework gets stuck in a transitional state. Skipping WM_CANCELMODE when a mouse grab is active completely resolves the issue. Here is the patch that fixes the bug: diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c --- a/dlls/winex11.drv/event.c +++ b/dlls/winex11.drv/event.c @@ -888,5 +888,12 @@ if (hwnd != NtUserGetForegroundWindow()) return; if (!(NtUserGetWindowLongW( hwnd, GWL_STYLE ) & WS_MINIMIZE)) - send_message( hwnd, WM_CANCELMODE, 0, 0 ); + { + if (x11drv_thread_data()->grab_hwnd) + { + TRACE("Skipping WM_CANCELMODE, mouse is grabbed by %p.\n", x11drv_thread_data()->grab_hwnd); + } + else + send_message( hwnd, WM_CANCELMODE, 0, 0 ); + } This is the same root cause as here (fix is the same): https://bugs.winehq.org/show_bug.cgi?id=59653 -- 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 51432] New: DXVA Checker 4.x (.NET 4.x app) needs DXVAHD_CreateDevice
by WineHQ Bugzilla July 7, 2026

July 7, 2026

https://bugs.winehq.org/show_bug.cgi?id=51432 Bug ID: 51432 Summary: DXVA Checker 4.x (.NET 4.x app) needs DXVAHD_CreateDevice Product: Wine Version: 6.12 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dxva2 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation of bug 35921 Prerequisite: * 32-bit WINEPREFIX (WINEARCH=win32) to work around regression * 'winetricks -q dotnet462' --- snip --- 0148:Call KERNEL32.WideCharToMultiByte(00000000,00000000,021b5ae4 L"DXVAHD_CreateDevice",00000013,0021eb14,00000015,00000000,00000000) ret=79a94936 0148:Ret KERNEL32.WideCharToMultiByte() retval=00000013 ret=79a94936 0148:Call KERNEL32.GetProcAddress(1ff00000,0021eb14 "DXVAHD_CreateDevice") ret=06346611 0148:Ret KERNEL32.GetProcAddress() retval=00000000 ret=06346611 0148:Call KERNEL32.WideCharToMultiByte(00000000,00000000,021b5b48 L"DXVAHD_CreateDeviceW",00000014,0021eb14,00000016,00000000,00000000) ret=79a94936 0148:Ret KERNEL32.WideCharToMultiByte() retval=00000014 ret=79a94936 0148:Call KERNEL32.GetProcAddress(1ff00000,0021eb14 "DXVAHD_CreateDeviceW") ret=06346611 0148:Ret KERNEL32.GetProcAddress() retval=00000000 ret=06346611 ... 0148:trace:seh:dispatch_exception code=e0434352 flags=1 addr=7B0102F8 ip=7b0102f8 tid=0148 0148:trace:seh:dispatch_exception info[0]=80004003 0148:trace:seh:dispatch_exception info[1]=00000000 0148:trace:seh:dispatch_exception info[2]=00000000 0148:trace:seh:dispatch_exception info[3]=00000000 0148:trace:seh:dispatch_exception info[4]=014f0000 0148:warn:seh:dispatch_exception unknown exception (code=e0434352) raised 0148:trace:seh:dispatch_exception eax=0021e994 ebx=00000005 ecx=0021ea8c edx=0021ea90 esi=00000005 edi=0021ea00 0148:trace:seh:dispatch_exception ebp=0021e9e8 esp=0021e994 cs=7bc50023 ds=21002b es=7bc3002b fs=210063 gs=006b flags=00200212 0148:trace:seh:call_vectored_handlers calling handler at 016A0430 code=e0434352 flags=1 ... 0148:Call user32.MessageBoxW(00020076,021b7690 L"GetDXVAHDProcessorDeviceError\r\nValue cannot be null.\r\nParameter name: ptr",02155618 L"DXVA Checker",00000010) ret=05681e44 --- snip --- Microsoft docs: https://docs.microsoft.com/en-us/windows/win32/api/dxvahd/nf-dxvahd-dxvahd_… Wine source: https://source.winehq.org/git/wine.git/blob/d10887b8f56792ebcca717ccc28a289… (spec file doesn't list it) $ sha1sum DXVAChecker_4.5.2.zip 358542765adae8e05aa66676ba82402077e655e4 DXVAChecker_4.5.2.zip $ du -sh DXVAChecker_4.5.2.zip 1.2M DXVAChecker_4.5.2.zip $ wine --version wine-6.12-162-gd10887b8f56 Regards -- 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 2