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

[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

[Bug 60063] New: shell32: SHBrowseForFolder crashes when an application passes an invalid BROWSEINFO.pidlRoot
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60063 Bug ID: 60063 Summary: shell32: SHBrowseForFolder crashes when an application passes an invalid BROWSEINFO.pidlRoot Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs(a)list.winehq.org Reporter: commoncargo(a)tutanota.com Target Milestone: --- Distribution: --- Created attachment 81568 --> http://bugs.winehq.org/attachment.cgi?id=81568 Backtrace A 32-bit application crashes when it opens the shell folder browser dialog. The process dies with a page fault inside shell32. Cause: the application fills its BROWSEINFOW with a plain CSIDL value instead of an item id list in the pidlRoot field. Disassembling the caller shows the BROWSEINFOW being built with the constant 0x11 (CSIDL_DRIVES) in the pidlRoot slot, ulFlags = BIF_RETURNONLYFSDIRS|BIF_STATUSTEXT, followed by the call to SHBrowseForFolderW. So the mistake is on the application side, but Windows does not crash on it. Wine dereferences the value immediately in InitializeTreeView (ILClone -> ILGetSize) and faults, making the dialog unusable. Windows 10 behaviour: the dialog is created and the process survives. Verified with a conformance test built from the Wine tree and run in a Windows 10 VM; the dialog opens and closes normally. How to reproduce without the application: Add a test to dlls/shell32/tests/brsfolder.c that calls SHBrowseForFolderA with bi.pidlRoot = (LPCITEMIDLIST)CSIDL_DRIVES and a callback that posts IDOK on BFFM_INITIALIZED. On Wine the test process dies with the page fault above; on Windows 10 it runs to completion. -- 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 60057] New: gdiplus: GdipCloneBitmapArea drops trailing pixels for 1bpp/4bpp bitmaps with non-byte-aligned width
by WineHQ Bugzilla Aug. 8, 2026

Aug. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60057 Bug ID: 60057 Summary: gdiplus: GdipCloneBitmapArea drops trailing pixels for 1bpp/4bpp bitmaps with non-byte-aligned width Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs(a)list.winehq.org Reporter: illienar2002(a)gmail.com Target Milestone: --- Distribution: --- When cloning a bitmap whose pixel format is less than 8 bits per pixel and whose width is not a whole number of bytes, the rightmost pixels of every row are not copied. They retain the destination bitmap's initial zero value, which typically renders as black. This issue affects PixelFormat1bppIndexed (loses width%8 columns) & PixelFormat4bppIndexed (loses 1 column if width is odd). How to reproduce: 1.Create a PixelFormat1bppIndexed bitmap of width 10, any height, with all pixels set to a non-zero palette index; 2. Clone it using GdipCloneBitmapArea(); 3. Read back the pixels of the clone. The resulting bitmap will have lost data in the last two columns of the image. This is caused by image.c convert_pixels() same-format path algorithm rounding down when calculating byte width of a row: UINT widthbytes = PIXELFORMATBPP(src_format) * width / 8; which should be easily fixable with: UINT widthbytes = (PIXELFORMATBPP(src_format) * width + 7) / 8; -- 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