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

[Bug 58972] New: error in mgest (gdiplus and C++ 2003 libraries)
by WineHQ Bugzilla 24 Feb '26

24 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=58972 Bug ID: 58972 Summary: error in mgest (gdiplus and C++ 2003 libraries) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)list.winehq.org Reporter: grandrodri3(a)gmail.com Distribution: --- Created attachment 79681 --> http://bugs.winehq.org/attachment.cgi?id=79681 error on terminal with mgest program Hey guys, I was looking at CRM and accounting programs and I happened to want to try this program called mgest (download link at the end of this report), but it's giving me an error (the Wine debugger pops up on both Windows 10 and 11). Looking at the libraries, it has gdiplus and libraries from the old C++ 2003. I tried installing C++ through winetricks but got a decompression error. Any ideas on how to get this program to run? And... could you take a look at it? Cheers download of mgest: http://mgest.com/formulario-de-descarga-mgest-lite/ -- 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 2

[Bug 59333] New: VNyan leaks memory (race in __wine_syscall_dispatcher $rsp switching breaks Unity GC)
by WineHQ Bugzilla 24 Feb '26

24 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=59333 Bug ID: 59333 Summary: VNyan leaks memory (race in __wine_syscall_dispatcher $rsp switching breaks Unity GC) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: lina(a)lina.yt Distribution: --- Created attachment 80270 --> http://bugs.winehq.org/attachment.cgi?id=80270 Debug & gdb logs VNyan (https://suvidriel.itch.io/vnyan) under recent versions of Wine starts leaking memory at a random time (from minutes to hours after startup). It took a few days of debugging and reverse engineering, but I tracked this down to an issue with Unity's GC observing a weird stack switch in Wine. For reference, Proton 8-5 seems to be fine and GE Proton 10-15 triggers the problem. The problem reproduces with plain `wine-11.0 (Staging)` (wine-11.0-2.fc43.x86_64 from Fedora 43), which is what I used for the traces in this bug. This is the Win32 threads code in the Unity fork of bdwgc: https://github.com/Unity-Technologies/bdwgc/blob/unity-master/win32_threads… Normally, bdwgc will use SuspendThread() on all application threads (see GC_suspend()) and then call GetThreadContext() to retrieve the thread context. It then uses the sp value to determine which stack segment to mark as roots for GC. The logic is complex and there is a safety check in case sp is out of bounds (then it collects the whole stack). However, on line 1695 above, sp is blindly subtracted from thread->stack_base and used to compute the stack usage in bytes, without any bounds checks. This means that when sp ends up above the stack, the subtraction overflows and returns a bogus huge stack size. This ends up throwing off the GC collection threshold, and the GC never runs again. During a normal stop-the-world GC ([1] in vnyan_debug.txt), all threads are stopped with $rip in Windows code (0x00006fffffxxxxxx) (other than the main thread which is in 0x000000018xxxxxx because I patched the Mono DLL to not relocate, for consistent debugging). Most threads are in NtWaitForSingleObject or NtWaitForAlertByThreadId, a couple in NtDelayExecution/NtNotifyChangeKey/NtUserMsgWaitForMultipleObjectsEx/NtWaitForMultipleObjects, and two threads in a mmdevapi wine_unix_call(). When the bug occurs, one thread is caught in the middle of UNIX code ([2] in vnyan_debug.txt). The stack pointer changes from this (pre-bug): Thread 82 (Thread 32.0x2c0): $201 = 0x7a8bf3e8 To this (during bug): Thread 82 (Thread 32.0x2c0): $295 = 0x12938eab0 The GC logs this warning (needs patches to enable debug logs): --> Marking for collection #2607 after 3617216 allocated bytes Marked from 150 dirty pages GC Warning: Thread stack pointer 000000012938EAB0 out of range, pushing everything Pushed 34 thread stacks And then the GC stops working. In the particular repro logged, rip is pointing here in __wine_syscall_dispatcher (it's usually within a few instructions of this area): https://github.com/wine-mirror/wine/blob/db11d0fe6a169c457e23d007e20404643d… This means that is_inside_syscall() returned false and allowed the thread state to be captured directly from native thread state. This is defined as: static inline BOOL is_inside_syscall( ULONG_PTR sp ) { return ((char *)sp >= (char *)ntdll_get_thread_data()->kernel_stack && (char *)sp <= (char *)get_syscall_frame()); } Just a few lines before the instruction the thread was stopped in: "leaq 0x70(%rcx),%rsp\n\t" /* %rsp > frame means no longer inside syscall */ Indeed, %rsp as seen by the user app is 0x70 into syscall_frame (which is 0x12938ea40). Later in the function the stack is switched to the proper user stack: /* switch to user stack */ "movq 0x88(%rcx),%rsp\n\t" I believe when a thread is stopped in the entire range between those two instructions, user code can observe %rsp set to a bogus value that should not be possible. This code was moved around by commit 245e8cedf059 and previously introduced by 0a5f7a71036. I'm not sure why %rsp is being set to point into &frame->rip instead of simply restoring it to the user stack pointer earlier. -- 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 44

[Bug 15346] New: Winamp disappears when you move it's location
by wine-bugs＠winehq.org 24 Feb '26

24 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=15346 Summary: Winamp disappears when you move it's location Product: Wine Version: 1.1.5 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: homerhomer(a)gmail.com Created an attachment (id=16178) --> (http://bugs.winehq.org/attachment.cgi?id=16178) DwmSetWindowAttribute error Sort of a silly bug, basically once winamp is up and running, if you click on the title bar and move it around winamp disappears. To make sure that the bug happens make sure to swirl it around a couple of times. ( A Swirly if you will ) Attached I also noticed this when running winamp manually at startup. This may be related. but then I move winamp and it disappears I don't get any more error messages. So I'm not sure. I appreciate the good work Thank you I'm running Ubuntu 8.04, Wine 1.1.5, AMD64 -- 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 48

[Bug 49583] New: Assassin's Creed Odyssey displays black bars on top and bottom.
by WineHQ Bugzilla 24 Feb '26

24 Feb '26

https://bugs.winehq.org/show_bug.cgi?id=49583 Bug ID: 49583 Summary: Assassin's Creed Odyssey displays black bars on top and bottom. Product: Wine Version: 5.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: GloriousEggroll(a)gmail.com Distribution: --- Created attachment 67739 --> https://bugs.winehq.org/attachment.cgi?id=67739 AC Odyssey black bar fix It's been a long known issue that AC: Odyssey renders with black bars on the top and bottom of the screen (see screenshot 1). Derek Lesho came up with a stub patch that both fixed this -and- allowed STEEP to run (it would not display previously). That patch can be found here: https://github.com/GloriousEggroll/proton-ge-custom/blob/5.12-GE-1/patches/… Recently, the relevant function QueryDisplayConfig was implemented, however it did not contain some of the changes Derek's patch adds. This allowed steep to work, however AC: Odyssey still retained the black bar issue. I modified Derek's patch by adding the relevant parts to QueryDisplayConfig, and removing the relevant flag checks (Derek's patch did this previously), and this allowed AC: Odyssey to render properly without the black bars. (see screenshot 2). The patch is hacky but may provide more information towards fixing this properly. -- 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 49393] New: Gag game crash
by WineHQ Bugzilla 24 Feb '26

24 Feb '26

https://bugs.winehq.org/show_bug.cgi?id=49393 Bug ID: 49393 Summary: Gag game crash Product: Wine Version: 5.10 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)winehq.org Reporter: axet(a)me.com Distribution: --- Hello! I'm trying to run 'Gag' game. And it's crashing winmm reading at zero memory address. I've tested few wine versions 5.0.0 .. 5.10 and all have same issue. https://en.wikipedia.org/wiki/GAG_The_Impotent_Mystery If you want trying to run the game, you gonna need start X server with 16-bit display like this: Xephyr :1 -ac -screen 800x600x16 & Crash output: 5.10 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x639d7db6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:639d7db6 ESP:016cf7c0 EBP:00000001 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:00ca3e08 ECX:016cf760 EDX:000001d0 ESI:00000000 EDI:014afb1c Stack dump: 0x016cf7c0: 009b38b8 639ec090 00000001 00000000 0x016cf7d0: 00ca3e24 00000000 00000000 639d85b5 0x016cf7e0: 00ca3ed4 00000008 000000e8 7ea09ea0 0x016cf7f0: 00000001 016cf810 016cf8cc 016cf820 0x016cf800: 0000001c 7ffc4000 0000003f 00ca0cf0 0x016cf810: 00ca0cf0 016cf830 639efe20 00ca3e08 Backtrace: =>0 0x639d7db6 EntryPoint+0xffffffff() in winmm (0x00000001) 1 0x639d8688 EntryPoint+0xffffffff() in winmm (0x00ca3ed4) 2 0x639da5b9 EntryPoint+0xffffffff() in winmm (0x016cf918) 3 0x7ea1bd0c in user32 (+0x9bd0b) (0x016cf918) 4 0x7ea1c35d in user32 (+0x9c35c) (0x016cf968) 5 0x7ea1e5a3 in user32 (+0x9e5a2) (0x016cf9b8) 6 0x7e9db0f2 in user32 (+0x5b0f1) (0x016cfa28) 7 0x7e9dd6c7 in user32 (+0x5d6c6) (0x016cfe48) 8 0x7e9e32df in user32 (+0x632de) (0x016cfea8) 9 0x639d9949 EntryPoint+0xffffffff() in winmm (0x016cff5c) 0x639d7db6 EntryPoint+0xffffffff in winmm: cmpw $1,0x0(%eax) 5.0.0 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x639d7b36). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:639d7b36 ESP:0127f700 EBP:00000001 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:0089e300 ECX:0127f6a0 EDX:0089e678 ESI:00000000 EDI:0105fb0c Stack dump: 0x0127f700: 0089c3c8 639eb090 00000001 00000000 0x0127f710: 0089e31c 00000000 00000000 639d8335 0x0127f720: 0089e3cc 00000008 000000e8 0127f750 0x0127f730: 0000000c 00030038 0127f768 7e925c50 0x0127f740: 7ea78cc0 7ffc4000 0000003f 0089c9f0 0x0127f750: 0089c9f0 0127f770 639eee20 0089e300 Backtrace: =>0 0x639d7b36 EntryPoint+0xffffffff() in winmm (0x00000001) 1 0x639d8408 EntryPoint+0xffffffff() in winmm (0x0089e3cc) 2 0x639da339 EntryPoint+0xffffffff() in winmm (0x0127f858) 3 0x7e93863c in user32 (+0xa863b) (0x0127f858) 4 0x7e938cad in user32 (+0xa8cac) (0x0127f8a8) 5 0x7e93b113 in user32 (+0xab112) (0x0127f8f8) 6 0x7e8f635e in user32 (+0x6635d) (0x0127f968) 7 0x7e8f8a7f in user32 (+0x68a7e) (0x0127fe38) 8 0x7e8fedca in user32 (+0x6edc9) (0x0127fe98) 9 0x639d96c9 EntryPoint+0xffffffff() in winmm (0x0127ff4c) 0x639d7b36 EntryPoint+0xffffffff in winmm: cmpw $1,0x0(%eax) -- 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 4

[Bug 58505] New: Odd windows management behaviour in later dev versions
by WineHQ Bugzilla 24 Feb '26

24 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=58505 Bug ID: 58505 Summary: Odd windows management behaviour in later dev versions Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kg.hammarlund(a)gmail.com Distribution: --- I run a geneaology database program written for windows under wine. It runs fine on v10.0 (stable) and on dev versions up to 10.4. From v10.5 and upwards, including v1012, I'm encountering an odd issue. When opening a search window, this window opens in the background instead of on top of the main window. I then have to move or resize the main window in order to highilght the search window and fill in the search data. But this only happens the first time I open the search window. Next time it opens in the foreground. If I untick the box "Allow the window manager to control the windows" in winecfg > graphics, the search window opens expected. But this solution has its drawbacks. -- 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 27

[Bug 58325] New: wined3d swapchain use-after-free
by WineHQ Bugzilla 24 Feb '26

24 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=58325 Bug ID: 58325 Summary: wined3d swapchain use-after-free Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: yshuiv7(a)gmail.com Distribution: --- Releasing the swapchain brings us to wined3d_swapchain_cleanup, which destroys the front/back buffer textures. Texture destruction is async, happening on the device's command stream. This means these textures can be destroyed way after the swapchain itself. But we did set `texture->swapchain` to `NULL` before queuing their destruction, so that bit is fine. The problem is in texture_resource_unload. Here we try to acquire the context, which goes adapter_gl_acquire_context -> wined3d_context_gl_acquire -> wined3d_context_gl_activate -> wined3d_context_gl_update_window. And here we try to access `context_gl->c.swapchain->win_handle`, which unfortunately points to the swapchain that was just freed. I am unsure what's the fix for this. Do we hold a refcount of the swapchain in the context? Do we clear `context->swapchain` when a swapchain is being freed? Should we release the front/back buffer synchronously? Or something else? -- 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 3

[Bug 45882] New: (Overwatch, several source games) Raw Mouse input not working
by wine-bugs＠winehq.org 24 Feb '26

24 Feb '26

https://bugs.winehq.org/show_bug.cgi?id=45882 Bug ID: 45882 Summary: (Overwatch, several source games) Raw Mouse input not working Product: Wine Version: 3.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: florian98.rg(a)gmail.com Distribution: --- Playing Overwatch I've noticed that the game still uses mouse pointer speed even though on Windows it uses Raw Mouse input exclusively. I've tried this on any branch of Wine (staging, esync, whatsoever) and the problem still persists. This also happens in Valve games where you can enable Raw Mouse Input, e.g. Team Fortress 2 etc. This does not happen with the native ports of said games that use SDL to get mouse input. I already disabled any mouse acceleration in GNOME whatsoever (using the "Flat" Profile), however the problem persists. Is it possible to rewrite Wine to get Mouse input via SDL2 instead? That would help pave way for Wayland etc. Thanks -- 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 34

[Bug 46534] New: Just Cause 4 crashes on startup
by wine-bugs＠winehq.org 24 Feb '26

24 Feb '26

https://bugs.winehq.org/show_bug.cgi?id=46534 Bug ID: 46534 Summary: Just Cause 4 crashes on startup Product: Wine Version: 4.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ramy0zahran(a)gmail.com Distribution: --- Created attachment 63387 --> https://bugs.winehq.org/attachment.cgi?id=63387 JC4backtrace Unhandled exception: page fault on read access to 0xffffffffffffffff in 64-bit code (0x0000000141926167). -- 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 19

[Bug 53574] New: MSYS2 "pacman -Sy" fails key lookup
by WineHQ Bugzilla 23 Feb '26

23 Feb '26

https://bugs.winehq.org/show_bug.cgi?id=53574 Bug ID: 53574 Summary: MSYS2 "pacman -Sy" fails key lookup Product: Wine Version: 7.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: joel(a)airwebreathe.org.uk Distribution: --- Created attachment 72951 --> https://bugs.winehq.org/attachment.cgi?id=72951 Log of console interaction With a fresh Msys2 installation, pacman fails to run, because it keeps producing "key lookup failed" errors. The user is prompted to with the following message: error: mingw32: key "5F944B027F7FE2091985AA2EFA11531AA0AA7F57" is unknown :: Import PGP key 5F944B027F7FE2091985AA2EFA11531AA0AA7F57? [Y/n] Y However, if the user selects "yes", pacman simply asks the same question again after a short delay, in an infinite loop. -- 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 6