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

[Bug 30639] New: Audio stuttering and performance drops in Star Wolves 3
by wine-bugs＠winehq.org Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=30639 Bug #: 30639 Summary: Audio stuttering and performance drops in Star Wolves 3 Product: Wine Version: 1.5.3 Platform: x86 URL: http://www.gamershell.com/download_8237.shtml OS/Version: Linux Status: UNCONFIRMED Keywords: download, regression Severity: normal Priority: P2 Component: directx-dsound AssignedTo: wine-bugs(a)winehq.org ReportedBy: gyebro69(a)gmail.com CC: patrakov(a)gmail.com Classification: Unclassified Regression SHA1: 275dfb83f2371a476b615b260465afb3cdf67f32 Due to a recent commit in Wine I get severe audio stuttering as well as slowdowns in certain games. This seems to affect only a small number of games, the vast majority of my games are still running fine. Whether these games are buggy ones or it is indeed a problem with the patch I can't decide as I don't have Windows installed to check how these games behave under native Windows. 275dfb83f2371a476b615b260465afb3cdf67f32 is the first bad commit commit 275dfb83f2371a476b615b260465afb3cdf67f32 Author: Alexander E. Patrakov <patrakov(a)gmail.com> Date: Mon May 7 00:06:13 2012 +0600 dsound: Added a windowed-sinc resampler. :040000 040000 8ecb8b2fbc5c65c2066aaf9a5e8c58104996c5ab 3768c38fdafc656c5e18e14ad70884ea7864b758 M dlls :040000 040000 680c52a0ebe164ca9b6a42d40c6521a91ae86e96 83407150c9beff0aa69d2d2e017b522543ac347f M tools Star Wolves 3: Civil War (v1.12, Steam): audio playback is glitch-free and performance is okay (well above 60 fps) in the menus and during the tutorial mission. When I advance in the game or when I load a saved game I get severe audio stuttering and framerate drops below 15 fps. This makes the game hardly playable. If I quit playing and go back to the main menu, everything is back to normal. The demo for the game is protected with Starforce so it cannot be tested. Droplitz (Steam version): this is a puzzle game. A certain sound effect is intended to play when I create a path for the 'drops' and they make their way to their goal. When this happens I observe the same audio stuttering and performance drops. It lasts only for 2-3 seconds so it's not so severe. Armored Fist 3: audio (both music and speech) are stuttering heavily and it affects performance too. Link to the demo added to URL. There is no music in the demo, but you should observe the problem with speech after starting a new game. HoverAce: the same stuttering in audio and slowdowns can be observed. No demo available. Terminal output doesn't show anything related. Fedora 16 x86 Kernel 3.3.4-3.fc16.i686.PAE Alsa 1.0.25 Pulseaudio is not running Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) -- 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 72

[Bug 60421] New: Incomplete implementation of cldapi.dll causes OneDrive to crash.
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60421 Bug ID: 60421 Summary: Incomplete implementation of cldapi.dll causes OneDrive to crash. Product: Wine Version: 11.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: 17lifers(a)proton.me Target Milestone: --- Distribution: --- Created attachment 82228 --> http://bugs.winehq.org/attachment.cgi?id=82228 Backtrace of cldapi.dll describing where it went wrong After getting the OneDrive 26.153.0809.0004 installer working (run in wine cmd with /peruser /childprocess options, set os as win10, disable cldapi.dll, re-enable after install), I have executed it from its folder of C:\Users\<user>\AppData\Local\Microsoft\OneDrive\OneDrive.exe. Attached is the backtrace of cldapi.dll. -- 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 60399] New: C++ exception reproducer (ARM64): crashes when a DLL function ends with a call to a noreturn throw helper
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60399 Bug ID: 60399 Summary: C++ exception reproducer (ARM64): crashes when a DLL function ends with a call to a noreturn throw helper Product: Wine Version: 11.18 Hardware: aarch64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcirt Assignee: wine-bugs(a)list.winehq.org Reporter: micronenator(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82197 --> http://bugs.winehq.org/attachment.cgi?id=82197 reproducer and logs A small ARM64 C++ exception test crashes in Wine's C++ runtime when a DLL function ends with a call to a noreturn throw helper, as MSVC lays such functions out. The reproducer (source and binaries) is attached. Tested on native aarch64 Ubuntu 24.04 with WineHQ master 4e819f054dd2d9ee855ee3f1e30d8c1bb8f80fcf (wine-11.18), built from official source (headless: --without-x and some optional libraries disabled; the test is a console program). Clean WINEPREFIX, Wine's builtin DLLs, no DLL overrides. Steps to reproduce: 1. Unpack the attached cxxeh-bug.tar.gz and cd into reproducer/. 2. Run: wine ./cxxeh.exe 5 Expected: "caught: OK", exit code 0 (as for cases 1-4). Actual: exit code 5 after a NULL read in ucrtbase!cxx_frame_handler+0x15c (WineDbg: ldr w9, [x0] with x0 = 0). Cases 1-4 (throw/catch in the exe, inside a DLL, from a DLL to the exe, catch (...)) all pass. What case 5 does: A DLL function with a local destructor object ends with a call to a noreturn throw helper. Its ARM64 unwind range ends right after that call, matching MSVC's layout (clang's trailing brk is left out of the range), so the unwound return address lies just past the function. Analysis: In dlls/msvcrt/except.c, cxx_frame_handler() passes the raw dispatch->ControlPc to RtlLookupFunctionEntry() for the nested exception check and dereferences the result without checking it. The neighbouring exception state lookups use get_exception_pc(), which subtracts 4 on ARM64 when ControlPcIsUnwound is set. Using the adjusted PC and skipping the check when no function entry is found fixes case 5 here; cases 1-4 still pass. A patch will follow as a merge request. Controls: - Microsoft's ARM64 VC++ runtime next to the test, with an explicit native override for vcruntime140.dll: case 5 passes. (Not used in the reported run.) Real-world code: Seen first with Unity OpenXR 1.14.3 in an ARM64 Unity game under Proton 11.0: the game crashed when the tracking origin changed, and Microsoft's runtime avoided it. UnityOpenXR.dll is MSVC-built and has this layout: 449 of its functions use __CxxFrameHandler3, 25 of them end with a call to a noreturn throw helper, and for 18 of those the unwound return address lies in no function. The report above uses only the standalone test. Attachment: cxxeh-bug.tar.gz reproducer/ source, build script, layout tool, README and the small ARM64 test binaries (no Microsoft DLLs) logs/ terminal output as .txt files: baseline-case1..5.txt unmodified Wine (case 5 with WineDbg trace) baseline-seh.txt unmodified Wine, WINEDEBUG=+seh fixed-case1..5.txt patched Wine fixed-seh.txt patched Wine, WINEDEBUG=+seh control-case5.txt Microsoft runtime control prefix-init.txt clean prefix initialization -- 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 59877] New: Tagscanner: Server-Side Decorations being drawn on top of the Client-Side Decorations.
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59877 Bug ID: 59877 Summary: Tagscanner: Server-Side Decorations being drawn on top of the Client-Side Decorations. Product: Wine Version: 11.11 Hardware: x86-64 URL: https://web.archive.org/web/20260615235907/https://www .xdlab.ru/files/tagscan-6.1.21-setup.exe OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: draviezz(a)proton.me Distribution: --- Created attachment 81185 --> http://bugs.winehq.org/attachment.cgi?id=81185 (1) Window_wine_default Instructions for reproduction/testing: 1. Create and use a clean, default WINEPREFIX (~/.wine). 2. Install the program normally. 3. Open the program normally. This program has its own borders and title bar, but the system still unnecessarily places one on top of it. (1)(A) Workaround - disabling "Allow the window manager to decorate the windows". Disabling this option prevents the overlay from happening, but artifacts and/or visual glitches on the window border will appear if your WINEPREFIX uses a version of Windows higher than Windows 8.1. (2)(B)(C)(D)(E) -- 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 9

[Bug 7054] Pure Pinball game crashes trying to access freed texture objects
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=7054 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #28 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 11.20. -- 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 0

[Bug 60517] New: ZBrush 2025.1.2 crashes when using ZRemesher 4.0 on complex mesh
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60517 Bug ID: 60517 Summary: ZBrush 2025.1.2 crashes when using ZRemesher 4.0 on complex mesh Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: pali12345(a)gmail.com Target Milestone: --- Distribution: --- I am running ZBrush 2025.1.2 under Wine on Kubuntu 24.04 LTS (X11 session). The application starts and runs, including pen pressure and basic sculpting. However, when I use ZRemesher 4.0 on a complex mesh (high polygon count), ZBrush either crashes unexpectedly or freezes the entire system. The same operation works perfectly in ZBrush 2022 (which uses ZRemesher 3.0) under the same Wine prefix and environment. The issue appears to be a regression introduced with ZRemesher 4.0, which uses massive multithreading. Wine seems unable to handle the synchronization of many threads, leading to a race condition and subsequent crash/hang. System information: - Distribution: Kubuntu 24.04 LTS (X11) - CPU: Intel Core i7-13700F - GPU: NVIDIA GeForce RTX 4070 Ti - NVIDIA Driver: 580.178.04 (or your current version) - Wine version: wine-11.9 (or your current version) - ZBrush version: 2025.1.2 - Wine prefix: /home/p/zbrush_2026 (adjust if needed) Steps to reproduce: 1. Start ZBrush 2025.1.2 with Wine. 2. Load a high-polygon mesh (e.g., more than 1 million polygons). 3. Go to Geometry > ZRemesher. 4. Click the ZRemesher button to start the remeshing process. 5. The progress bar advances, but at some point (often near completion or when finishing), ZBrush crashes or the whole system freezes. Additional information: - ZBrush 2022 (ZRemesher 3.0) works flawlessly in the same environment. - The crash/freeze does not occur with simple or low-poly meshes, but is very frequent with complex, high-poly meshes. - I have tried limiting CPU cores via WINE_CPU_TOPOLOGY and disabling Esync/Fsync, but the problem persists. - The issue seems to be related to thread synchronization in Wine when ZRemesher 4.0 spawns many threads. -- 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 0

[Bug 47015] New: Photoshop CC2019 Login screen does not render
by wine-bugs＠winehq.org Oct. 16, 2026

Oct. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=47015 Bug ID: 47015 Summary: Photoshop CC2019 Login screen does not render Product: Wine Version: 4.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: funtimeschaos(a)rocketmail.com Distribution: --- Created attachment 64172 --> https://bugs.winehq.org/attachment.cgi?id=64172 Log for 4.5 staging Tested on 4.5 staging. PS was installed on windows. I believe I used "winetricks gdiplus vcrun2010 vcrun2012 vcrun2013 vcrun2015 msxml3 msxml6 atmlib corefonts fakejapanese" to get this far. Not using winetricks causes the launcher to output the following and exit immediately: ``` 002a:fixme:ntdll:NtQuerySystemInformationEx Relationship filtering not implemented: 0x4 002a:fixme:ntdll:NtQuerySystemInformationEx Relationship filtering not implemented: 0x4 002a:err:module:LdrInitializeThunk "CRClient.dll" failed to initialize, aborting 002a:err:module:LdrInitializeThunk Initializing dlls for L"Z:\\home\\jenia\\Desktop\\winestuff\\pf\\pf64\\Adobe\\APCC2019\\Photoshop.exe" failed, status c0000005 ``` When trying to launch PS, it does launch, however, there is a small window (which I assume is the creative cloud login screen) which does not render. X ing out of the small window closes PS. Log is attached. Looks to me like it is stuck trying (and failing) to render web content? This version of PS was installed on a Japanese system, so a language support issue might be related. -- 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 27

[Bug 60516] New: Zeroconf 3.7.16 (.NET mDNS library): service discovery fails with SocketException 10022 (Invalid argument)
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60516 Bug ID: 60516 Summary: Zeroconf 3.7.16 (.NET mDNS library): service discovery fails with SocketException 10022 (Invalid argument) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)list.winehq.org Reporter: marvin.gnad(a)herrmannultraschall.com Target Milestone: --- Distribution: --- Created attachment 82375 --> http://bugs.winehq.org/attachment.cgi?id=82375 Terminal output with WINEDEBUG=+winsock A .NET 8 application using the Zeroconf library (https://www.nuget.org/packages/Zeroconf/3.7.16) fails under Wine with SocketException 10022 when it starts an mDNS query. On Windows the same application discovers the services. Steps to reproduce: 1. Create a .NET 8 console app that references Zeroconf 3.7.16 and calls ZeroconfResolver.ResolveAsync("_opcua-tcp._tcp.local."). 2. Publish it self-contained for win-x64 and run it with "wine app.exe" in a clean prefix. Expected: no exception (the call returns the services found, or an empty list). Actual: SocketException 10022 from Socket.SetSocketOption. No mDNS service needs to be present on the network; the error happens while the socket is set up. The +winsock trace (attached) shows setsockopt(IPPROTO_IP, IP_MULTICAST_IF) failing for each interface Zeroconf uses (7 interfaces, 14 calls including retries), e.g.: setsockopt ... name IP_MULTICAST_IF, optval ... (436207616), optlen 4 server_setsockopt status 0xc000000d. 436207616 is 0.0.0.26 in network byte order, i.e. interface index 26. Windows treats values in the 0.x.x.x range (except 0.0.0.0) as an interface index: https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-o… (IP_MULTICAST_IF) https://learn.microsoft.com/en-us/windows/win32/api/ws2ipdef/ns-ws2ipdef-ip… (imr_interface) In a separate test, IP_ADD_MEMBERSHIP with an interface index in imr_interface failed the same way (not in the attached log, as Zeroconf fails before reaching it). Passing the interface's IPv4 address instead of the index works for both options. Environment: Arch Linux x86-64, Wine 11.19 (distribution package, unmodified), clean prefix, no DLL overrides. Note: the hostname and IP addresses in the attached log were replaced with placeholders (HOSTNAME, 192.0.2.x, 198.51.100.x, 203.0.113.x, 2001:db8::x, fe80::x). -- 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 0

[Bug 57647] New: DEATHLOOP needs GetWsChangesEx implementation
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=57647 Bug ID: 57647 Summary: DEATHLOOP needs GetWsChangesEx implementation Product: Wine Version: 10.0-rc4 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Output has lots of 0514:fixme:seh:GetWsChangesEx (FFFFFFFFFFFFFFFF, 0000000000000000, 00007F4D23A8FC10) -- 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 60515] New: Notification area icons stop receiving mouse clicks after the system tray host is restarted (GNOME AppIndicator extension, suspend/resume)
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60515 Bug ID: 60515 Summary: Notification area icons stop receiving mouse clicks after the system tray host is restarted (GNOME AppIndicator extension, suspend/resume) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: source, testcase Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: brunet.cyril(a)hotmail.com Target Milestone: --- Distribution: --- Created attachment 82373 --> http://bugs.winehq.org/attachment.cgi?id=82373 traytest.c After the XEmbed system tray host goes away and comes back, Wine re-docks its notification icons, but they no longer receive any mouse input: clicking the icon does nothing, so applications that are only reachable through their tray icon menu cannot be used anymore. A blank 160x20 "explorer.exe" window (the stand-alone tray) also appears and stays on screen; clicking in it does nothing either. On my system this happens after every suspend: the monitors disconnect, GNOME Shell recreates its tray, and from then on every Wine tray icon is dead until the application is restarted. The same thing can be triggered on demand by disabling and re-enabling the GNOME Shell AppIndicator extension, which provides the legacy (XEmbed) tray. The attached traytest.c adds a tray icon and prints the callback messages it receives. The attached terminal output shows the left and right clicks being reported before the tray host restart, and nothing after it. Steps to reproduce: 1. GNOME Shell (Wayland session, XWayland) with the AppIndicator extension and its legacy tray enabled (Ubuntu: ubuntu-appindicators, "legacy-tray-enabled" true). 2. Build traytest.c: x86_64-w64-mingw32-gcc traytest.c -lshell32 -o traytest.exe 3. wine traytest.exe, then click the icon in the top bar: callbacks 0x0201/0x0202 and 0x0204/0x0205 are printed. 4. gnome-extensions disable ubuntu-appindicators(a)ubuntu.com; gnome-extensions enable ubuntu-appindicators(a)ubuntu.com (or suspend and resume the machine) 5. Click the icon again. Expected: the callbacks are printed again, as they are after a restart of the application. Actual: nothing is printed; the stand-alone tray window is shown. Additional information (from +systray,+event,+cursor,+x11drv traces): - When the tray host disappears, the docked icon gets WM_CLOSE ("icon 1 no longer embedded"), hide_icon()/show_icon() fail to dock it again and it is added to the stand-alone tray with systray_add_icon(). - When the new tray host announces itself (MANAGER message), hide_icon() is called on the icon that now lives in the stand-alone tray. The driver still considers its window embedded, so WINE_SYSTRAY_DOCK_REMOVE succeeds and icon->display is set to ICON_DISPLAY_HIDDEN before systray_remove_icon(), which then returns early. The icon window stays a WS_CHILD of the stand-alone tray window (which stays visible) while being docked again. - Separately, while the icon window goes back and forth, the window manager (mutter) manages it for a moment and deletes its WM_STATE property when it gets docked. handle_wm_state_notify() takes this as "unexpected WM_STATE 0", the desired wm_state becomes Withdrawn, and window_update_client_config() then ignores every later configure change ("unexpected config (1569,5)-(1585,21)"). The Win32 rect of the icon window stays at -1920,0 while the X window is at 3489,5, so the button events that winex11 receives and maps to (1577,13) are never delivered to the icon window. Tested with Wine 11.0 built from source (with unrelated local changes in other components), clean 64-bit prefix, Ubuntu 26.04.1, GNOME Shell 50.1 (Wayland, XWayland), three monitors. Both code paths look unchanged in current git master (programs/explorer/systray.c hide_icon(), dlls/winex11.drv/event.c handle_wm_state_notify()). -- 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