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

[Bug 59926] New: kernelbase: CharPrevA/CharPrevExA crash on NULL start pointer (MapleStory 216150 fails to launch)
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59926 Bug ID: 59926 Summary: kernelbase: CharPrevA/CharPrevExA crash on NULL start pointer (MapleStory 216150 fails to launch) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: f0rm4tm3(a)gmail.com Distribution: --- MapleStory (Steam app 216150) fails to launch under Wine: the process crashes with an access violation (0xc0000005) during startup. Root cause: CharPrevA() and CharPrevExA() in dlls/kernelbase/string.c dereference the start pointer in their loop condition without a NULL guard: LPSTR WINAPI CharPrevExA(WORD codepage, const char *start, const char *ptr, DWORD flags) { while (*start && (start < ptr)) /* crashes when start == NULL */ The game passes a NULL start pointer at launch, triggering the crash. CharPrevA() has the same bug. Suggested fix: return NULL early when start is NULL, matching how other kernelbase string helpers (e.g. StrChrA) already handle NULL input: if (!start) return NULL; while (*start && (start < ptr)) ... Reproduce: 1. Steam -> MapleStory (216150) under any recent Wine/Proton. 2. Launch -> process crashes at startup (0xc0000005 in kernelbase, inside CharPrevExA). Patch: two commits attached as git format-patch files (git am them): 1. kernelbase/tests: Add tests for CharPrevA. 2. kernelbase: Don't dereference NULL in CharPrevA/CharPrevExA. (I would have opened a merge request, but my gitlab.winehq.org account is awaiting validation and cannot fork; attaching the patch here instead.) -- 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 18

[Bug 59436] New: Wayland/EGL: Washed-out colors caused by double sRGB conversion on default framebuffer (GL_FRAMEBUFFER_SRGB)
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59436 Bug ID: 59436 Summary: Wayland/EGL: Washed-out colors caused by double sRGB conversion on default framebuffer (GL_FRAMEBUFFER_SRGB) Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: tpaniaki(a)protonmail.com Distribution: --- Created attachment 80417 --> http://bugs.winehq.org/attachment.cgi?id=80417 Patch Fixes https://bugs.winehq.org/show_bug.cgi?id=59073 Summary When running Wine with the Wayland driver (winewayland.drv) using EGL, colors may appear washed out / desaturated in OpenGL applications. The issue is caused by GL_FRAMEBUFFER_SRGB remaining enabled while rendering to the default framebuffer (FBO 0), leading to a double gamma/sRGB conversion in some Wayland/EGL pipelines. Disabling GL_FRAMEBUFFER_SRGB only when rendering to the default framebuffer fixes the color output. Environment Wine: wine-git (tested on 11.x, reproducible on current master) Backend: winewayland.drv (Wayland native, not XWayland) GPU: AMD (Mesa) Compositor: wlroots-based (qtile Wayland) EGL backend in use Application tested: Roon (Chromium/CEF-based UI, OpenGL rendering) Observed behavior Colors appear faded / washed out Gamma looks incorrect (as if double sRGB conversion occurs) Issue only occurs under Wayland/EGL Colors are correct: Under X11/XWayland Or if GL_FRAMEBUFFER_SRGB is manually disabled for FBO 0 Root cause hypothesis Some Wayland/EGL compositors already perform colorspace handling for the window surface. If GL_FRAMEBUFFER_SRGB remains enabled when rendering to the default framebuffer, the pipeline applies sRGB conversion twice: App → GL_FRAMEBUFFER_SRGB → EGL/Compositor colorspace → Display This results in desaturated output. Minimal fix Disable GL_FRAMEBUFFER_SRGB only when binding the default framebuffer (FBO 0), while preserving the application's requested sRGB state for non-default FBOs. Example patch (conceptual) Inside framebuffer binding path: if (!framebuffer && gl_info->supported[ARB_FRAMEBUFFER_SRGB]) { TRACE("glBindFramebuffer disabling GL_FRAMEBUFFER_SRGB on default framebuffer\n"); glDisable(GL_FRAMEBUFFER_SRGB); } else if (framebuffer && app_framebuffer_srgb_enabled) { TRACE("glBindFramebuffer restoring GL_FRAMEBUFFER_SRGB on non-default framebuffer\n"); glEnable(GL_FRAMEBUFFER_SRGB); } Results Colors become correct under Wayland/EGL No regression observed in tested OpenGL apps Behavior matches X11 output sRGB still works correctly for offscreen FBO rendering -- 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 60068] New: wminet_utils: implement GetErrorInfo()
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60068 Bug ID: 60068 Summary: wminet_utils: implement GetErrorInfo() Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs(a)list.winehq.org Reporter: tpaniaki(a)protonmail.com Target Milestone: --- Distribution: --- Created attachment 81575 --> http://bugs.winehq.org/attachment.cgi?id=81575 Patch Roon crashes during startup when querying information about attached volumes through `System.Management`. The crash is caused by the unimplemented `wminet_utils.dll.GetErrorInfo` export: ```text wine: Call from ... to unimplemented function wminet_utils.dll.GetErrorInfo, aborting ``` The resulting .NET stack trace includes: ```text System.Management.WbemErrorInfo.GetErrorInfo() System.Management.ManagementException.ThrowWithExtendedInfo(...) System.Management.ManagementObjectCollection.ManagementObjectEnumerator.get_Current() Sooloos.Broker.FileBrowser.VolumeAttached.GetInfoFromDrive(...) ``` The application then terminates through `System.Environment.FailFast`. The attached patch implements `wminet_utils.GetErrorInfo()` as a wrapper around `oleaut32!GetErrorInfo()`, adds the required `oleaut32` import, and replaces the stub export in `wminet_utils.spec`. After rebuilding Wine with this patch, Roon no longer crashes at this point and completes startup normally (in addition to https://bugs.winehq.org/show_bug.cgi?id=60067) -- 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 60012] New: HOTAS controlls by WinWing are not recognized and even aggresively mapped as some x-box controller.
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60012 Bug ID: 60012 Summary: HOTAS controlls by WinWing are not recognized and even aggresively mapped as some x-box controller. Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs(a)list.winehq.org Reporter: winehq.faculty027(a)simplelogin.com Target Milestone: --- Distribution: --- Created attachment 81432 --> http://bugs.winehq.org/attachment.cgi?id=81432 .patch containing commit with the fix Winebus may expose Winwing Orion flight hardware through SDL's synthesized gamepad path, which can produce an XInput-compatible device and hide axes or buttons available through the original HID reports. This happened to me with (only) Orion Joystick (rest was okay) for Star Wars Squadron game making it bugged controller. I had to go to Protontricks and change protons aggressive remaping by forcing WINEBUS\WINE_COMP_HID: Service -> Changed from xinput to winehid DeviceDesc -> Changed to Wine HID compatible device CompatibleIds -> Changed to WINEBUS\WINE_COMP_HID (was already there, but first line was something else) That fixed the issue, so it's also verified by me. This change uses winebus's existing hidraw preference mechanism so the raw HID interface wins during device arbitration. The VID:PID match also applies to every interface exposed by these composite USB devices. 4098:bea8 — Winwing Orion Joystick Base Metal 2 4098:bd64 — Winwing Orion Throttle Base II 4098:bef0 — Winwing Orion Combat Rudder Pedals !! In attachment I added `.patch` with commit that fix it. Tried it on github https://github.com/ValveSoftware/wine/pull/340 but it's not upstream. -- 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 59980] New: Final Fantasy XI Online: Unexpected Right Shift behaviour.
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59980 Bug ID: 59980 Summary: Final Fantasy XI Online: Unexpected Right Shift behaviour. Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: regression Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: chiitoo(a)gentoo.org Target Milestone: --- Regression SHA1: b8266e743e3477968208802c8b6b73f520f91396 Distribution: Gentoo After b8266e743e3 [1], right shift gains odd behaviour in Final Fantasy XI Online. Normally when either shift is being held down with an in-game menu open, pressing the arrow keys will move the camera. Without shift, the arrow keys will change the selection of the menu. It is also possible to get the key "stuck" when trying to do this, resulting in similar behaviour to when the Caps Lock is enabled, although sometimes neither of the shift keys will have effect on the casing after this starts. Repeating the actions, at least sometimes, restore the casing and the effect of either shift on the case, but in all cases it seems to be impossible to move the camera with the right shift pressed. I have not had the chance to test this on native Windows environment yet, nor Wayland, but I'd certainly be very surprised if this was the intended behaviour. Thank you! https://gitlab.winehq.org/wine/wine/-/commit/b8266e743e3477968208802c8b6b73… -- 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 25

[Bug 59898] New: Wine on aarch64 fails on linux with CONFIG_ARM64_VA_BITS=39
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59898 Bug ID: 59898 Summary: Wine on aarch64 fails on linux with CONFIG_ARM64_VA_BITS=39 Product: Wine Version: 8.11 Hardware: aarch64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader Assignee: wine-bugs(a)list.winehq.org Reporter: martin(a)martin.st CC: julliard(a)winehq.org Regression SHA1: ac1761d1dae8bf114a05e28ed6886deba6c2c860 Distribution: --- Since commit ac1761d1dae8bf114a05e28ed6886deba6c2c860, "loader: Build the preloader as PIE on 64-bit.", Wine on aarch64 fails on linux kernels that are configured with CONFIG_ARM64_VA_BITS=39. In my case, old and small SBCs have kernels built with CONFIG_ARM64_VA_BITS=39 (or CONFIG_ARM64_VA_BITS_39=y, which then sets CONFIG_ARM64_VA_BITS to that value). From https://github.com/raspberrypi/linux/blob/rpi-6.18.y/arch/arm64/configs/bcm…, it seems like even very recent configurations for raspberry pi 4 have this set, while kernels for raspberry pi 5 are configured with more virtual address bits. Before ac1761d1dae8bf114a05e28ed6886deba6c2c860, WINEPRELOADER_LDFLAGS contained "-Wl,-Ttext=0x7d400000". After that commit, if the "-static-pie" option isn't supported, WINEPRELOADER_LDFLAGS ends up containing "-Wl,-Ttext=0x7d7d00000000" instead. I.e. - previously, we set the text section address of 0x7d400000, while we now set 0x7d7d00000000. The former is a 31 bit address, while the latter is a 47 bit address. Kernels with CONFIG_ARM64_VA_BITS_39=y just immediately segfault if they try to execute a binary linked with -Ttext=0x7d7d00000000. Any virtual address with 39 bits or fewer works, while higher addresses won't work. Reversing the change, setting -Wl,-Ttext=0x7d400000, makes the binaries work fine (in brief testing) on such aarch64 linux devices. I'm not sure if there's any immediate drawbacks to it - but I guess it would be nice to set an address with less than 39 bits, at least for aarch64. -- 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 19

[Bug 60051] New: Input queue delivers hardware messages with garbage message IDs (0, 3, 0xffffffff), application deadlocks ("not responding") — regression in 11.13
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60051 Bug ID: 60051 Summary: Input queue delivers hardware messages with garbage message IDs (0, 3, 0xffffffff), application deadlocks ("not responding") — regression in 11.13 Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: ilkwon2(a)gmail.com Target Milestone: --- Distribution: --- Since upgrading wine-staging 11.12 → 11.13 (WineHQ Ubuntu repo), KakaoTalk (Windows messenger, version 26.6.0.5208, 32-bit, WINEARCH=win64 prefix) intermittently deadlocks a few minutes after startup. When it happens, the console/journal floods with: ``` 01b0:err:msg:process_hardware_message unknown message type ffffffff 0078:err:msg:process_hardware_message unknown message type 3 0024:err:msg:process_hardware_message unknown message type 0 ``` (thousands of occurrences within 2-3 minutes; the message ID value varies between runs: 0, 3, 0xffffffff — i.e. garbage), after which every thread of the process parks in futex waits (0% CPU) and the window stops responding to _NET_WM_PING. The corruption survives the app process: explorer.exe of the same prefix keeps logging the same error on every subsequent input event, and a relaunched app instance joining the same wine session hangs again immediately. Full recovery requires `wineserver -k`. **Trigger:** reproducibly correlated with opening a new window — in one captured case a chat window (richedit init + FlashWindowEx immediately before the flood), in another the built-in image viewer window. **Regression evidence:** systemd journal retention on this machine goes back to 2026-05-13. Grepping the whole journal for `process_hardware_message` yields ZERO hits from May 13 through July 22 (wine-staging 11.7 → 11.12, same KakaoTalk version since July 13, heavy daily use), and 28,792 hits on July 23 alone — the first day of real use after the 11.13 upgrade. 11.12 was in use for 16 days (2026-07-06 → 2026-07-22) without a single occurrence. Ruled out: KakaoTalkAdBlock (third-party window tool) — the hang reproduces with it completely absent from the process list. Possibly related: a MusicBee user reported the same signature ("err:msg:process_hardware_message unknown message type 0" flood + freeze) on 2026-07-20: https://discuss.cachyos.org/t/program-through-wine-freezing-or-closing-itse… Note: the commits "win32u: Ignore empty mouse input in NtUserSendHardwareInput" (9329917d) and "server: Skip dispatching rawinput message when it is empty" (e01ecb4a) are already included in 11.13, so they do not cover this path. **Environment details:** - winehq-staging 11.13~noble-1 (dl.winehq.org/wine-builds/ubuntu) - X11 (Xorg) session, fcitx IME (XMODIFIERS=@im=fcitx), X11 Driver InputStyle=root, UseTakeFocus=N - USB serial adapters present (/dev/ttyUSB0-2 mapped to COM33-35) - WINE_VK_WAYLAND_DISABLE=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.

1 5

[Bug 58112] New: Unimplemented function KERNEL32.dll.InitializeSynchronizationBarrier
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=58112 Bug ID: 58112 Summary: Unimplemented function KERNEL32.dll.InitializeSynchronizationBarrier Product: Wine Version: 10.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: git.ceeac(a)gmail.com Distribution: --- I am developing a cross-platform application that uses barriers as a synchronization primitive. This works fine when the application is started on Windows, however when started on Linux (Arch) + WINE (10.5), the application crashes with wine: Unimplemented function KERNEL32.dll.InitializeSynchronizationBarrier called at address 00006FFFFFC695E8 (thread 012c) Presumably, all of the following functions are unimplemented in WINE: - InitializeSynchronizationBarrier - DeleteSynchronizationBarrier - EnterSynchronizationBarrier -- 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 11595] New: wine application crashes if linux application changes a file it has open ( Notepad++)
by wine-bugs＠winehq.org Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=11595 Summary: wine application crashes if linux application changes a file it has open (Notepad++) Product: Wine Version: 0.9.54. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: tycho_lamerigts(a)yahoo.com - install notepad++ - start notepad++ - create new file - save file - modify saved file with a linux application (e.g. gedit) - switch focus back to notepad++, it sees the change, then freezes. -- 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 64

[Bug 60093] New: Unable to combine 32 bit arm with i386 emulation on aarch64
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60093 Bug ID: 60093 Summary: Unable to combine 32 bit arm with i386 emulation on aarch64 Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: martin(a)martin.st Target Milestone: --- Distribution: --- It's possible to build a combined "old wow64" setup with 32 bit arm and aarch64, by first installing an arm build into a prefix, and then installing an aarch64 build into the same prefix. With that build, it's possible to run armv7 and aarch64 executables with the same "wine" command/prefix. If the aarch64 build is configured with --enable-archs=aarch64,arm64ec - and the prefix has a working xtajit64.dll installed - we get one single wine install that can run armv7, aarch64, arm64ec and x86_64 binaries. If we further extend the aarch64 build with --enable-archs=aarch64,arm64ec,i386, and add both xtajit64.dll and xtajit.dll, we can execute aarch64, arm64ec, x86_64 and i386 binaries. But we no longer can execute armv7 binaries in the same setup. If we don't have i386 included, we end up with arm binaries in windows/syswow64, and executing the arm binaries works fine. If we do have i386 included and with a working xtajit.dll, we end up with i386 binaries in windows/syswow64, and executing arm binaries doesn't work. In order to have both working arm and i386, the arm binaries probably would need to be installed in windows/sysarm32 instead of windows/syswow64. -- 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