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

[Bug 60543] New: ntdll: on macOS, check_invalid_gsbase() mistakes page-straddling access violations for %gs faults and retries them forever
by WineHQ Bugzilla Oct. 19, 2026

Oct. 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=60543 Bug ID: 60543 Summary: ntdll: on macOS, check_invalid_gsbase() mistakes page-straddling access violations for %gs faults and retries them forever Product: Wine Version: unspecified Hardware: arm OS: MacOS Status: UNCONFIRMED Severity: critical Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: opendev(a)netforza.com Target Milestone: --- On macOS, Diablo II: Resurrected (launched from Battle.net) hangs at startup with a black window; the main thread spins in signal handling. Cause: an access violation on an instruction that straddles into an inaccessible page is mistaken by check_invalid_gsbase() for a %gs fault and silently retried forever. D2R's copy protection decrypts code pages on demand through exactly this kind of fault, so it retries ~40,000 times per second and never progresses. Patch: https://github.com/SergioB/d2r-macos-wine-fix/tree/main/patches (0001) Full analysis: https://github.com/SergioB/d2r-macos-wine-fix/blob/main/docs/investigation.… Environment: MacBook Air M3, macOS 26.6.2, Wine 11.0, D2R 3.3.93847, Battle.net 2.53.5. Reproduced on vanilla Wine: [version] -- 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 60542] New: Keys that produce non-ASCII characters (2/é, 7/è...) don't work as shortcuts in Unreal Engine games
by WineHQ Bugzilla Oct. 19, 2026

Oct. 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=60542 Bug ID: 60542 Summary: Keys that produce non-ASCII characters (2/é, 7/è...) don't work as shortcuts in Unreal Engine games Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: vbernard42(a)gmail.com Target Milestone: --- Distribution: --- A number of games use by default the numeric keys from the top row of the keyboard for character or item swapping. AZERTY players sometimes encounter difficulties with some games, mainly on the 2 key (which is also é on AZERTY keyboards). This occurs, for example, on Arc Raiders and NTE, two Unreal Engine 5 games. The key works fine when typing text, but the associated action never triggers. In Arc Raiders, rebinding the action with the same key fixes the problem (this writes `UnknownCharCode_201` in the associated configuration file). After some investigation, it appears to come from the winex11's implementation of MapVirtualKeyEx() (with wMapType=MAPVK_VK_TO_CHAR), which tries to capitalize every character when it's possible (RtlUpcaseUnicodeChar()). Only VK_A to VK_Z should return uppercase letters, others should return their unshifted character (as expected in https://gitlab.winehq.org/wine/wine/-/merge_requests/12314 and hinted in the Remarks section of https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-mapv…) Reproduced with vanilla Wine 11.20: MapVirtualKeyW('2', MAPVK_VK_TO_CHAR) returns 0xc9 instead of 0xe9 with a French layout. It looks like this has been like that since 1999. win32u's NtUserMapVirtualKeyEx() does the correct thing here: the Wayland driver doesn't override it, so it's a common workaround to set PROTON_ENABLE_WAYLAND=1 on those games with some Proton forks (see e.g. https://www.reddit.com/r/NevernessToEverness/comments/1sz951p/bug_key_2_not…) See also: https://github.com/ValveSoftware/Proton/issues/8658 And maybe: https://bugs.winehq.org/show_bug.cgi?id=45740 -- 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 60389] New: 16-bit installer subsystem crashes (fixed-offset null-pointer-style read) under new WoW64, works fine under classic WoW64
by WineHQ Bugzilla Oct. 19, 2026

Oct. 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=60389 Bug ID: 60389 Summary: 16-bit installer subsystem crashes (fixed-offset null-pointer-style read) under new WoW64, works fine under classic WoW64 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: fjavier1954(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82182 --> http://bugs.winehq.org/attachment.cgi?id=82182 Crash log, Wine 11.17, Windows XP Summary 16-bit installer subsystem (krnl386.exe16) crashes with a null-pointer-style read access violation when running under the new WoW64 architecture (no multilib / no 32-bit host process). The same installer works correctly under classic WoW64 (wine32 + wine64, e.g. Wine 11.0 on Linux Mint 21.3 with multilib/i386 enabled). Environment - Wine build: wine-11.17 and wine-11.18 (Arch/CachyOS official packages, pure WoW64, no multilib dependency) — same crash class reproduced on both versions, see "Second reproduction" below. - Host: CachyOS Linux, kernel 7.2.5-1-cachyos, x86_64. - Working reference environment: Wine 11.0, Linux Mint 21.3, classic WoW64 (wine32 + wine64, multilib/i386 enabled) — same installer runs and completes correctly there, aside from an unrelated 3D-rendering bug. - WINEPREFIX: fresh 64-bit WoW64 prefix (default), no WINEARCH override. WINEARCH=win32 is rejected in this build with: "WINEARCH is set to 'win32' but this is not supported in wow64 mode." - Windows version emulated: reproduced under both "Windows XP" and "Windows 2000" settings in winecfg — same crash signature in both cases (attachments here are the Windows XP runs only). What I'm trying to run A commercial legacy Windows application from around 1999-2000 (proprietary software, name withheld, happy to give more detail if it helps triage). The main installer is MAINSETUP.EXE, a PE32 executable for MS Windows 4.00 (GUI), Intel i386, 4 sections, built with linker version 6.0. I confirmed with the `file` command that this is a genuine 32-bit PE executable, not a 16-bit NE executable, and not an archive-wrapped installer (verified by extracting it with 7-Zip: it only contains the executable's own PE sections — .text/.data/.rdata/.rsrc — no embedded installer payload). The final installed application binaries are also all PE32 32-bit. So the crashing code appears to be a 16-bit component invoked internally by this otherwise-32-bit installer (likely a legacy install/license-check routine from that era), rather than the application itself being 16-bit. Steps to reproduce 1. On a system with Wine built against the new (pure) WoW64 architecture (no multilib), create a fresh WINEPREFIX. 2. Set the Windows version to XP (or 2000) in winecfg. 3. Run wine MAINSETUP.EXE. 4. Proceed through the installer UI to the license-code entry screen. 5. Enter a valid license code and click "Install". Expected result The installer proceeds with the installation, as it does under classic WoW64 (Wine 11.0, Mint 21.3, wine32+wine64). Actual result (Wine 11.17) The installer window stops responding. Terminal output shows the 16-bit subsystem (krnl386.exe16, user.exe16, gdi.exe16, etc. — all loaded successfully) is invoked, but it crashes shortly after with an unhandled exception: a page fault on read access to address 0x00000030, happening in wow64 32-bit code, with the backtrace going through ntdll, kernelbase, kernel32, and krnl386.exe16 (see attached crash-11.17-winxp.txt for the full backtrace and register dump). Reproduced twice, with two different Windows-version settings (XP and Windows 2000), both times crashing with a read access violation at the same fixed offset (0x00000030) from what looks like a null pointer, always originating from krnl386.exe16 calling into kernelbase/kernel32. Second reproduction on Wine 11.18 Re-tested on wine-11.18 (same host, same installer, same steps, Windows XP setting). The crash is the same class of bug — a read fault at the same fixed offset 0x00000030, still triggered from 16-bit code — but the exact call site has moved: this time the backtrace goes through win32u, user32, user.exe16 and krnl386.exe16 (see attached crash-11.18-winxp.txt). On 11.17 the crash happened one layer lower, directly in krnl386.exe16 -> kernelbase/kernel32. On 11.18 it happens one layer higher, in a 16-bit USER call (user.exe16, e.g. window/dialog creation) thunking up through user32 into win32u — but it's still the same fixed offset (0x30) being read, which looks like the same underlying null or uninitialized pointer issue surfacing at a different point in the 16-to-32-bit call chain, rather than two unrelated bugs. This looks consistent with the large TEB/main-image rework that landed around 11.18 having shifted where the bad pointer gets dereferenced, without fixing the root cause. Additional notes - This is not the well-known "WINEARCH=win32 not supported in wow64 mode" limitation — the 16-bit subsystem does initialize and load all its modules correctly under both 11.17 and 11.18 (unlike an earlier test on a CachyOS-patched Wine 10.x testing build, where krnl386.exe16 failed to initialize entirely). The crash here happens deeper, once 16-bit code is actually executing and calling back into 32-bit routines — it looks like a bug in the 16-to-32-bit thunking/ translation path of the new WoW64 implementation itself, rather than a missing-support issue. - This may be related to bug 54670 ("16-bit applications fail in wow64 mode"), which was closed fixed in 10.16 and addressed an earlier failure where krnl386.exe16 would fail to initialize entirely ("failed to initialize, aborting"). That specific failure is no longer present here — krnl386.exe16 and its dependent 16-bit modules all initialize and run correctly under 11.17/11.18. This report is about a separate crash that occurs further down the call chain, once 16-bit code is already running, which may be a follow-on issue left after that earlier fix rather than the same bug. - Switching the emulated Windows version between XP and 2000 does not change the outcome (only the exact call depth reached before the crash). - The fact that the same fixed-offset (0x30) read fault reproduces across two consecutive dev releases (11.17 and 11.18), at two different points in the 16-to-32-bit call chain, suggests a structural issue in the new WoW64's 16-bit thunking rather than a one-off regression in either release. - Happy to test further Wine versions or provide WINEDEBUG logs if that would help triage. I'd rather not share the installer itself, as it's proprietary commercial software. --- -- 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 60541] New: Ubersoldier II crashes during startup - corrupted private copies of Wine code observed with bundled StarForce protection
by WineHQ Bugzilla Oct. 19, 2026

Oct. 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=60541 Bug ID: 60541 Summary: Ubersoldier II crashes during startup - corrupted private copies of Wine code observed with bundled StarForce protection Product: Wine Version: 11.20 Hardware: x86-64 URL: https://store.steampowered.com/app/281410/UberSoldier_ II/ OS: Linux Status: NEW Keywords: obfuscation Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Target Milestone: --- Distribution: ArchLinux Created attachment 82407 --> http://bugs.winehq.org/attachment.cgi?id=82407 Wine terminal output + Protection ID log Over the past 7 years, I've acquired 3 different versions of Ubersoldier II, 2 of which come from so-called DRM-free stores. I own the IndieGala, Steam, and Zoom Platform versions, and all three have the exact same issue when launched under Wine: the game crashes immediately upon launch. The startup failure also occurs with the legacy shared WoW64 build configuration. On Windows 11 in VirtualBox, the game reaches the menu properly. All three releases of the game retain the Starforce DRM mechanism (or remnants of it). This was initially verified using Protection ID and subsequently confirmed via AI-assisted analysis. To reproduce, launch xtend.exe from the installed game directory. The game crashes or exits before reaching the menu. The failure varies between runs: page faults, stack overflows and silent termination have all occurred. Investigation under Wine found that private executable copies of Wine function code contain altered instructions, including missing register assignments. In a captured unpatched run, the damaged allocator copy leads to an invalid memory access. This points to a compatibility problem involving the protection-associated code-copying machinery; it does not establish incorrect Wine heap API semantics. I set the affected Wine component to 'ntdll': the strongest evidence for this is the crash occurring in Wine's corrupted private copy of RtlAllocateHeap. This doesn't imply a faulty API implementation, it merely pinpoints the area most relevant to the compatibility issue under investigation. -- 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 46697] New: ntQueryDirectoryFileEx needed
by wine-bugs＠winehq.org Oct. 19, 2026

Oct. 19, 2026

https://bugs.winehq.org/show_bug.cgi?id=46697 Bug ID: 46697 Summary: ntQueryDirectoryFileEx needed Product: Wine Version: 4.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: springrat(a)protonmail.com Distribution: --- Mod Organizer 2 fails to load the userspace virtual file system (USVFS) .dll due to a lack of the function, "ntQueryDirectoryFileEx" in ntdll.dll. As a result, the program itself cannot be used for its intended purposes of organizing and loading mods directly, and some critical features such as using tools within the virtual environment break. -- 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 24

[Bug 57222] New: Installation of Konami games fails (Bombergirl, Beatmania IIDX Infinitas) with error 1603
by WineHQ Bugzilla Oct. 19, 2026

Oct. 19, 2026

https://bugs.winehq.org/show_bug.cgi?id=57222 Bug ID: 57222 Summary: Installation of Konami games fails (Bombergirl, Beatmania IIDX Infinitas) with error 1603 Product: Wine Version: 9.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: sraamar.psplus(a)gmail.com Distribution: --- Created attachment 77139 --> https://bugs.winehq.org/attachment.cgi?id=77139 Trace The installation process for certain Konami games, such as Bombergirl and Beatmania IIDX Infinitas, fails when run through Wine. The setup halts with error code 1603. These are the relevant lines I think of the trace: 0120:err:msi:execute_script Execution of script 0 halted; action L"[C:\\users\\vince\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\KONAMI\\BomberGirl.url\0080http://eagate.573.jp/game/konasteapp/API/login/login.html?game_id=bomber-girl\00801\0080C:\\Games\\BomberGirl\\BomberGirl.ico\00800\0080C:\\users\\vince\\Desktop\\BomberGirl.url\0080h"... returned 1603 0120:err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603 Bombergirl installer: https://p.eagate.573.jp/game/eacbg/bg/download/installer.html Beatmania IIDX INFINITAS installer : https://d1rc4pwxnc0pe0.cloudfront.net/v2/installer/infinitas_installer_2022… Tested on Arch Linux with wine 9.18 in a clean prefix. -- 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 60538] New: iperf3 needs support for the TCP_MAXSEG socket option
by WineHQ Bugzilla Oct. 19, 2026

Oct. 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=60538 Bug ID: 60538 Summary: iperf3 needs support for the TCP_MAXSEG socket option Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)list.winehq.org Reporter: alexhenrie24(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82405 --> http://bugs.winehq.org/attachment.cgi?id=82405 Terminal output Steps to reproduce: 1. In one terminal, run `wine iperf3.exe -s` 2. In another terminal, run `wine iperf3.exe -c localhost` 3. Observe the following message: 014c:fixme:winsock:getsockopt unrecognized TCP option 0x4 0x4 is TCP_MAXSEG, which has a 1:1 Linux equivalent, but it isn't yet hooked up in Wine. iperf3.exe also has a -M option which should set TCP_MAXSEG to an arbitrary value, but the program doesn't seem to even try to set the option if it can't be read. $ sha256sum iperf3.22_64.zip 520f985ee03adb8a92d710ac24e7abe2ddef5eb775774093694bc75be33f80a6 -- 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 60537] New: Final Fantasy XI Online: Window manager rules not applying as usual, and window decorations misbehaving.
by WineHQ Bugzilla Oct. 19, 2026

Oct. 19, 2026

http://bugs.winehq.org/show_bug.cgi?id=60537 Bug ID: 60537 Summary: Final Fantasy XI Online: Window manager rules not applying as usual, and window decorations misbehaving. Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: chiitoo(a)gentoo.org Target Milestone: --- Regression SHA1: 6cfa941df3f385ab025aa2c458753c017aa49ccc Distribution: Gentoo Created attachment 82404 --> http://bugs.winehq.org/attachment.cgi?id=82404 terminal output during application start After 6cfa941df3f [1], at least some states of the PlayOnline Viewer (as well as Final Fantasy XI Online when running in windowed mode) application window is no longer remembered via kwin-x11 window/application rules. I tend to have KWin remember "No Title Bar and Frame", or "apply initially", but neither seems to no longer be working with the aforementioned commit. Using 'force' instead of 'remember' or 'apply initially' does still work. Another oddity starting with this change can be seen when exiting Final Fantasy XI Online, and going back to the PlayOnline Viewer, where there is a brief moment where the window decorations appear to be something like the Wine window decorations, and after a moment the desktop theme-style decorations take over again. While there are some new'ish fixmes to be seen with the application output, they do start before this commit, but I wonder if they could hint towards something here. fixme:wgl:win32u_context_create Unknown WGL_CONTEXT_FLAGS_ARB 0x1 Thank you! 1. 6cfa941df3f385ab025aa2c458753c017aa49ccc -- 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 60536] New: Clip Studio Paint 1.13.2 Drawing Tool Cursor (pen, brush, eraser, etc) stops responding after pressing tablet button. Prevent drawing with mouse or stylus.
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60536 Bug ID: 60536 Summary: Clip Studio Paint 1.13.2 Drawing Tool Cursor (pen, brush, eraser, etc) stops responding after pressing tablet button. Prevent drawing with mouse or stylus. Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: firstone1993(a)msn.com Target Milestone: --- Distribution: --- Created attachment 82403 --> http://bugs.winehq.org/attachment.cgi?id=82403 Video demonstrating the bug. After pressing a button on my graphics tablet, the cursor for drawing related tools (Pen, Brush, Eraser, etc) will suddenly freeze in place, independently from the mouse cursor. It will jump around when you zoom or pan, but you will be unable to actually draw anything at all. Clicking out of the program and back into it "fixes" the frozen cursor, but then Clip Studio will no longer detect pen pressure until I restart it. System info: OS Linux Mint 22.3 (Cinnamon version 6.6.9) Kernel: 7.0.0-38-generic Display Server: X11 Wine info: Wine running in Windows 8.1 mode Allow window manager to decorate the windows is enabled Allow the window manager to control the windows is enabled Tablet model: Wacom Intuos Pro (PTH-660) -- 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 59682] New: Windrose server: UDP bind to specific IPv4 behaves like 0.0.0.0%iface, causing wrong source IP and multihoming conflicts
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=59682 Bug ID: 59682 Summary: Windrose server: UDP bind to specific IPv4 behaves like 0.0.0.0%iface, causing wrong source IP and multihoming conflicts Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)list.winehq.org Reporter: koekdendeniz(a)gmail.com Distribution: --- A Windows dedicated server application (WindroseServer-Win64-Shipping.exe) works correctly on native Windows, where binding to a specific IP via -Multihome=<IP> results in UDP sockets bound to that IP:PORT. Under Wine on Linux, the same server appears to bind correctly in Wine debug logs, but the resulting Linux UDP socket shows up as 0.0.0.0%iface:PORT instead of IP:PORT. This causes two problems: 1. Outgoing UDP replies use the wrong source IP (the host's main IP instead of the IP passed to -Multihome). 2. Multiple instances cannot use the same UDP port on different local IPs, because the socket effectively behaves like 0.0.0.0:PORT instead of IP_A:PORT and IP_B:PORT. Tested with: * host networking * multiple public IPv4 addresses assigned on the same host * command line using -Multihome=<IP> Expected result: UDP socket is bound to the specific IPv4 address, replies use that source IP, and multiple instances can bind the same UDP port on different local IPs. Actual result: UDP socket appears as 0.0.0.0%iface:PORT, replies use the wrong source IP, and same-port multi-IP hosting fails. -- 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