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

[Bug 59342] Roblox Studio crashes when typing ASCII symbols in search bar of "Find in Place" window when RegEx is enabled

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59342 Andrew Nguyen <arethusa26(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |msvcp -- 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.

Jan. 31, 2026

[Bug 47486] GsView draws one menu item with white background

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=47486 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://jira.reactos.org/br | |owse/CORE-13935 | --- Comment #10 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to KRosUser from comment #9) > A good fix is available here : > https://github.com/reactos/reactos/commit/ > 076699bff6a8c80668f670d8e39952f1590a19d3 You've been asked multiple times already to stop posting reactos references 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.

Jan. 31, 2026

[Bug 47486] GsView draws one menu item with white background

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=47486 --- Comment #9 from KRosUser <kyle.kcsoftwares(a)gmail.com> --- A good fix is available here : https://github.com/reactos/reactos/commit/076699bff6a8c80668f670d8e39952f15… -- 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.

Jan. 31, 2026

[Bug 59338] Menus fail to display after closing child dialog in DAZ Studio 4.24.0.4 (Qt popup recreated but not mapped/shown)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59338 --- Comment #3 from William Korb <korb(a)qisc.com> --- I should mention that the 21.3 -> 22.3 upgrade changed the current configuration to be as follows: - Wine: wine-11.1 (apt install --install-recommends winehq-devel) - OS: Linux Mint 22.3 Cinnamon X11 w/ all latest updates applied - Kernel: 6.8.0-94-generic - GPU: NVIDIA 590.48.01 driver - App: DAZ Studio 4.24.0.4 base install -- 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.

Jan. 31, 2026

[Bug 59333] VNyan leaks memory (race in __wine_syscall_dispatcher $rsp switching breaks Unity GC)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59333 --- Comment #9 from Hoshino Lina <lina(a)lina.yt> --- I was thinking about the "masking" USR1 and... I guess I was confused about the meaning. Since USR1 is just a normally handled signal, I guess it would be sufficient to just check if %rip is inside the syscall dispatcher and just set a flag and return? Then the syscall handler itself can check the flag, and if set, jump to the rest of the USR1 handling code. You'd need some subtlety around "carving out" the check itself so it would go something like: - Between start of __wine_syscall_dispatcher and loading the flag, do the above - After the flag is loaded, and before jumping into the syscall, just handle it normally in the signal handler (considered "in syscall"). - If it's after syscall return and back in __wine_syscall_dispatcher, perhaps the easiest thing to do is just have the USR1 handler alter the signal return context to restart the syscall return path (you'd have to ensure the syscall return code is idempotent with respect to user state). This only really matters if the context is allowed to be modified by another thread "during" a syscall. -- 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.

Jan. 31, 2026

[Bug 59338] Menus fail to display after closing child dialog in DAZ Studio 4.24.0.4 (Qt popup recreated but not mapped/shown)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59338 --- Comment #2 from William Korb <korb(a)qisc.com> --- I upgraded my system to Linux Mint 22.3 (Ubuntu 24.04 base) because some users on the Daz forum have suggested this doesn't happen on 22.3, but I am still seeing it. Confirmed reproduces on latest wine-devel (11.1) in a completely clean prefix (wineboot --init only, no DLL overrides, no env vars, no nvidia-libs, no custom tweaks) with base DAZ Studio 4.24.0.4 installed (no content libraries). Repro still: Window → Workspace → Select Layout... → Cancel → Window menu fails to appear on next click. This removes any possibility of prefix cruft or overrides causing it. Happy to provide new log from this upgraded setup or test bisect builds/patches. -- 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.

Jan. 31, 2026

[Bug 59341] dynamic link library error?

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59341 Andrew Nguyen <arethusa26(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Nguyen <arethusa26(a)gmail.com> --- Bottles is not an official Wine tool, so issues with Bottles are not in scope for the Wine bug tracker. That said, I would guess that the reason you are running into the issue in bug 56709 that is already fixed in upstream Wine is presumably because Bottles is running your application with a custom Wine fork (which we do not support here) that does not include the fix. Bottles is probably also not using the Wine 11.1 installation in Arch you mentioned. Please refer to the support channels for Bottles as a more appropriate place to address your issues using this tool. -- 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.

Jan. 31, 2026

[Bug 59343] Debian 13 (Trixie): winehq-stable depends on non‑installable wine-stable-i386 despite WOW64 support

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59343 Jullius Caeser <cg8g0s8wgwg4o404ooss48g04go8o4wo(a)ai.notifier.in> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cg8g0s8wgwg4o404ooss48g04go | |8o4wo(a)ai.notifier.in --- Comment #2 from Jullius Caeser <cg8g0s8wgwg4o404ooss48g04go8o4wo(a)ai.notifier.in> --- (In reply to Rosanne DiMesio from comment #1) > That is intentional. That's too bad to hear. Then please consider updating your Wiki: https://gitlab.winehq.org/wine/wine/-/wikis/Debian-Ubuntu because it is clearly misleading: "Add the repository: The WineHQ packages for Ubuntu 25.10 and Debian Testing (version 10.18 and up) are WoW64. ****Therefore, the 32-bit packages are no longer necessary****." Debian 10 is ages ago, current stable is Debian 13 Trixie. This is why I thought I can get WOW64 support from official winehq apt repository, even Debian APT does not offer yet. > Packages for forky are new WoW64, as are the ones for Ubuntu 25.10. Forky is sid and not ready for production, guess I need to wait until Debian Forky then. -- 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.

Jan. 31, 2026

[Bug 59340] Win32 streams support (filename:streamname:$DATA)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59340 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|ntoskrnl |ntdll --- Comment #1 from Zeb Figura <z.figura12(a)gmail.com> --- What doesn't work in these applications? -- 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.

Jan. 31, 2026

[Bug 59333] VNyan leaks memory (race in __wine_syscall_dispatcher $rsp switching breaks Unity GC)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59333 --- Comment #8 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to easyaspi314 from comment #7) > I mean I may be overlooking things, but uh... Is Wine actually checking > whether it is in a syscall when calling NtGetContextThread and returning > nonzero? I don't see it in any of the instances of where it sets the return > value. NtGetContextThread() is supposed to return a valid context while in a syscall. It's just that it's the context that will be restored on return to user mode, not the context of the kernel. -- 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.

Jan. 31, 2026