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

[Bug 60258] New: tuberank jeet bug 2026

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60258 Bug ID: 60258 Summary: tuberank jeet bug 2026 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: pocomal112(a)codverts.com Target Milestone: --- Distribution: --- I installed on bottle in linux a software by name TUBERANK JEET AI together with the software of windowsdesktop-runtime-10.0.10-win-x64 The whole installation worked smoothly without errors until I saw a problem with the launch. the software didnt launch and no bug report file to show you what bug. please fix it -- 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.

Aug. 31, 2026

[Bug 52254] Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #7 from Zhai Can <bczhc0(a)126.com> --- For the info the latest proton-ge has added a [patch] to winex11 so that the transparency can be displayed correctly, including the input region being handled correctly ([pr]). However it's only for winex11 and is implemented using top-level windows with XShape so it requires the xwayland server to handle them well (for example i tested with `kwin_wayland --xwayland` it works but for niri+xwayland-satellite the input-passthrough is still not working) [patch]: https://github.com/GloriousEggroll/proton-ge-custom/blob/53ed6068a99b68f12f… [pr]: https://github.com/GloriousEggroll/proton-ge-custom/blob/53ed6068a99b68f12f… -- 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.

Aug. 31, 2026

[Bug 52254] Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=52254 Wehrwolfmann <wehrwolfmann(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81972|text/x-csrc |text/plain mime type| | -- 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.

Aug. 30, 2026

[Bug 52254] Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #6 from Wehrwolfmann <wehrwolfmann(a)gmail.com> --- Created attachment 81973 --> http://bugs.winehq.org/attachment.cgi?id=81973 three runs on wine-11.16: DWM path and --no-dwm control (winex11.drv), plus the DWM path under winewayland.drv - all three identical -- 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.

Aug. 30, 2026

[Bug 52254] Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=52254 Wehrwolfmann <wehrwolfmann(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wehrwolfmann(a)gmail.com --- Comment #5 from Wehrwolfmann <wehrwolfmann(a)gmail.com> --- Created attachment 81972 --> http://bugs.winehq.org/attachment.cgi?id=81972 minimal d3d9 + DwmExtendFrameIntoClientArea test (--no-dwm gives the control run) Still a stub on wine-11.16. Comment 4 is right that these windows come out black - I wrote a smaller test than attachment 71378 to pin down where it actually breaks, so I am adding it here instead of filing a duplicate. Attached test, ~75 lines, d3d9 + dwmapi and nothing else: a plain WS_OVERLAPPEDWINDOW, DwmExtendFrameIntoClientArea() with MARGINS {-1,-1,-1,-1} (the documented "sheet of glass"), then a windowed D3D9Ex device with an A8R8G8B8 back buffer. Every frame it clears the client area to ARGB(0,0,0,0) and a 100x100 square in the middle to opaque green. --no-dwm skips the DWM call and changes nothing else - that is the control run. Per MSDN ("Custom Window Frame Using DWM") the extended frame shows wherever the underlying pixels have alpha 0, so the DWM run should be a green square floating over the desktop and the control run an ordinary opaque window. I have no Windows box here, so that half is what the docs say, not something I measured. On Wine the two runs are pixel-identical. I put a colourful picture behind the window; cropping the client rect out of both screenshots, compare -metric AE gives 0. Both are a solid black client area with the green square in it. dwmapi logs the stub and returns S_OK, so the app is told transparency is on, but xwininfo reports Depth: 24 on the X window even though the server advertises 32-bit visuals - there is no alpha channel to composite at all. winex11.drv only moves a window to argb_visual inside the "if (layered)" branch of X11DRV_CreateWindowSurface (dlls/winex11.drv/bitblt.c). Same black window under winewayland.drv, so this is not an X11-only thing. Build: x86_64-w64-mingw32-gcc dwm_alpha.c -o dwm_alpha.exe -ld3d9 -ldwmapi -lgdi32 Tested on wine-11.16 64-bit, clean prefix, winex11.drv on XWayland and winewayland.drv, Plasma 6.7.4 Wayland session, Mesa on NVIDIA. Besides the games in comment 4: desktop mascot apps built on the UniWindowController package take this same path and never call UpdateLayeredWindow, so they all draw as black boxes too. -- 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.

Aug. 30, 2026

[Bug 60257] New: win32u: send_mouse_motion() skips resetting raw_mouse.count on empty input, causing a heap buffer overflow

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60257 Bug ID: 60257 Summary: win32u: send_mouse_motion() skips resetting raw_mouse.count on empty input, causing a heap buffer overflow 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: GenShinigami(a)gmail.com Target Milestone: --- Distribution: --- Please note: I am not someone with the tech-knowledge to have done this alone, and want to be transparent that I have been using a LLM to assist in investigating and resolving it. I've tested the fix it has provided, and it has been working for me. Apologies for not providing something that I personally dug into and identified, and if providing LLM-generated finds is not allowed, I also apologize of that. This particular bug was found while using the Shadowrun 5e character creation app called "Chummer5a" wihch is a .NET character generator that I am running through WINE. accum_mouse_motion() in dlls/win32u/input.c accumulates raw mouse motion frames into a fixed 64-entry buffer (struct raw_mouse { UINT count; POINT data[64]; }, embedded in struct user_thread_info). When the buffer is about to overflow, it calls send_mouse_motion() to flush the accumulated input and reset the counter. send_mouse_motion() has an early-return optimization to skip sending genuinely empty input: static NTSTATUS send_mouse_motion( UINT flags ) { struct user_thread_info *info = get_user_thread_info(); INPUT input = info->mouse_motion; NTSTATUS status; if (!input.mi.dwFlags && !input.mi.mouseData) return STATUS_SUCCESS; /* ignore empty inputs */ TRACE( "Sending %s (%u raw frames)\n", debugstr_mouseinput( &input.mi ), info->raw_mouse.count ); status = server_send_hardware_message( info->mouse_hwnd, flags, &input, (LPARAM)&info->raw_mouse ); memset( &info->mouse_motion, 0, sizeof(info->mouse_motion) ); info->raw_mouse.count = 0; info->mouse_hwnd = NULL; return status; } The early return happens BEFORE info->raw_mouse.count = 0. If info->mouse_motion happens to be empty (dwFlags == 0 && mouseData == 0) at the exact moment accum_mouse_motion() calls this to flush an about-to-overflow buffer, the function returns without resetting the counter. The caller has no way to know the reset didn't happen, and proceeds to memcpy into the buffer and increment the counter anyway - now starting from a value that's already at (or past) capacity. Every subsequent raw mouse frame writes one slot further out of bounds. In our reproduction the counter reached 73 (9 slots, i.e. 72 bytes, past the 64-entry/512-byte buffer) before the overflow reached and corrupted session_data, a pointer field later in the same struct user_thread_info that's dereferenced on essentially every call into the shared message-queue code (get_shared_queue() and friends in dlls/win32u/winstation.c). Once that pointer is corrupted, the affected thread SIGSEGVs on every subsequent call to those functions, recovers, and retries - producing a CPU-pinned livelock rather than a clean crash, since Wine's own signal handler catches and recovers from the fault each time. Reproduction: we were not able to isolate a minimal, deterministic repro - it depends on the exact timing/sequence of real mouse input (specifically, a run of raw motion frames with no accompanying regular move/button/wheel data landing right as the 64-entry accumulator is about to overflow). In our case it surfaced as an intermittent CPU-pinning hang in a .NET application under Wine, recurring anywhere from under a minute to about ten minutes into a session, confirmed via a hardware watchpoint on the corrupted field across multiple independent captures (all showing the same raw_mouse.count pattern: 9 past capacity). Suggested fix: perform the accumulator reset (mouse_motion, raw_mouse.count, mouse_hwnd) unconditionally on every flush; only the actual send to wineserver should be skipped for empty input: static NTSTATUS send_mouse_motion( UINT flags ) { struct user_thread_info *info = get_user_thread_info(); INPUT input = info->mouse_motion; NTSTATUS status = STATUS_SUCCESS; if (input.mi.dwFlags || input.mi.mouseData) { TRACE( "Sending %s (%u raw frames)\n", debugstr_mouseinput( &input.mi ), info->raw_mouse.count ); status = server_send_hardware_message( info->mouse_hwnd, flags, &input, (LPARAM)&info->raw_mouse ); } memset( &info->mouse_motion, 0, sizeof(info->mouse_motion) ); info->raw_mouse.count = 0; info->mouse_hwnd = NULL; return status; } This preserves the original "don't bother telling wineserver about an empty input" optimization while guaranteeing the accumulator's own bookkeeping is always reset on a flush, closing the overflow path. We've built and run this fix locally (wine-staging 11.13) and confirmed it resolves the livelock - one hour of continuous use with zero recurrences, versus recurring every few minutes before the fix. -- 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.

Aug. 30, 2026

[Bug 29384] Multiple applications expect correct handling of WRITECOPY memory protection (Voobly fails to launch Age of Empires II, MSYS2)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=29384 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikrutrafal(a)protonmail.com --- Comment #94 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- *** Bug 54280 has been marked as a duplicate of this bug. *** -- 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.

Aug. 30, 2026

[Bug 54280] Deno crashes when opening it

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=54280 --- Comment #3 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- *** This bug has been marked as a duplicate of bug 29384 *** -- 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.

Aug. 30, 2026

[Bug 29384] Multiple applications expect correct handling of WRITECOPY memory protection (Voobly fails to launch Age of Empires II, MSYS2)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=29384 mikey9220(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikey9220(a)gmail.com --- Comment #93 from mikey9220(a)gmail.com --- I've been working on this for the Battle.net / CEF case (bug 53835) and have a working implementation that takes a different route than userfaultfd, so I'd like to check the direction here before opening an MR. The observation: Windows semantics for this are "the page is a private copy". The tests in kernel32/tests/virtual.c (the map_prot_written() loop) show that once a page has been copied on write, every later VirtualProtect reports the written protection, no matter what sequence of protections is applied. And the kernel already knows which pages are private copies: on Linux a written page of a MAP_PRIVATE file mapping shows up in /proc/self/pagemap as an exclusively mapped anonymous page, on macOS mach_vm_page_range_query reports it as copied. So the protection can be reported correctly by asking the kernel at NtProtectVirtualMemory / NtQueryVirtualMemory time, with no signal handlers, no EFAULT problems with syscalls writing into read-only pages, and no extra faults at runtime. The missing piece is that Wine itself writes to image pages while mapping them (ImageBase in the headers, relocations, the zeroed tail of sections), which makes them private copies before the application ever runs. Windows does that work in the kernel and shares the result. The patch moves those pages into an anonymous file after mapping and maps them back MAP_PRIVATE, so they read as clean copy-on-write pages again and only application writes show up as copies. Status: Battle.net's renderer passes its CHECK_EQ(PAGE_READWRITE) and the client works with no other hacks. ntdll:virtual passes, kernel32:loader and psapi are at their baseline, and the WRITECOPY todos in kernel32:virtual now pass (tested on macOS; the remaining failures there are pre-existing macOS issues and 16k page granularity artifacts). Views that are mapped shared still write through to the file, that part is untouched and stays todo. Zhiyi, does this conflict with your userfaultfd branch? As far as I can tell they solve different layers: pagemap/page query answers "has this page been copied", which is enough for the protection reporting, while uffd-wp would additionally catch writes that don't create a copy. If the read-back approach is acceptable I'll split it into an MR (three parts: image mapping, reporting, tests). -- 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.

Aug. 30, 2026

[Bug 46671] Biamp canvas crashes on startup

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=46671 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |53186cd7aafbfde0b30f8b048e3 | |1bc1558830045 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Great stuff. Thank you for testing. -- 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.

Aug. 30, 2026