November 2025 - Wine-Bugs - list.winehq.org

[Bug 59063] New: Roblox Studio's place templates and child windows aren't rendering correctly under Vulkan
by WineHQ Bugzilla Dec. 3, 2025

Dec. 3, 2025

http://bugs.winehq.org/show_bug.cgi?id=59063 Bug ID: 59063 Summary: Roblox Studio's place templates and child windows aren't rendering correctly under Vulkan Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: eff3ctsb0t(a)gmail.com Distribution: --- Created attachment 79834 --> http://bugs.winehq.org/attachment.cgi?id=79834 Wine debugging log When using Roblox Studio's native Vulkan renderer, the place templates selection is pitch black (with the exception of the menu bar). Upon loading one of the place templates, you'll notice that most of the child windows are pitch black as well. Resizing one of these windows causes them to flicker rapidly. Steps to reproduce: 1. Create an account on roblox.com (this is required in order to be able to log into Roblox Studio, unfortunately). 2. Download the installer for Roblox Studio from the following link: https://setup.rbxcdn.com/RobloxStudioInstaller.exe Roblox Studio unfortunately autoupdates to the latest version, no matter what version of the installer is used, so this may present issues regarding reproducibility. 3. Create a desktop entry named "Roblox_Studio.desktop" with the following contents (again, this is required in order to be able to log into Roblox Studio). Replace <user> with the name of your user: [Desktop Entry] Name=Roblox Studio (modified) Exec=env "WINEPREFIX=/home/<user>/.wine" wine "C:\\\\users\\\\<user>\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Roblox\\\\Roblox Studio.lnk" %u Type=Application StartupNotify=true Icon=2C11_RobloxStudioBeta.0 StartupWMClass=robloxstudiobeta.exe MimeType=x-scheme-handler/roblox-studio-auth 4. Run the installer through Wine. This should also launch Roblox Studio itself once the installation is complete. If not, run the RobloxStudioBeta.exe executable that is located inside the Wineprefix. 5. Upon launching Roblox Studio, you will be greeted by an error prompting you to login via your browser. Click on the "Login via Browser" button, then click "Continue" on the newly spawned browser window. 6. Once you reached the place templates selection, click on the "File" menu on the top left, then on "Studio Settings" and then on "Rendering" in the newly spawned window, where you should change the "Graphics Mode" from "D3D11" to "Vulkan". After that, relaunch Studio. System Information: OS: Arch Linux x86_64 Kernel: Linux 6.17.9-arch1-1 Display Server: Wayland (Niri) GPU: AMD Radeon RX 6650 XT [Discrete] Driver: Mesa 25.2.7-1 257364eb5f671b2fd63507373b0427b519dfa71d was the commit that caused this bug to appear, so this is a regression. -- 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 7

[Bug 44840] New: Icewind Dale unusably glitchy starting with Wine Version 3.2
by wine-bugs＠winehq.org Dec. 3, 2025

Dec. 3, 2025

https://bugs.winehq.org/show_bug.cgi?id=44840 Bug ID: 44840 Summary: Icewind Dale unusably glitchy starting with Wine Version 3.2 Product: Wine Version: 3.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: wodencafe(a)gmail.com Distribution: --- Starting with Wine 3.2 and on, Icewind Dale (2.0.0.11 (GOG)) is having very strange input / glitchy rendering issues. I have attached a video comparison with 3.1 where it works fine. Tested with 3.2, 3.3, and 3.4, and all have the strange input and glitchy problem. There are no additional wine modifications. Please see the video for example of problem, and comparison of when it was working with 3.1 -- 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 21

[Bug 59015] New: Battle.net client fails to start games (e.g. Starcraft Remastered)
by WineHQ Bugzilla Dec. 2, 2025

Dec. 2, 2025

http://bugs.winehq.org/show_bug.cgi?id=59015 Bug ID: 59015 Summary: Battle.net client fails to start games (e.g. Starcraft Remastered) Product: Wine-staging Version: 10.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: zculek(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 79754 --> http://bugs.winehq.org/attachment.cgi?id=79754 Relevant crash logs Environment: - Hardware: Lenovo Thinkbook 15p G2 (Core i5-1235U, Intel GPU) - OS: Linux Mint 21.3 Cinnamon (Linux kernel 5.15.0-161-generic) - Wine: wine-staging 10.19 - Application: Battle.net client/launcher 2.49.4.15928 Issue: Battle.net client fails to start games, e.g. Starcraft Remastered. Expected behavior: Game should start normally when clicking on Play button. Actual behavior: The game doesn't start (crashes) due to error: 04b0:err:module:loader_init "ClientSdk.dll" failed to initialize, aborting 04b0:err:module:loader_init Initializing dlls for L"C:\\Program Files (x86)\\StarCraft\\x86_64\\StarCraft.exe" failed, status c0000094 Additional notes: - Reverting to wine-staging 10.18 resolves this issue, so it looks to be a regression. - This already happened at least once - https://bugs.winehq.org/show_bug.cgi?id=49525 - with wine-staging 5.12, so could be the same regression. Please let me know if any additional info is needed. -- 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 59016] New: Directdraw games get black screen
by WineHQ Bugzilla Dec. 2, 2025

Dec. 2, 2025

http://bugs.winehq.org/show_bug.cgi?id=59016 Bug ID: 59016 Summary: Directdraw games get black screen Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: i(a)xuzhao.net Distribution: --- Created attachment 79755 --> http://bugs.winehq.org/attachment.cgi?id=79755 Black screen, with directdraw render method Hi Wine Community, I want to ask about a regression I observed on my desktop (openSUSE Tumbleweed, KDE, NVIDIA 3080 Ti). A few old Japanese Galgames have blackscreen starting from a few months ago. To be specific, I am running Ebenbourg no Kaze (by Studio e-go!). The game screen is black, but with `WINEDEBUG=+ddraw` I can see logs being printed out: https://pastebin.com/s5m0i3AK I am testing on other applications, e.g., VisualBoyAdvance (the GameBoyAdvance simulator). I found that when I switch the render method to "DirectDraw" it shows black screen, but when I switch to "GDI", "OpenGL" or "Direct3D", the screen is normal. I have tried changing [HKCU/Wine/Direct3D] -> "renderer" from "gl" to "gdi", but the game/application will crash/black screen. I suspect there is a regression in DirectDraw support in Wine. -- 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 59049] New: When navigating through the wine file explorer via Clip Studio Paint Pro 4.0.3 after pressing File>Open>.. the Explorer is only able to see Clip Studio made .psd files.
by WineHQ Bugzilla Dec. 2, 2025

Dec. 2, 2025

http://bugs.winehq.org/show_bug.cgi?id=59049 Bug ID: 59049 Summary: When navigating through the wine file explorer via Clip Studio Paint Pro 4.0.3 after pressing File>Open>.. the Explorer is only able to see Clip Studio made .psd files. Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: n96rom(a)gmail.com Distribution: --- Created attachment 79820 --> http://bugs.winehq.org/attachment.cgi?id=79820 Screenshot of Wine File Explorer unable to see other available psd files than "Illustration". I followed this guide: https://appdb.winehq.org/objectManager.php?sClass=version&iId=42586 It worked. I am able to use every other functionality of CS. However, the wine file system does not detect any other .psd files except the ones I have created in CS. To navigate I used File>Open> and then it opens up wine's file explorer. I am not sure how to change it to Dolphin which is the file explorer used on my OS, PikaOS 4 but it cant see the files. -- 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 59060] New: Movie Maker msi does not open
by WineHQ Bugzilla Dec. 1, 2025

Dec. 1, 2025

http://bugs.winehq.org/show_bug.cgi?id=59060 Bug ID: 59060 Summary: Movie Maker msi does not open Product: Wine Version: 10.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)list.winehq.org Reporter: passymas(a)gmail.com Distribution: --- Created attachment 79830 --> http://bugs.winehq.org/attachment.cgi?id=79830 error movie maker msi Movie Maker msi does not open. -- 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

[Bug 57588] New: Guardant USB key drivers: grdkey.sys crashes
by WineHQ Bugzilla Dec. 1, 2025

Dec. 1, 2025

https://bugs.winehq.org/show_bug.cgi?id=57588 Bug ID: 57588 Summary: Guardant USB key drivers: grdkey.sys crashes Product: Wine Version: 10.0-rc3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: amorozov(a)etersoft.ru Distribution: --- Created attachment 77697 --> https://bugs.winehq.org/attachment.cgi?id=77697 Log with WINEDEBUG=+ntoskrnl,+plugplay and winedbg output I installed Guardant USB key drivers 7.0.224 from here: https://www.guardant.com/support/users/download/2238/ with WoW64 Wine build. $ md5sum GrdDrivers.exe 731d388d2ee4c1a4f45d655e4b8c9163 GrdDrivers.exe After installation windows/system32/drivers/grdkey.sys appears. And it crashes at Wine start: wine: Unhandled page fault on read access to 0000000000000008 at address 00006FFFFC8A295B (thread 00f0), starting debugger... In AddDevice handler grdkey.sys calls IoOpenDeviceRegistryKey. This results in calling get_device_instance_id -> get_device_id and sending IRP_MJ_PNP/IRP_MN_QUERY_ID with BusQueryDeviceID to the driver which calls IofCallDriver(NULL, ....) and crashes. The crash can be avoided with commenting out this line: device = IoGetAttachedDevice( device ); in get_device_id function in dlls/ntoskrnl.exe/pnp.c But I assume that the correct fix should be in avoiding to send IRPs from IoOpenDeviceRegistryKey. MSDN says that IRP_MN_QUERY_ID is sent before loading driver and calling AddDevice: https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/adding-a-… -- 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 59065] New: 32-bit foobar2000 crashes when you play files
by WineHQ Bugzilla Dec. 1, 2025

Dec. 1, 2025

http://bugs.winehq.org/show_bug.cgi?id=59065 Bug ID: 59065 Summary: 32-bit foobar2000 crashes when you play files Product: Wine-staging Version: 10.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: just4steam778(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 79838 --> http://bugs.winehq.org/attachment.cgi?id=79838 Log 32-bit foobar2000 crashes when you try to play files. 64-bit foobar2000 works fine. OS: Arch Linux -- 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 30853] New: Wine doesn’t always handle "right alt" properly
by wine-bugs＠winehq.org Dec. 1, 2025

Dec. 1, 2025

http://bugs.winehq.org/show_bug.cgi?id=30853 Bug #: 30853 Summary: Wine doesn’t always handle "right alt" properly Product: Wine Version: 1.5.5 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: sloonz(a)gmail.com Classification: Unclassified Created attachment 40410 --> http://bugs.winehq.org/attachment.cgi?id=40410 workaround/quick and dirty fix I’m trying to get World of Warcraft working under Wine. However, I have huge trouble with key bindings (I use unusual key bindings : I use the right half of my keyboard, whereas most players use the left half). After investigation, I found 3 bugs (different behaviors between Wine and my Windows installation). The first one is the management of the right "Alt" key (labeled "Alt-Gr" on my keyboard). When I press AltGr+l under Windows with Spy++, I get the followings events : <03637> 0007045A P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 <03638> 0007045A P WM_KEYDOWN nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:1 fRepeat:0 fUp:0 <03639> 0007045A P WM_KEYDOWN nVirtKey:'L' cRepeat:1 ScanCode:18 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <03640> 0007045A P WM_DEADCHAR chCharCode:'002F' (47) cRepeat:1 ScanCode:18 fExtended:0 fAltDown:1 fRepeat:0 fUp:0 <03641> 0007045A P WM_KEYUP nVirtKey:'L' cRepeat:1 ScanCode:18 fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <03642> 0007045A P WM_SYSKEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:1 fRepeat:1 fUp:1 <03643> 0007045A P WM_KEYUP nVirtKey:VK_MENU cRepeat:1 ScanCode:38 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 Under Wine 1.5.5 however (WINEDEBUG=+msg), I get those : trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x6007e wp eb lp 760001 [note: wp = VK_OEM_PA2] trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x6007e wp 4c lp c0260001 [note: wp = 'L'] trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x6007e wp eb lp c0760001 [note: wp = VK_OEM_PA2] With xev, I get : KeyPress event, serial 93, synthetic NO, window 0x4000001, root 0xbc, subw 0x0, time 5086996, (1585,410), root:(2578,425), state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 93, synthetic NO, window 0x4000001, root 0xbc, subw 0x0, time 5087052, (1585,410), root:(2578,425), state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES, XKeysymToKeycode returns keycode: 92 XLookupString gives 0 bytes: XFilterEvent returns: False After "setxkbmap us", AltGr is bound to Alt_R under X (checked with xev), and I get this under Wine : trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 0x10046 wp a5 lp 21380001 [wp = VK_RMENU] trace:msg:peek_message got type 7 msg 104 (WM_SYSKEYDOWN) hwnd 0x10046 wp 4c lp 20260001 [wp = 'L'] trace:msg:peek_message got type 6 msg 106 (WM_SYSCHAR) hwnd 0x10046 wp 6c lp 20260001 [wp = 'l'] trace:msg:peek_message got type 7 msg 105 (WM_SYSKEYUP) hwnd 0x10046 wp 4c lp e0260001 [wp = 'L'] trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10046 wp a5 lp c1380001 [wp = VK_RMENU] (yes, I have a KEYUP without KEYDOWN) Wich is still not the same as Windows. So I think there is two problems here : - ISO_Level3_Shift is not properly recognized by Wine - "AltGr" doesn't have the same behavior under Wine and Windows FYI, attached patch is a workaround to have the same behavior than Windows. With it, I get this under Wine : trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp a2 lp 1d0001 [note: wp = VK_LCONTROL] trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp a4 lp 20380001 [note: wp = VK_LMENU] trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10062 wp 4c lp 20260001 [note: wp = 'L'] trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10062 wp 4c lp e0260001 trace:msg:peek_message got type 7 msg 105 (WM_SYSKEYUP) hwnd 0x10062 wp a2 lp e01d0001 trace:msg:peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x10062 wp a4 lp c0380001 Which is still not the same as Windows : - Windows uses (right) control + menu (with fExtended flag for menu) whereas Wine uses left control + left menu. Not investigated if this is related to TranslateMessage. - AltGr+L is a dead symbol on my keymap. Windows send a DEADCHAR message, wheras Wine send nothing. Note that I had to disable the XFilterEvent test in event.c to have those messages, otherwise nothing is sent to the program (but that’s another story for another bug report) But it suffice for my use case (WoW key bindings with right alt) -- 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 57925] New: winewayland.drv: Games are not filled to my monitor's resolution
by WineHQ Bugzilla Nov. 30, 2025

Nov. 30, 2025

https://bugs.winehq.org/show_bug.cgi?id=57925 Bug ID: 57925 Summary: winewayland.drv: Games are not filled to my monitor's resolution Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: daniel.penalized(a)proton.me Distribution: ArchLinux Created attachment 78178 --> https://bugs.winehq.org/attachment.cgi?id=78178 SWAT 4 output log (in this log I opened the settings and tried to set the maximum resolution that the game supports) Old games (specifically Ghost Recon, Splinter Cell 1, Splinter Cell 2 and SWAT 4) won't fill to my monitor's resolution, even if I switch to a higher resolution in the game settings. This MR (https://gitlab.winehq.org/wine/wine/-/merge_requests/6804) was supposed to work with winewayland.drv and fix this issue, but it doesn't work or fix it. However, this MR (https://gitlab.winehq.org/wine/wine/-/merge_requests/5057) does work and fixes that issue. There is a workaround (at least for SWAT 4): which is to take the game window out of fullscreen, then toggle the maximization state of the game window and put the game window back into fullscreen (In labwc/openbox terms: ToggleFullscreen > ToggleMaximize > ToggleFullscreen). I think it also works for Ghost Recon. Splinter Cell 1 even supports 16:9 resolutions, but only in game (in the menus, loadings and cut-scenes are still not filled in for my monitor's resolution) and Splinter Cell 2 is worse, there's no support for 16:9 resolutions or even a workaround. - I use labwc/wlroots as WM. - I'm using the new WoW64 mode. I did some tests with normal wine, but it's been a few weeks or months, so I'm not sure if the new WoW64 mode has any impact here, but I don't think so. (Sorry if the paraphrases seem disconnected from each other, if I'm not very clear or if I'm giving too little information. I've been doing a lot of testing over the last few hours and my mind isn't in a good place to come up with a good text here :/) -- 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