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

[Bug 59797] New: List the current Bugzilla version in the `//*[@id="version"]` field.
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=59797 Bug ID: 59797 Summary: List the current Bugzilla version in the `//*[@id="version"]` field. Product: WineHQ Bugzilla Version: unspecified Hardware: Other OS: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: gugutyg4(a)rokejulianlockhart.addy.io CC: austinenglish(a)gmail.com Created attachment 81035 --> http://bugs.winehq.org/attachment.cgi?id=81035 A Demonstrative Duplicate Of `https://bugs.winehq.org/enter_bug.cgi?product=WineHQ%20Bugzilla` Currently, the version is greater than the latest, of 3.2.3, available: 1. ~~~ #!/usr/bin/env sh curl \ -H 'Content-Type: text/xml' \ --data '<?xml version="1.0"?> <methodCall> <methodName>Bugzilla.version</methodName> <params></params> </methodCall>' \ 'https://bugs.winehq.org/xmlrpc.cgi' | xmllint --xpath 'string(//member[name="version"]/value/string)' - ~~~ 2. > 4.4.13 -- 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 4

[Bug 60105] New: Crossrunner emulator crashes on loading a hard drive image file (Gentoo Linux)
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60105 Bug ID: 60105 Summary: Crossrunner emulator crashes on loading a hard drive image file (Gentoo Linux) Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: enkiferreiracosta867(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81656 --> http://bugs.winehq.org/attachment.cgi?id=81656 console output I installed the Crossrunner emulator for Apple IIGS (https://www.crossrunner.gs/) using the provided .msi file. The program runs fine, until I try to load ANY hard disk image (.hdv/.2mg) file, be it by clicking the `...` button, or even typing its path in the text field. That's when the crash happens, and, to make it even weirder, no meaningful message is shown in the console output, as you can see in the attachment. These "Ignoring stroke style" messages all appear when i simply just hover the text field for the drive image file. Wine 11.12 was compiled on Gentoo with the `X alsa custom-cflags gecko kerberos mingw opengl ssl strip truetype vulkan wayland wow64` USE flags. -- 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 3

[Bug 60114] New: Client fails to find shared session objects after the session mapping has grown, window class registration fails with error 1411
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60114 Bug ID: 60114 Summary: Client fails to find shared session objects after the session mapping has grown, window class registration fails with error 1411 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: Seth2313(a)gmail.com Target Milestone: --- Distribution: --- IN PLAIN WORDS Wine keeps user interface objects (window classes, windows, message queues) in a shared memory area that starts small and is supposed to grow as needed. Once it actually has to grow, the application side can no longer find objects that the wineserver created successfully just before - window class registration then fails with error 1411 and the application aborts. Making the area large enough that it never has to grow avoids the problem entirely, which is what points at the growth path as the culprit. SUMMARY After the shared session mapping has had to grow beyond its initial size, the CLIENT can no longer resolve session objects the SERVER has successfully allocated: find_shared_session_object() returns NULL although the server request succeeded and returned a valid locator. Window class registration then fails with ERROR_CLASS_DOES_NOT_EXIST (1411). Raising only the INITIAL size of the session mapping in server/mapping.c:create_session_mapping() from 512 to 32768 object_shm_t slots avoids the growth path entirely and makes the failure disappear permanently. ENVIRONMENT Wine: wine-staging 11.13 (also 11.9, 11.10, 11.11, 11.12) Application: FL Studio 2025 / 2026 (64-bit), large projects with many plugin instances Kernel: 7.1.3 (CachyOS), ntsync in use STEPS TO REPRODUCE 1. Run FL Studio with a stock wineserver. 2. Load a project large enough to create several thousand user objects (window classes, windows, message queues) - in practice a project with many plugin windows. 3. Loading fails with error 1411. Actual result: error 1411; in our case followed by an abort inside the application (c0000409). Expected result: project loads; the session mapping grows transparently. EVIDENCE: THE FAILURE IS ON THE CLIENT SIDE WINEDEBUG output at the moment of failure: err:class:NtUserRegisterClassExWOW Failed to get shared session object for window class That ERR is emitted in dlls/win32u/class.c:656, and the code path matters: SERVER_START_REQ( create_class ) { ... ret = !wine_server_call_err( req ); locator = reply->locator; /* server succeeded, locator valid */ atom = reply->atom; } SERVER_END_REQ; if (!ret) goto failed; /* not taken - server call was fine */ if (!(shared = find_shared_session_object( locator.id, locator.offset ))) { ERR( "Failed to get shared session object for window class\n" ); So the server allocated the object and returned its locator; only the client-side lookup in find_shared_session_object() (dlls/win32u/winstation.c:175) failed. It fails either because find_shared_session_block() could not map a block covering locator.offset, or because the id check "id == shared_object_get_id( object )" did not match. WHY THIS POINTS AT THE GROWTH PATH * Server side, the mapping is explicitly designed to grow: alloc_shared_object() -> find_free_session_block() -> grow_session_mapping() in server/mapping.c, which enlarges the backing file and maps the additional region. * Client side, find_shared_session_block() (dlls/win32u/winstation.c:145) walks the list of already mapped blocks and otherwise calls map_shared_session_block(), which re-opens \KernelObjects\__wine_session and maps a view at the granularity-aligned offset. * A larger INITIAL size cannot change any of this logic - it only ensures the growth path is never taken. That it reliably fixes the failure is the strongest indication that the defect lives in growing the mapping or in the client picking the growth up. One detail I noticed while reading, possibly harmless but it looks wrong: LIST_FOR_EACH_ENTRY( block, &session_blocks, struct session_block, entry ) if (block->offset < offset && offset + size <= block->offset + block->size) The first comparison is strict, so an object located exactly at block->offset is not recognised as covered by that block and an additional view gets mapped. "<=" looks like the intended comparison. WORKAROUND CURRENTLY IN USE --- a/server/mapping.c +++ b/server/mapping.c @@ -1425,7 +1425,7 @@ unsigned int attr, const struct security_descriptor *sd ) { static const unsigned int access = FILE_READ_DATA | FILE_WRITE_DATA; - size_t size = max( sizeof(*shared_session) + sizeof(object_shm_t) * 512, 0x10000 ); + size_t size = max( sizeof(*shared_session) + sizeof(object_shm_t) * 32768, 0x10000 ); size = round_size( size, host_page_mask ); return create_mapping( root, name, attr, size, SEC_COMMIT, 0, access, sd ); In continuous daily use across five Wine releases (11.9 -> 11.13) without any observed side effect. It requires rebuilding wineserver from matching sources after every Wine update, which is why a proper fix would be very welcome. RULED OUT BY TESTING ntsync, esync/fsync settings, and Wine version updates - the failure follows the session pool size and nothing else. AVAILABLE ON REQUEST A full WINEDEBUG=warn+win32u,+class log from a reproduction with the stock wineserver. The interesting lines would be "Failed to map session block for offset ..." from find_shared_session_block(), which would distinguish "could not map the block" from "id mismatch". Say the word and I will produce 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.

1 1

[Bug 60115] New: d2d_cdt_insert_segment() recurses without a global termination guard, stack overflow on degenerate geometry
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60115 Bug ID: 60115 Summary: d2d_cdt_insert_segment() recurses without a global termination guard, stack overflow on degenerate geometry Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d2d Assignee: wine-bugs(a)list.winehq.org Reporter: Seth2313(a)gmail.com Target Milestone: --- Distribution: --- IN PLAIN WORDS An application that draws complex vector graphics through Direct2D can kill Wine's main thread. A helper function in Wine's Direct2D triangulation code calls itself over and over without ever stopping when the input geometry is degenerate, until the 1 MB thread stack is used up and the process dies with a stack overflow. There is a safety check in the function, but it only guards a single call level, so it never fires. SUMMARY d2d_cdt_insert_segment() in dlls/d2d1/geometry.c:2287 recurses without a global termination guard. For degenerate geometry (collinear or duplicate vertices) the recursion oscillates between two origins and never terminates, exhausting the thread stack: EXCEPTION_STACK_OVERFLOW (0xC00000FD). The application's main thread dies while its audio threads keep running, so the process turns into a half-alive zombie rather than exiting. ENVIRONMENT Wine: wine-staging 11.9 when analysed; the affected code is byte-identical in 11.13 Application: FL Studio (64-bit) with two or more Serum 2 instances (JUCE/IPlug GUI drawing via Direct2D) d2d1: Wine builtin THE DEFECT static BOOL d2d_cdt_insert_segment(struct d2d_cdt *cdt, struct d2d_geometry *geometry, const struct d2d_cdt_edge_ref *origin, struct d2d_cdt_edge_ref *edge, size_t end_vertex) { for (current = *origin;; current = next) { ... if (<collinear case>) { d2d_cdt_edge_sym(&new_origin, &current); return d2d_cdt_insert_segment(cdt, geometry, &new_origin, edge, end_vertex); /* :2312 */ } if (d2d_cdt_rightof(...) && d2d_cdt_leftof(...)) { ... new_origin = *edge; return d2d_cdt_insert_segment(cdt, geometry, &new_origin, edge, end_vertex); /* :2335 */ } if (next.idx == origin->idx) { ERR("Triangle not found.\n"); return FALSE; } } } The only termination guard is "next.idx == origin->idx", which detects a full revolution around THE ORIGIN OF THE CURRENT INVOCATION. Both recursive calls at :2312 and :2335 enter with a NEW origin, so each level starts its guard from scratch. When the traversal cycles between two origins (A -> B -> A -> ...), no level ever completes a revolution, the guard never triggers, and the recursion is unbounded. EVIDENCE 1. Stack overflow (original code). With WINEDEBUG=+seh: code=c00000fd ... stack 0x108c0 (0x10000-0x11000-0x110000) i.e. the 1 MB thread stack is fully consumed. The main thread dies; the process stays alive because its audio threads are unaffected, which presents to the user as a total UI freeze. 2. The non-termination is real, not merely deep recursion. Both recursive calls are tail calls, so they can be rewritten as a loop ("origin = &new_origin; goto restart;") without any change in semantics. With that rewrite the stack overflow disappears and is replaced by an INFINITE LOOP: the thread spins at 100 % CPU with the instruction pointer stable inside d2d_cdt_insert_segment (RVA 0x2e9a3), confirmed with gdb across many samples. That rules out "recursion is merely too deep" and establishes non-termination. WORKAROUND IN USE HERE Tail-call elimination plus a generous iteration budget, bailing out the same way the existing "Triangle not found" path does: --- a/dlls/d2d1/geometry.c +++ b/dlls/d2d1/geometry.c @@ struct d2d_cdt_edge_ref base_edge, current, new_origin, next, target; size_t current_destination, current_origin; + unsigned int iterations = 0; +restart: for (current = *origin;; current = next) { + /* Guard against non-terminating cycles caused by degenerate geometry + * (e.g. collinear/duplicate vertices). The original code recursed here + * and died with a stack overflow; bail out and skip the segment instead. + * A correct segment insertion is O(edge_count), so a generous multiple + * of it is a safe upper bound that legitimate geometry never reaches. */ + if (++iterations > 16 * cdt->edge_count + 0x10000) + { + WARN("Iteration limit exceeded, skipping segment.\n"); + return TRUE; + } with both "return d2d_cdt_insert_segment(...)" calls replaced by "origin = &new_origin; goto restart;". This has been in daily production use since 2026-05 with no visible rendering artefacts. Note this returns TRUE (skip the segment and carry on) rather than FALSE. FALSE propagates up through d2d_cdt_insert_segments() and fails the whole tessellation, which in practice loses far more than the one bad segment. Which of the two is the right upstream behaviour is a call for the d2d1 maintainers - the important part is that the function must terminate. NO MINIMAL REPRODUCER The degenerate geometry is produced at runtime by a closed-source plugin GUI, so I cannot supply a small test case. A targeted test would presumably construct a path geometry containing duplicate and collinear vertices and tessellate it. I am happy to test any candidate patch against the real workload that triggers this reliably. -- 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 0

[Bug 60113] New: Deadlock between winex11.drv/Xlib and the OpenGL driver lock hangs multi-threaded GL application
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60113 Bug ID: 60113 Summary: Deadlock between winex11.drv/Xlib and the OpenGL driver lock hangs multi-threaded GL application Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: Seth2313(a)gmail.com Target Milestone: --- Distribution: --- IN PLAIN WORDS Two threads of the same application block each other forever. One of them is inside Wine's X11 code and needs the graphics driver; the other is inside the graphics driver and is waiting for an answer from the X server - an answer that has already arrived, but that only the first thread could pick up. Neither can move, the application hangs for good. The X server itself is perfectly healthy the whole time. SUMMARY Deadlock between winex11.drv/Xlib and the OpenGL driver's internal lock: a multi-threaded application using OpenGL hangs permanently, with the main thread holding an X11-related lock while blocked on the GL driver lock, and a second thread holding the GL driver lock while waiting for an X reply that can no longer be delivered. ENVIRONMENT Wine: wine-staging 11.13 (also seen on 11.9-11.12) Application: FL Studio 2026 (64-bit), Image-Line. OpenGL is loaded dynamically via LoadLibrary("opengl32.dll") GPU driver: NVIDIA 610.43.03 (open modules) Display: XWayland 24.1.13 under KWin 6.7.3 (KDE Plasma Wayland session) Kernel: 7.1.3 (CachyOS), ntsync in use Sync: WINEESYNC=1 WINEFSYNC=1, __GL_THREADED_OPTIMIZATIONS=0 Note that __GL_THREADED_OPTIMIZATIONS=0 was already set, so the NVIDIA threaded-optimization helper thread is NOT involved. SYMPTOM The application freezes completely and can normally only be terminated with "wineserver -k". The X server itself stays healthy the entire time and answers other clients immediately. This has occurred repeatedly over months; the analysis below is from one instance that was caught while still running. MEASURED STATE DURING THE HANG All 137 threads were parked; no thread in state R; zero CPU progress over several seconds. --- Thread A - main thread (TID == PID) --- /proc/PID/task/TID/syscall: 202 (futex) uaddr=0x7f0313fe58a0 op=0x80 (FUTEX_WAIT|PRIVATE) val=2 timeout=NULL pthread_mutex_t at 0x7f0313fe58a0, read from /proc/PID/mem: __lock=2 __count=1 __owner=19561 __nusers=1 __kind=1 (PTHREAD_MUTEX_RECURSIVE) Stack, obtained by scanning $rsp against the process mappings - gdb produces only "?? ()" for Wine processes. Innermost first: libc.so.6 <- libnvidia-glcore <- libGLX_nvidia <- libnvidia-glcore <- libGLX_nvidia <- libGL.so.1 <- libGLX_nvidia <- libGLX.so.0 <- libX11.so.6 <- libGLX.so.0 <- libX11.so.6 <- libGL.so.1 <- winex11.so <- win32u.so <- opengl32.so <- ntdll.so <- opengl32.dll Thread A additionally HELD a second, uncontended lock: 0x7f03e04d6240 __lock=1 __owner=<TID of thread A> __kind=0 (PTHREAD_MUTEX_NORMAL) in an anonymous mapping adjacent to winex11.so. I could not resolve this to a symbol - addresses are process-local and the process has since been restarted. --- Thread B - TID 19561, thread name "SmoothAnimation" --- /proc/PID/task/19561/syscall: 202 (futex) uaddr=0x5555946a1ce4 op=0x189 (FUTEX_WAIT_BITSET|PRIVATE|CLOCK_REALTIME) val=254 timeout=NULL val3=0xffffffff op=0x189 with FUTEX_BITSET_MATCH_ANY is glibc's pthread_cond_wait; the address is in [heap]. Stack: libc.so.6 <- libX11.so.6 <- libc.so.6 <- libGLX_nvidia <- libnvidia-glcore <- libGLX_nvidia <- libGLX.so.0 <- win32u.so <- winex11.so <- win32u.so <- opengl32.so <- ntdll.so <- opengl32.dll Thread B HELD the recursive mutex thread A was waiting for, plus a second recursive mutex at 0x7f023424f2c0 (__lock=1, __count=1) located in the mapping range of libGL.so.1 / libGLX.so.0, i.e. the GLX dispatch lock. --- X connection --- "ss -x -p" on the application's X11 socket showed 200 bytes sitting UNREAD in the receive queue while the process was hung. The X server was fully responsive to other clients (xdpyinfo from another process returned immediately). THE CYCLE Thread A (main): holds X11/winex11-related lock -> blocks acquiring GL driver lock Thread B: holds GL driver lock + GLX lock -> waits inside libX11 for an X reply The reply bytes had already arrived from the X server but nobody consumed them: the thread that would have dispatched them is thread A, which is blocked inside the GL driver. VERIFICATION OF THE DIAGNOSIS Releasing the GL driver mutex on thread B's behalf - writing __lock=__count=__owner=__nusers=0 and issuing FUTEX_WAKE - immediately resolved the hang: thread A acquired the mutex through the normal glibc path, the X socket receive queue drained to 0, thread B woke up, and the application continued running normally for over an hour afterwards. This confirms the cycle above rather than an external X stall. This is of course not a fix, just a demonstration. Thread B then continues without the lock it believes it holds; its later pthread_mutex_unlock fails cleanly with EPERM because glibc checks __owner. ANALYSIS / SUGGESTED DIRECTION winex11.drv appears to call into the GL/GLX stack while holding an internal lock that is also required to dispatch X replies. The GL driver in turn performs an X round trip while holding ITS lock. That is a lock-order inversion between two components that know nothing about each other, so it can only be resolved on the Wine side - e.g. by not holding the display/driver lock across calls into libGL, or by giving GL round trips a separate X connection. NOT AVAILABLE I do not have a minimal reproducer. The hang occurs sporadically in a large commercial application. The diagnostic path above is fully scriptable, though, so anyone hitting a similar hang can confirm the pattern in a few seconds: 1. cat /proc/PID/task/TID/syscall for the main thread -> futex address 2. read 20 bytes at that address from /proc/PID/mem -> __owner gives the holding TID. Works for PTHREAD_MUTEX_RECURSIVE and ERRORCHECK; NORMAL mutexes store no owner. 3. repeat for the holder to follow the chain Requires kernel.yama.ptrace_scope=0. I am happy to test any candidate patch against the workload that triggers this. -- 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 0

[Bug 58180] New: CaptureAge 1.17.1: fails to GetSharedHandle
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=58180 Bug ID: 58180 Summary: CaptureAge 1.17.1: fails to GetSharedHandle Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: eabesea(a)rambler.ru Distribution: Ubuntu Created attachment 78475 --> http://bugs.winehq.org/attachment.cgi?id=78475 captureage log When I run CaptureAge, it fails to start rendering. It appears that the fail is because dxgi_resource_GetSharedHandle is not implemented. I'm not attaching full wine terminal output since it's very large and appears to be mostly irrelevant. -- 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 58657] New: Reference to swapchain not removed when swapchain is destroyed
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=58657 Bug ID: 58657 Summary: Reference to swapchain not removed when swapchain is destroyed Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: gingyu02(a)gmail.com Distribution: --- While using OpenGL renderer,when a swapchain is removed,some references to it (such as surfaces,contexts) are not removed,resulting in a null pointer error when calling related fuctions. -- 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 1

[Bug 45364] New: Frostpunk
by wine-bugs＠winehq.org Aug. 2, 2026

Aug. 2, 2026

https://bugs.winehq.org/show_bug.cgi?id=45364 Bug ID: 45364 Summary: Frostpunk Product: Wine Version: 3.10 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hewanci(a)gmail.com Distribution: --- Frostpunk is so dark that it's unplayable due to not being able to see what's happening. Steam version Staging 3.10 Arch Linux There is already a bug about glitches but I doN't know how related that is: bug 45098 -- 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 29

[Bug 60108] New: Desktop wallpaper appears on top of applications
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=60108 Bug ID: 60108 Summary: Desktop wallpaper appears on top of applications Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: NEW Keywords: download, integration, source Severity: trivial Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: imwellcushtymelike(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81660 --> http://bugs.winehq.org/attachment.cgi?id=81660 Screenshot The Wine desktop wallpaper appears on top of applications. Sometimes the applications redraw to get rid of it, sometimes they don't. See screenshot. All I get from the console is: 00e8:fixme:event:X11DRV_ConfigureNotify synthetic event mapping not implemented wine reg add "HKCU\Control Panel\Desktop" /v Wallpaper /t REG_SZ /d "C:\wine.bmp" /f wine explorer /desktop=derp,800x600 winecfg -- 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 0

[Bug 59518] New: EGL device enumeration regression with NVIDIA 590
by WineHQ Bugzilla Aug. 2, 2026

Aug. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=59518 Bug ID: 59518 Summary: EGL device enumeration regression with NVIDIA 590 Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)list.winehq.org Reporter: ravxnz(a)proton.me Distribution: --- Created attachment 80542 --> http://bugs.winehq.org/attachment.cgi?id=80542 WINEDEBUG=+vulkan,+opengl,+wgl log Wine 11.4 chooses a broken libEGL device instead of falling back to a working one, causing breakage. Trace will show wine-staging, but it occurs on stable wine 11.4 as well. Mesa version: 2:26.0.2-2 NVIDIA version: 590.48.01-6 OS: Cachy-OS Programs I cannot use because of the error: - Clip Studio Paint - Wallpaper Engine - Any 32-bit application Some 64-bit applications warn but still run. This is technically a problem with the libEGL drivers in the newer NVIDIA and Mesa versions, but my other applications are falling back to working drivers instead, except for wine. -- 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 1