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

[Bug 54176] New: Vegas pro 16
by WineHQ Bugzilla Oct. 11, 2026

Oct. 11, 2026

https://bugs.winehq.org/show_bug.cgi?id=54176 Bug ID: 54176 Summary: Vegas pro 16 Product: Wine Version: 7.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bochtabochta(a)gmail.com Distribution: --- Created attachment 73699 --> https://bugs.winehq.org/attachment.cgi?id=73699 BackTrace of crash Vegas pro 16 crashes at launch when loading i/o file manager -- 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 46716] New: utherverse client : crash when loading and installing
by wine-bugs＠winehq.org Oct. 11, 2026

Oct. 11, 2026

https://bugs.winehq.org/show_bug.cgi?id=46716 Bug ID: 46716 Summary: utherverse client : crash when loading and installing Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: www.max87(a)yahoo.fr Distribution: --- Created attachment 63684 --> https://bugs.winehq.org/attachment.cgi?id=63684 report generate by wine on the crash When i lunch the application client Uhterverse i got a bug report from wine and the loading of the client is stopped I tryed a reinstall of the client and it done the same a bug appared but the installation finished -- 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 5

[Bug 33985] New: Nokia Music Player: window decorations should not be displayed in installer window
by wine-bugs＠winehq.org Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=33985 Bug #: 33985 Summary: Nokia Music Player: window decorations should not be displayed in installer window Product: Wine Version: 1.6-rc4 Platform: x86-64 URL: http://nds1.nokia.com/files/support/nseries/phones/sof tware/SetupOviPlayer.exe OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: frederic.delanoy(a)gmail.com Classification: Unclassified Created attachment 45154 --> http://bugs.winehq.org/attachment.cgi?id=45154 WinXP/wine-1.6-rc4-52-g9a0b434 side-by-side comparison The windows decorations (here from XFCE 4.10) are present in Wine while they aren't in native Windows. See attached screenshot for a comparison -- 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.

2 9

[Bug 55336] New: Touhou 6 : Full-screen with Alt-tabbing or using DXVK breaks inputs
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

https://bugs.winehq.org/show_bug.cgi?id=55336 Bug ID: 55336 Summary: Touhou 6 : Full-screen with Alt-tabbing or using DXVK breaks inputs Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: riyu12383(a)gmail.com Distribution: --- -The Game Here is a very small demo version of the game from archive.org https://archive.org/compress/KoumaTr013/formats=ARCHIVE%20BITTORRENT,METADA… To launch this version, you'll need to add Japanese locale like this : LANG=ja_JP.UTF-8 wine 東方紅魔郷.exe -The bug When launching the game in Full-screen and Alt-Tabbing or using DXVK, the game inputs breaks, its scrolls the menu infinitely or quit the game by itself, the user can't control anything anymore. On the demo version it seems the user only loose the control. Interestingly on Windows, since Windows 10, the game has an exaggerated speed/framerate in full-screen. Which was fixed using this dx8 to dx9 converter : http://enbdev.com/convertor_dx8_dx9_v0036.htm However this doesn't change anything with wine. I originally discovered this bug here : https://github.com/AlpyneDreams/d8vk/issues/155 -- 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 29

[Bug 60059] New: Lock-key state (CapsLock/NumLock) oscillates on every keystroke when any global WH_KEYBOARD_LL hook exists — adjust_lock_state defeated by its own deferred synthetic events
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60059 Bug ID: 60059 Summary: Lock-key state (CapsLock/NumLock) oscillates on every keystroke when any global WH_KEYBOARD_LL hook exists — adjust_lock_state defeated by its own deferred synthetic events Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: me(a)papayadev.net Target Milestone: --- Distribution: --- Created attachment 81552 --> http://bugs.winehq.org/attachment.cgi?id=81552 minimal reproducer: pass-through global WH_KEYBOARD_LL + lock-state logging (modes: control/hook/eat) winex11's lock-key reconciliation defeats itself whenever any global WH_KEYBOARD_LL hook exists on the desktop, permanently corrupting the desktop-wide CapsLock/NumLock toggle state on every keystroke, for every process in the prefix. Mechanism, current git (byte-identical from wine-11.10 through master): update_lock_state (dlls/winex11.drv/keyboard.c:1472, called from X11DRV_KeyEvent for every X key event) detects a toggle mismatch against the X event state mask and calls adjust_lock_state (keyboard.c:1452), which sends a synthetic lock-key down+up via NtUserSendHardwareInput and immediately re-reads NtUserGetAsyncKeyboardState to detect whether a keyboard hook blocked the change. But with a global WH_KEYBOARD_LL present, the server defers the keystate commit until the hook thread replies: queue_keyboard_message only calls queue_hardware_message — which contains the sole keystate update, update_desktop_key_state at server/queue.c:1859 — after the LL hook result arrives (queue.c:2489, send_hook_ll_message; commit on reply in store_message_result). And the driver's send never waits for that: DECL_HANDLER(send_hardware_message) sets sender=NULL unless SEND_HWMSG_INJECTED (queue.c:3232, :3265), so hardware-origin sends are fire-and-forget. The immediate re-read in adjust_lock_state is therefore deterministically stale (in the common case the hook belongs to the app's main thread, which is currently inside X11DRV_KeyEvent and cannot possibly have processed the hook callback yet). The code then WARNs "keystate %x not changed, probably blocked by hooks" and force-writes the corrected toggle via set_async_key_state — the intended hook-defeat behavior — but the deferred synthetic KEYDOWN then passes the (non-blocking) hook, commits, and toggles the desktop-wide state right back (update_key_state, queue.c). The next real key event detects the mismatch again and the cycle repeats forever: with a seeded mismatch the lock toggles flip on every keystroke, visibly randomizing character case mid-line in any app on the desktop. A mismatch seed is trivial: start wineserver with physical NumLock ON (Wine's initial toggle is off), or toggle CapsLock while the Wine window is unfocused. Reproducer (attached, ditest3.c, plain user32/gdi32, i686-w64-mingw32-gcc -O2 -o ditest3.exe ditest3.c -luser32 -lgdi32): it installs a PASS-THROUGH global WH_KEYBOARD_LL (CallNextHookEx only) on its pumping thread, mimicking what many games do. With physical NumLock ON and a fresh wineserver: WINEDEBUG=-all,+key,+keyboard wine ditest3.exe hook, then type ~20 letters. Observed (wine 11.13, X11): 277 of 277 reconcile attempts fail with "probably blocked by hooks", "Adjusting NumLock state (0x40)" fires on every key event, GetKeyState(VK_NUMLOCK)&1 flips per keystroke, and after toggling CapsLock out of focus the typed text comes out with random per-character case ("the QuicK brown fox jumps Over the lazy dog"). Control run without the hook (ditest3.exe): the same mismatch converges silently after one keystroke, zero WARNs — confirming the LL hook deferral is the sole trigger. A third mode (ditest3.exe eat) has the hook genuinely eat (return 1) the lock-key events: the force-write then sticks and the state converges with exactly one WARN per genuine desync — i.e. the existing hook-defeat force-write works correctly whenever the events are truly blocked; only the delayed-but-not-blocked case breaks it. This is a regression introduced by cbc657a244d1 ("winex11.drv: Force changing lock keys state if hooks blocked keyboard input processing.", 2018). Before that commit, a correction deferred behind a non-blocking low-level hook simply committed late and converged one keystroke later. With it, the force-write plus the later deferred commit toggle the state twice per reconcile, sustaining the oscillation indefinitely. The case that commit was written for — a hook genuinely blocking lock keys — still needs the force-write, so a plain revert is not the fix either; the problem is that the "did the state change" check cannot distinguish blocked from deferred. Real-world impact: Final Fantasy XI installs such a global WH_KEYBOARD_LL, and one running instance permanently corrupts Caps/NumLock behavior for every Wine process in the prefix (randomly flipping character case while typing). Any app with a global LL keyboard hook should trigger the same. Suggested fix directions: commit the keystate change of driver-origin lock-key corrections before/independently of the LL-hook round trip; or have adjust_lock_state skip the synthetic events and only force-write when a global WH_KEYBOARD_LL is present; or make the "did it change" check wait for / account for the deferred commit rather than misreading deferral as blocking. Related but distinct existing reports (checked 2026-07-24, none cover this defect): bug 35907 (caps state confused across processes — thread-vs-async state propagation, 2014 analysis predating the adjust_lock_state force-write; no LL hook involved, no per-keystroke oscillation) ; bug 59888 (numlock changes only detected while focused — the mismatch-seeding condition, not the oscillation; reconciliation-on-next-key is expected, this report is about the reconcile then un-doing itself); bug 57958 (adjust_lock_state falsely triggering while physically HOLDING CapsLock with the toggle on — a trigger-condition bug in the same function, no hook required; open MR !11315 addresses only that trigger condition and does not touch the LL-hook deferral). The control run (no hook: converges silently in one keystroke) isolates this report from all three. -- 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 15

[Bug 52254] New: Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea)
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

https://bugs.winehq.org/show_bug.cgi?id=52254 Bug ID: 52254 Summary: Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea) Product: Wine Version: 7.0-rc2 Hardware: x86-64 URL: https://zerofield.net/2020/09/30/hajimari-no-kiseki-sp readsheet-translation/ OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwmapi Assignee: wine-bugs(a)winehq.org Reporter: johnny(a)localmomentum.net Distribution: --- Created attachment 71376 --> https://bugs.winehq.org/attachment.cgi?id=71376 ColdSteelSubs transparency code (currently not in the distributed application) This application provides a transparent clickthrough overlay to show English translations on top of the original Japanese source. It relies on layered windows and DwmExtendFrameIntoClientArea to handle the transparent display. Currently, the main UI elements show, but the game (or any other application) does not show through. This seems to be because DwmExtendFrameIntoClientArea is only a stub. I'm not sure if that's the only reason it's not transparent, but it's at least one of the reasons. The program itself uses the unity3d engine along with some native dll calls to the relevant user32 apis to handle the transparency. I was able to get a copy of the relevant code (but not the whole application), of which I will attach. Since I can't get all of the code, I've been using an unity sample application to try to figure out some parts myself (the relevant code is here https://github.com/pheonise/Unity3D-Desktop-Overlay/blob/master/Assets/Scri…) This unity3d application works as expected on windows, but is not transparent via wine (as expected). When i comment the call to DwmExtendFrameIntoClientArea, then it its also no longer transparent on windows as well. It seems that if the sample application works, then I can make sure the dev applies to the same technique to the overlay application. Please let me know If i can provide any more information. -- 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 19

[Bug 58878] New: Norwegian version of "Who Wants To Be A Millionaire" did not works
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=58878 Bug ID: 58878 Summary: Norwegian version of "Who Wants To Be A Millionaire" did not works Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lars_martin4(a)hotmail.com Distribution: --- larsmartinhambro(a)fedora-linux:~/.wine/drive_c/Program Files (x86)/Eidos Interactive/HotHouse Creations/Vil Du Bli Millionær$ dir BINKW32.DLL Data Game.exe SMACKW32.DLL Viktig.rtf larsmartinhambro(a)fedora-linux:~/.wine/drive_c/Program Files (x86)/Eidos Interactive/HotHouse Creations/Vil Du Bli Millionær$ wine Game.exe 002c:fixme:winediag:loader_init wine-staging 10.15 is a testing version containing experimental patches. 002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. 0090:err:environ:init_peb starting L"C:\\Program Files (x86)\\HDD Health\\HDDHealthService.exe" in experimental wow64 mode 0090:fixme:heap:RtlSetHeapInformation HEAP_INFORMATION_CLASS 1 not implemented! 00c8:err:environ:init_peb starting L"C:\\Program Files (x86)\\ASUS\\AXSP\\4.00.38\\atkexComSvc.exe" in experimental wow64 mode 00c8:fixme:ole:CoInitializeSecurity 00000000, -1, 00000000, 00000000, 6, 3, 00000000, 2, 00000000 stub 00c8:fixme:wbemprox:client_security_SetBlanket 79273934, 00C145B8, 10, 0, (null), 4, 3, 00000000, 0 00c8:fixme:wbemprox:client_security_Release 79273934 00c8:fixme:wbemprox:client_security_Release 79273934 00c8:fixme:wbemprox:wbem_services_CreateInstanceEnum unsupported flags 0x10 wine: Unhandled page fault on read access to 00000000 at address 793A43CD (thread 00c8), starting debugger... 00d0:err:environ:init_peb starting L"C:\\windows\\syswow64\\winedbg.exe" in experimental wow64 mode 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0070:err:ole:start_rpcss Failed to start RpcSs service 00e4:err:ole:start_rpcss Failed to start RpcSs service 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0070:err:ole:start_rpcss Failed to start RpcSs service 003c:err:service:process_send_start_message service L"asComSvc" failed to start 003c:fixme:service:scmdatabase_autostart_services Auto-start service L"asComSvc" failed to start: 1053 0100:err:environ:init_peb starting L"C:\\windows\\syswow64\\winedevice.exe" in experimental wow64 mode 010c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\win32k.sys" 010c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgkrnl.sys" 010c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgmms1.sys" 0108:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\SecDrv": c0000142 003c:fixme:service:scmdatabase_autostart_services Auto-start service L"SecDrv" failed to start: 1114 014c:err:environ:init_peb starting L"C:\\Program Files (x86)\\Electronic Arts\\Medal of Honor Airborne\\UnrealEngine3\\MOHAGame\\pb\\PnkBstrA.exe" in experimental wow64 mode 0024:fixme:winediag:loader_init wine-staging 10.15 is a testing version containing experimental patches. 0024:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. 01e4:err:environ:init_peb starting L"C:\\Program Files (x86)\\Eidos Interactive\\HotHouse Creations\\Vil Du Bli Million\00e6r\\Game.exe" in experimental wow64 mode 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0204:err:environ:init_peb starting L"C:\\users\\larsmartinhambro\\AppData\\Local\\Temp\\~ef7194.tmp" in experimental wow64 mode 0210:err:environ:init_peb starting L"C:\\windows\\syswow64\\winedevice.exe" in experimental wow64 mode 021c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\win32k.sys" 021c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgkrnl.sys" 021c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgmms1.sys" 0218:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\SecDrv": c0000142 larsmartinhambro(a)fedora-linux:~/.wine/drive_c/Program Files (x86)/Eidos Interactive/HotHouse Creations/Vil Du Bli Millionær$ 0224:fixme:winediag:loader_init wine-staging 10.15 is a testing version containing experimental patches. 0224:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. -- 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 29

[Bug 59901] New: Nintendo Switch Pro Controller is forced as a DirectInput device
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=59901 Bug ID: 59901 Summary: Nintendo Switch Pro Controller is forced as a DirectInput device Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- The Nintendo Switch Pro Controller in USB mode (idVendor=057e, idProduct=2009, bcdDevice= 2.00) gets forced into being a DirectInput device on all subsequent prefix launches after the first one when it is plugged in. I.e. When the controller is first detected by a prefix, it's detected correctly as a xinput controller, but after that initial detection done by the prefix, all subsequent launches of that prefix force it into being a DirectInput device. xinput will report no connected controllers to apps, but the "Game Controllers" control panel applet will still show it's button presses on the xinput tab, and all others. The Joysticks tab claims it's DirectInput. Attempting to reset the pro controller back to xinput fails. (The reset button on the joysicks tab doesn't do anything.) Deleting the prefix and recreating it forces wine back into the initial detection behavior, but exiting and relaunching the prefix causes the bug to occur again. Pulling up regedit shows nothing in HKCU\Software\Wine\DirectInput or HKCU\Software\Wine\DirectInput\Joysticks. Looking under HKCU\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput shows a key with the controller's VID and PID. (Along with \calibration\0 subkeys.) Deleting the key with the controller's VID and PID, exiting and relaunching the prefix makes wine redetect the controller as xinput again, but the registry key gets recreated and the bug occurs again on subsequent prefix launches. So it appears the existence of this key overrides the xinput controller to DirectInput, but wine's Control Panel applet cannot reset it. Nor is it possible to keep it as a xinput device. -- 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 16

[Bug 59751] New: WizTree 4.30: Dropdown menu fails to redraw hovered items with active visual style
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59751 Bug ID: 59751 Summary: WizTree 4.30: Dropdown menu fails to redraw hovered items with active visual style 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 80933 --> http://bugs.winehq.org/attachment.cgi?id=80933 Dropdown menu screenshot https://diskanalyzer.com/files/archive/wiztree_4_30_setup.exe WizTree 4.30 download link Dropdown menu fails to redraw hovered items with active visual style of WizTree -- 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 43991] New: Window disappears while changing applications
by wine-bugs＠winehq.org Oct. 8, 2026

Oct. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=43991 Bug ID: 43991 Summary: Window disappears while changing applications Product: Wine Version: 2.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: anonymous.maarten(a)gmail.com Distribution: --- Hey, When changing applications using ALT+TAB or using the WIN key in Gnome 3, the window of this application disappears. It is thus impossible to go to this application using ALT+TAB. Gnome is running on Wayland (if that would matter). Application name: RW Analyze 0.4 Beta URL: http://www.steve-m.com/downloads/tools/rwanalyze/ $ wine --version wine-2.19 (Staging) $ cat /etc/fedora-release Fedora release 26 (Twenty Six) $ sha1sum RWAnalyze.exe 43504ea98322c97311318373050ffa33b30671ca RWAnalyze.exe $ du -b RWAnalyze.exe 265728 RWAnalyze.exe -- 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 5