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

[Bug 60514] New: ntdll: IL-only (.NET Framework) exe crashes when debugger injects thread into suspended process before main thread runs
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60514 Bug ID: 60514 Summary: ntdll: IL-only (.NET Framework) exe crashes when debugger injects thread into suspended process before main thread runs Product: Wine Version: 11.18 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: promonteiro89(a)icloud.com Target Milestone: --- Summary: loader_init() (dlls/ntdll/loader.c) handles an IL-only main module with: status = fixup_imports_ilonly( wm, NULL, entry ); which overwrites the start address (context->Rcx on x86_64) of whichever thread is the first thread to run loader_init with mscoree's _CorExeMain. That is only correct if the first thread is the main thread. If a debugger creates the process suspended and injects a thread before the main thread is resumed, that injected thread is the first to initialize the process and gets redirected to _CorExeMain. The real main thread later takes the else (thread attach) path and starts at the image's original entry point. For a 32-bit IL-only image (the usual AnyCPU .NET Framework console app) that entry is the PE32 stub "jmp dword ptr [abs32 IAT]". In a 64-bit process the slot holds garbage, so the thread jumps to a random non-canonical address and the process dies with 0xc0000005 (EXCEPTION_ACCESS_VIOLATION). How it was observed: Debugging a .NET Framework 4.8 AnyCPU console app (FxDemo.exe, PE32, ILONLY, entry stub at RVA 0x2712, image base 0x400000) under a debugger (tested with Visual Studio / vsdebugeng). The same program runs fine standalone, because there the main thread initializes the process first. - Under the debugger the main thread started at the unmodified entry point ("Starting thread proc 0000000000402712 (arg=000000010002D000)" in a +relay trace) and then faulted immediately: rip was a random 64-bit garbage value that changed on every run, the registers were still the initial thread context, and the exception was EXCEPTION_ACCESS_VIOLATION, info[0] = 8 (execute). - A different thread of the same process had initialized the process first (its PROCESS_ATTACH for mscoree.dll carried the process-init context) and was started at _CorExeMain with thread parameter 0. By inference, this was a thread injected from the debugger side whose original start address was not the exe entry point. - The debuggee had been created with CREATE_SUSPENDED. Root cause: The redirect to _CorExeMain is applied per "first thread to run loader_init" instead of per "thread that starts at the executable's entry point". Note on implementation pitfall: Do not compare against OptionalHeader.AddressOfEntryPoint directly. For IL-only PE32 images convert_to_pe64() zeroes it in the in-memory header, so the original entry point needs to come from ProcessImageInformation (SECTION_IMAGE_INFORMATION.TransferAddress). Suggested approach: - Record _CorExeMain and the original entry point (from SECTION_IMAGE_INFORMATION.TransferAddress); - Redirect a thread only if its start address equals the original entry point, in both the first-initializer path and the thread-attach path; - Clear the stored redirect once used. -- 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 60506] New: Garbled text in Pegasus Mail 4.80 and later (in messages and program help).
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60506 Bug ID: 60506 Summary: Garbled text in Pegasus Mail 4.80 and later (in messages and program help). Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: winebugtr074712(a)ikaa.net Target Milestone: --- Distribution: --- Pegasus Mail works perfectly in Wine up to its version 4.73 (included). From version 4.80 on, all textboxes (message reading, writing, and the program's help) display severely garbled text (this obviously doesn't happen under Windows). This issue happens on several Linux distros: (Devuan and Ubuntu) using Wine versions ranging from 8 (Devuan repo) to 11.0 (WineHQ-stable). There is 1 report of an old Fedora version using Wine 11.19-dev not having this problem. The components which have changed between those Pegasus Mail version are: Works - Pegasus Mail v4.73, March 2018: TER32 File Version 18.0.3.4 HTS32 File Version 13.0.0.1 Doesn't work anymore - Pegasus Mail v4.80, February 2022: TER32 File Version 29.0.0.0 HTS32 File Version 24.0.0.1 (Homepage of both: https://www.subsystems.com/) There is a longish thread on the Pegasus Mail forum which describes the problem and carries screenshots of what the garbled display looks like: https://community.pmail.com/index.php?u=/topic/12491/help-pegasus-on-linux-… To reproduce: 1. Download a copy of Pegasus Mail (https://www.pmail.com/downloads.htm) 2. Launch the installer. No need to actually install the program: 3. Just click on "Help" in the installer window and you'll see an example of the garbled text. -- 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 2

[Bug 60480] New: Small buffer sizes now yield choppy sound
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60480 Bug ID: 60480 Summary: Small buffer sizes now yield choppy sound Product: Wine Version: 11.19 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: --- After upgrading to Wine 11.19, I noticed that the audio in some of my programs was broken. First, it was on Neko Project 21/W. I had previously set the buffer size to 40 ms, the smallest it supports, and have been able to use it just fine. After the upgrade however, I had to bump that to 50. It may not be that big of a difference, but it still feels like a regression to me regardless. Then came FamiTracker. I had also set the audio buffer size there to 40 ms and was able to play things normally, until I upgraded. The buffer size now sits at 48 ms, because lower values make the audio really buggy. I'm using Wine's ALSA sound driver, and have been ever since I first installed it on my Gento system. I might wanna test the previous buffer size values with different drivers later on (have to recompile, ALSA is the only one I kept enabled). -- 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 34774] New: Crimson Skies crashes when a mission ends
by wine-bugs＠winehq.org Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=34774 Bug #: 34774 Summary: Crimson Skies crashes when a mission ends Product: Wine Version: 1.7.4 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: benpicco-wine(a)flauschlabor.de Classification: Unclassified Created attachment 46368 --> http://bugs.winehq.org/attachment.cgi?id=46368 Unhandled page fault on read access I've installed the game to a 32bit Windeprefix, installed quartz, Active Video and native amstream.dll and disabled winegstreamer so the game would launch. Everything works well, I can launch missions/instant action battles, but when they end and the game normally would go to a debriefing screen, it crashes instead. Last few lines of console output (abbreviated): fixme:dinput:LinuxInputEffectImpl_Download Could not upload effect. Assuming a disconnected device 45 "Invalid argument". fixme:dinput:joy_polldev joystick cannot handle type 21 event (code 1) fixme:dinput:LinuxInputEffectImpl_Download Could not upload effect. Assuming a disconnected device 45 "Invalid argument". fixme:dinput:LinuxInputEffectImpl_Download Could not upload effect. Assuming a disconnected device 45 "Invalid argument". wine: Unhandled page fault on read access to 0x06240000 at address 0x22022e0 (thread 0047), starting debugger... fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} -- 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 13

[Bug 60513] New: wininet: TCP keep-alive probe configuration and idle socket eviction across cellular CGNAT gateways
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60513 Bug ID: 60513 Summary: wininet: TCP keep-alive probe configuration and idle socket eviction across cellular CGNAT gateways Product: Wine Version: 10.0 Hardware: x86-64 URL: https://pxm2.io/mobile-proxies/4g-vs-5g-mobile-proxies / OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)list.winehq.org Reporter: info(a)neurobitlab.com Target Milestone: --- Distribution: --- When running Windows applications under Wine that perform persistent HTTP/S requests via WinINet or WinHTTP across mobile broadband WAN adapters (4G LTE / 5G USB cellular modems), pooled idle TCP connections frequently fail with ERROR_INTERNET_CONNECTION_RESET (12031) or ERROR_INTERNET_TIMEOUT (12002). Under RFC 6598 (Carrier-Grade NAT IPv4 Address Space) and mobile carrier network architectures, cellular middleboxes enforce strict translation session timeouts (often 30 to 60 seconds of inactivity). Standard Windows registry settings for KeepAliveTimeout (defaulting to 120s) exceed mobile carrier CGNAT session eviction windows. When WinINet reuses an evicted socket from its connection pool without an active keepalive probe having been acknowledged, the carrier gateway drops the outbound packet or returns a TCP RST. Configuring INTERNET_OPTION_SEND_TIMEOUT and setting SO_KEEPALIVE intervals below 30s prevents silent socket disconnection across cellular LTE/5G carrier pools. Technical references & network benchmarks: - Cellular 4G vs 5G modem throughput and TCP socket behavior benchmarks: https://pxm2.io/mobile-proxies/4g-vs-5g-mobile-proxies/ - Microsoft WinINet connection pooling documentation: https://learn.microsoft.com/en-us/windows/win32/wininet/managing-connection… - IETF RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space): https://datatracker.ietf.org/doc/html/rfc6598 - IETF RFC 7230 (HTTP/1.1 Message Syntax and Routing): https://datatracker.ietf.org/doc/html/rfc7230 -- 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 60495] New: NULL pointer crash in COMBOEX_NotifyEndEdit() when a ComboBoxEx item has empty/callback text
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60495 Bug ID: 60495 Summary: NULL pointer crash in COMBOEX_NotifyEndEdit() when a ComboBoxEx item has empty/callback text Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: tiagoascardoso(a)gmail.com Target Milestone: --- Distribution: --- Wine version: 11.19 (Staging) — also reproduced on 10.0 (Ubuntu repack) OS: Linux (Ubuntu 26.04), WoW64 Affected app: AutoShop V4.11.0.5 (Inovance PLC programming software, 32-bit, MFC 9.0 / VC90) --- Description: AutoShop.exe crashes with an unhandled EXCEPTION_ACCESS_VIOLATION (read from address 0) whenever the user interacts with a ComboBoxEx dropdown whose currently-selected item has NULL/empty text while the control is in active-edit mode and the dropdown closes. The crash is deterministic and 100% reproducible on this install. It was captured via the app's own minidump (dbghelp.dll-based crash handler) and resolved with winedbg against Wine's own debug info: Backtrace (winedbg against AutoShop.exe's own .dmp crash dump): =>0 0x7838f80e lstrcpynW+0x1c [include/winbase.h:2411] in comctl32 1 0x7838f80e COMBOEX_NotifyEndEdit+0x2e [dlls/comctl32/comboex.c:226] in comctl32 2 0x7838e2f4 COMBOEX_Command+0x4e4 [dlls/comctl32/comboex.c:1131] in comctl32 3 0x783911a5 COMBOEX_WindowProc+0x1265 [dlls/comctl32/comboex.c:2101] in comctl32 4 0x7a01a648 in user32 (+0xa648) ... (standard WndProc dispatch chain through user32 / mfc90u) ... --- Root cause: dlls/comctl32/comboex.c, COMBOEX_NotifyEndEdit() (line 222-236): static INT COMBOEX_NotifyEndEdit (const COMBOEX_INFO *infoPtr, NMCBEENDEDITW *neew, LPCWSTR wstr) { if (infoPtr->NtfUnicode) { lstrcpynW(neew->szText, wstr, CBEMAXSTRLEN); // line 226 — crashes if wstr == NULL ... Called from COMBOEX_Command(), line 1131: if (COMBOEX_NotifyEndEdit (infoPtr, &cbeend, COMBOEX_GetText(infoPtr, item))) return 0; COMBOEX_GetText() (line 291) returns item->pszText directly when it is not LPSTR_TEXTCALLBACKW: static LPCWSTR COMBOEX_GetText(const COMBOEX_INFO *infoPtr, CBE_ITEMDATA *item) { ... if (item->pszText != LPSTR_TEXTCALLBACKW) return item->pszText; ... item->pszText is legitimately NULL when the item was inserted with an empty string (InsertItemW only allocates pszText when the supplied text has non-zero length). COMBOEX_NotifyEndEdit() never checks wstr for NULL before handing it to lstrcpynW()/WideCharToMultiByte(), so any item with empty text that is active-edited and then has its dropdown closed (CBN_DROPDOWN path, oldflags & WCBE_ACTEDIT) crashes the process. --- Steps to reproduce: 1. Any app using a ComctlX ComboBoxEx control (CBS_DROPDOWN / WC_COMBOBOXEXW) that can insert an item with empty text (COMBOBOXEXITEMW.pszText = L"" or iImage-only item, cchTextMax 0). 2. Give the ComboBoxEx keyboard/edit focus (active-edit mode), then open and close its dropdown (e.g. click the dropdown arrow, or programmatically trigger CB_SHOWDROPDOWN) while that empty-text item is the current selection. 3. Wine crashes with STATUS_ACCESS_VIOLATION inside comctl32. A minimal repro using raw Win32/ComCtl32 API (InsertItemW with an empty pszText, then toggling the dropdown) should trigger it; I can only confirm against the third-party app above, not against a minimal test case, since I don't have a Windows machine to verify the behavior differs from real Windows. --- Suggested fix: --- a/dlls/comctl32/comboex.c +++ b/dlls/comctl32/comboex.c @@ -222,6 +222,8 @@ static INT COMBOEX_NotifyEndEdit (const COMBOEX_INFO *infoPtr, NMCBEENDEDITW *neew, LPCWSTR wstr) { + if (!wstr) wstr = L""; + /* Change the Text item from Unicode to ANSI if necessary for NOTIFY */ if (infoPtr->NtfUnicode) { lstrcpynW(neew->szText, wstr, CBEMAXSTRLEN); This mirrors how real Windows comctl32 appears to treat an empty-text item (as an empty string, not a NULL dereference) — defensive NULL handling at the single point where the untrusted text pointer enters this function is the minimal, safe 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.

1 2

[Bug 43461] New: NoLimits2 crashes on startup
by wine-bugs＠winehq.org Oct. 15, 2026

Oct. 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=43461 Bug ID: 43461 Summary: NoLimits2 crashes on startup Product: Wine Version: 2.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: directx-d3dx9 Assignee: wine-bugs(a)winehq.org Reporter: alt.stephan(a)web.de Distribution: --- Created attachment 58835 --> https://bugs.winehq.org/attachment.cgi?id=58835 Wine console messages While initializing, the program quits with a fatal error: The application failed with: D3DXAssembleShader return with an unexpected error. (see crash.png) Wine console log (crash.log) attached below, as well as the wine "crash detected" log (err_report.log). I tried with both UseGLSL enabled and disabled. -- 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 16

[Bug 60512] New: wmvread testcase: IWMReaderAdvanced::GetMaxOutputSampleSize() on the asynchronous WMVCore reader fails with E_NOTIMPL
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60512 Bug ID: 60512 Summary: wmvread testcase: IWMReaderAdvanced::GetMaxOutputSampleSize() on the asynchronous WMVCore reader fails with E_NOTIMPL Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: source, testcase Severity: normal Priority: P2 Component: wmp&wmvcore Assignee: wine-bugs(a)list.winehq.org Reporter: brunet.cyril(a)hotmail.com Target Milestone: --- Distribution: --- Created attachment 82371 --> http://bugs.winehq.org/attachment.cgi?id=82371 wmvread.c (testcase) Some video players open WMV/ASF files with the asynchronous WMVCore reader (WMCreateReader() + IWMReaderCallback) and call IWMReaderAdvanced::GetMaxOutputSampleSize() on the video output before starting playback, to size their buffers. In Wine this method of the asynchronous reader is a stub: fixme:wmvcore:WMReaderAdvanced_GetMaxOutputSampleSize (...)->(0 ...) It returns E_NOTIMPL (0x80004001) and leaves the size at 0. A player that checks the result stops there and never plays the file, although Wine can open and decode it: the testcase below plays the same file to the end right after the failed call. The synchronous reader already implements the equivalent IWMSyncReader::GetMaxOutputSampleSize(); only the asynchronous reader (dlls/wmvcore/async_reader.c) is missing it. Steps to reproduce: 1. Build the attached wmvread.c: x86_64-w64-mingw32-gcc -municode wmvread.c -lole32 -luuid -o wmvread.exe 2. Create a small WMV file: ffmpeg -f lavfi -i testsrc=size=640x360:rate=25 -f lavfi -i sine=frequency=440 -t 3 -c:v wmv2 -b:v 1M -c:a wmav2 test.wmv 3. wine wmvread.exe test.wmv Expected: GetMaxOutputSampleSize returns S_OK and the maximum size of the video output samples, as documented for IWMReaderAdvanced::GetMaxOutputSampleSize (not verified on Windows by me). Actual: IWMReaderAdvanced::GetMaxOutputSampleSize(0) hr 0x80004001, size 0 ... video samples 75, audio samples 65, other 0 Tested with wine-11.16-1379-g5b6b85421c2 (current git, after 11.19, unmodified, clean prefix, no DLL overrides) and with Wine 10.0 and 11.0: same result. Complete terminal output attached. I first saw this with a video application that plays WMV9 (WMV3) streams through this reader: it stops right after this call and plays nothing. GStreamer's WMV decoders are installed (gstreamer1.0-libav 1.28.2, avdec_wmv3 available), and the WMV3 stream does get decoded to I420 when the reader runs. System: Ubuntu 26.04.1 LTS x86_64, GStreamer 1.28.2 with plugins base/good/bad/ugly/libav. -- 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 60509] New: DwmEnableBlurBehindWindow is a stub: OpenGL windows with an alpha channel (Qt, GLFW transparent framebuffer) are drawn with an opaque black background
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60509 Bug ID: 60509 Summary: DwmEnableBlurBehindWindow is a stub: OpenGL windows with an alpha channel (Qt, GLFW transparent framebuffer) are drawn with an opaque black background Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwmapi Assignee: wine-bugs(a)list.winehq.org Reporter: brunet.cyril(a)hotmail.com Target Milestone: --- Distribution: --- On Windows, a window rendered with OpenGL can have a per-pixel transparent background: the application creates a pixel format with an alpha channel and calls DwmEnableBlurBehindWindow() on the window, and DWM then composites the window using the alpha channel of the back buffer. Pixels with alpha 0 show the desktop behind the window. Two common toolkits do this: - Qt 5 and Qt 6: for an OpenGL (or Vulkan) QWindow whose format has an alpha channel (for example a translucent QQuickWindow or a QOpenGLWidget with Qt::WA_TranslucentBackground), updateGLWindowSettings() in src/plugins/platforms/windows/qwindowswindow.cpp calls applyBlurBehindWindow(): blurBehind.dwFlags = DWM_BB_ENABLE | DWM_BB_BLURREGION; blurBehind.fEnable = TRUE; blurBehind.hRgnBlur = CreateRectRgn(0, 0, -1, -1); DwmEnableBlurBehindWindow(hwnd, &blurBehind); - GLFW 3.3/3.4 with the GLFW_TRANSPARENT_FRAMEBUFFER window hint: updateFramebufferTransparency() in src/win32_window.c makes the same call with the same empty region. In Wine, DwmEnableBlurBehindWindow() is a stub that returns E_NOTIMPL: fixme:dwmapi:DwmEnableBlurBehindWindow 0x... 0x... The alpha channel of the OpenGL back buffer is ignored and the window is shown with an opaque background: every pixel that should be transparent is drawn black. Desktop overlays, mascots, widgets and HUD-style applications built with these toolkits are affected. Steps to reproduce (GLFW): 1. Build a GLFW program that sets glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE) and glfwWindowHint(GLFW_DECORATED, GLFW_FALSE), creates a window and clears it every frame with glClearColor(0, 0, 0, 0) before drawing a small opaque shape. 2. Run it in Wine. Expected: only the shape is visible; the desktop is visible around it, as on Windows 10/11. Actual: the shape is drawn on an opaque black rectangle. I observed this with a Qt 5 / Qt 6 desktop-overlay application (OpenGL windows with an 8-bit alpha buffer, transparent clear color). I did not run the GLFW program above; it is given as the smallest reproducer because GLFW goes through the same DwmEnableBlurBehindWindow() call. System: - Wine 11.0 (also 10.0), 64-bit prefix - Ubuntu 26.04.1 LTS, GNOME Shell 50.1, Wayland session (XWayland, winex11.drv); a compositing window manager is running, so 32-bit ARGB X11 visuals are available - NVIDIA GeForce RTX 5070 Ti, driver 615.71.09; same result on an AMD Radeon 780M with Mesa Notes: - With the NVIDIA driver, a GLX context created for a 24-bit visual cannot be made current on a 32-bit ARGB drawable (BadMatch), so supporting this needs more than switching the visual of the existing window. - Such windows are often also click-through overlays (WS_EX_LAYERED | WS_EX_TRANSPARENT): clicks on fully transparent pixels must go to the windows below, clicks on opaque pixels must still reach the application. - Bug 52254 is the same kind of problem for DwmExtendFrameIntoClientArea() with Direct3D 9; this report is about DwmEnableBlurBehindWindow() with OpenGL. -- 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 60511] New: Qt 6.11.3 qml.exe: QML window never updates after the first frame (default Direct3D 11 backend)
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60511 Bug ID: 60511 Summary: Qt 6.11.3 qml.exe: QML window never updates after the first frame (default Direct3D 11 backend) Product: Wine Version: 10.0 Hardware: x86-64 URL: https://download.qt.io/online/qtsdkrepository/windows_ x86/desktop/qt6_6113/qt6_6113_mingw/qt.qt6.6113.win64_ mingw/ OS: Linux Status: UNCONFIRMED Keywords: download, source, testcase Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: brunet.cyril(a)hotmail.com Target Milestone: --- Distribution: --- Created attachment 82367 --> http://bugs.winehq.org/attachment.cgi?id=82367 counter.qml (testcase) Qt 6 draws Qt Quick (QML) windows with Direct3D 11 by default on Windows. With Wine's builtin d3d11/dxgi, such a window only ever shows its first frame. The application keeps running, but later changes to the scene never appear on screen. Steps to reproduce: 1. Download the official Qt 6.11.3 MinGW packages for Windows from the URL above: qtbase, qtdeclarative, the MinGW runtime and d3dcompiler_47 (SHA1 below), and extract them into one directory. 2. Copy libgcc_s_seh-1.dll, libstdc++-6.dll, libwinpthread-1.dll and d3dcompiler_47.dll into bin/, next to qml.exe. 3. Save the attached counter.qml (a 1-second Timer that increments a counter shown in a Text item and in the window title). 4. wine bin/qml.exe counter.qml Expected: the text counts up every second ("ticks: 1", "ticks: 2", ...). Actual: the window keeps showing "ticks: 0". The timer does run: after 10 seconds the window title, bound to the same counter, reads "qt6-d3d11-counter 8" while the content still shows "ticks: 0". The same test with QSG_RHI_BACKEND=opengl (Qt Quick on OpenGL instead of D3D11) counts normally. It also counts normally with DXVK instead of the builtin d3d11/dxgi. Tested with wine-11.16-1379-g5b6b85421c2 (current git, after 11.19, unmodified, clean prefix), and also seen with Wine 10.0 and 11.0. Complete terminal output attached. Possible clue, from the terminal output: fixme:d3d:wined3d_swapchain_init Unimplemented swap effect 0x2. Qt creates a flip-model swapchain here; the displayed image never changes after the first Present. Bug 56799 (JUCE GUIs hang with the builtin dxgi) may be related. System: Ubuntu 26.04.1 LTS x86_64, GNOME Shell 50.1 Wayland session (XWayland, winex11.drv), NVIDIA GeForce RTX 5070 Ti with driver 615.71.09. SHA1 of the Qt archives used: f051a4dfa3dc0ea6edd1afa1cb26fdffcd3ac81d 6.11.3-0-202609240253qtbase-Windows-Windows_11_24H2-Mingw-Windows-Windows_11_24H2-X86_64.7z 54c9c8d76009bc0e365ab17b660f48411ccca57d 6.11.3-0-202609240253qtdeclarative-Windows-Windows_11_24H2-Mingw-Windows-Windows_11_24H2-X86_64.7z 6a0888995df2efed352688f238f275094bb26d44 6.11.3-0-202609240253MinGW-w64-x86_64-13.1.0-release-posix-seh-msvcrt-rt_v11-rev1-runtime.7z e1d197a16e5368647d03eb6d920d7c8444615d07 6.11.3-0-202609240253d3dcompiler_47-x64.7z -- 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