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

[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

[Bug 60510] New: ShowCursor(FALSE) reaches the driver only on the next message pump, so a following SetCursorPos shows the cursor at its new position
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60510 Bug ID: 60510 Summary: ShowCursor(FALSE) reaches the driver only on the next message pump, so a following SetCursorPos shows the cursor at its new position Product: Wine Version: 10.0 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: gbrazell(a)gmail.com Target Milestone: --- Created attachment 82366 --> http://bugs.winehq.org/attachment.cgi?id=82366 +cursor traces before and after When an application hides the cursor with ShowCursor(FALSE) and then moves it with SetCursorPos, the cursor is visible at the new position for a frame or two before it disappears. On Windows the hide takes effect immediately. Many games start mouse-look this way. Monsters & Memories (Unity 6000.0.59f2, D3D11) does it on every right- or left-drag camera look: ShowCursor(FALSE), then about 7 ms later SetCursorPos to the window centre, then ClipCursor to that point. Under Wine the cursor flashes at the window centre at the start of every look. NtUserShowCursor only changes the count on the server. The server then queues WM_WINE_SETCURSOR (update_desktop_cursor_handle), and the thread handles it in its next PeekMessage/GetMessage. NtUserSetCursorPos, by contrast, calls pSetCursorPos straight away. So the warp happens before the driver learns that the cursor is hidden. The attached +cursor trace shows NtUserShowCursor 0, then macdrv_SetCursorPos to the centre, and only about 10 ms later process_wine_setcursor with hcursor 0x0. Polling CGCursorIsVisible in the same session confirmed that the cursor was visible at the centre for 6-13 ms on every look. Commit 8da05257f3 ("win32u: Process driver events and internal hardware messages in NtUserSetCursor", bug 58331) fixed the same delay for SetCursor by calling check_for_events(QS_INPUT) after the server request. NtUserShowCursor has no such call. Adding the same check_for_events(QS_INPUT) there (for example only when the count crosses zero, i.e. when visibility actually changes) fixes it: in the attached "after" trace the hide reaches the driver in the same millisecond as ShowCursor, before the warp, and in that session all 20 camera looks were hidden before the warp. Tested on a Wine 10.0 macOS build (Sikarugir 10.0_6, x86-64 under Rosetta 2, macOS 26, Apple M5 Max), where I applied the change as a binary edit with the same effect. The code path is unchanged in current master (5b6b85421c). The analysis was done with the help of an AI assistant; for that reason I am not submitting a patch. -- 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 58935] New: Dark Souls: Remastered crashes on exit with "!status && \"vkAcquireNextImageKHR\""
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=58935 Bug ID: 58935 Summary: Dark Souls: Remastered crashes on exit with "!status && \"vkAcquireNextImageKHR\"" Product: Wine Version: 10.18 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- This happens just on exit. Simple run the game and then exit to reproduce. 05ec:err:d3d:wined3d_swapchain_vk_create_vulkan_swapchain Failed to create Vulkan surface, vr VK_ERROR_OUT_OF_HOST_MEMORY. 05ec:err:d3d:swapchain_vk_present Failed to recreate swapchain, hr 0x80004005. 05ec:err:msvcrt:_wassert (L"!status && \"vkAcquireNextImageKHR\"",L"../wine/dlls/winevulkan/loader_thunks.c",45) wine-10.18-192-gb448a8ba7b6 -- 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 60507] New: ST Visual Develop 4.3.12 crashes opening Project Settings
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60507 Bug ID: 60507 Summary: ST Visual Develop 4.3.12 crashes opening Project Settings Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: testcase Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: mpm1107.dev(a)gmail.com Target Milestone: --- Distribution: Ubuntu Created attachment 82364 --> http://bugs.winehq.org/attachment.cgi?id=82364 Testcase program ST Visual Develop (STVD), STMicroelectronics' free IDE for ST7/STM8 microcontrollers, crashes as soon as Project -> Settings is opened, with any project loaded, including the examples that ship with it. Bug 36999 looks like it might be the same crash (closed as abandoned in 2014). Setup: wine-11.19 built from the release tag, Ubuntu 24.04 x86_64, clean prefix. STVD's installer says "Failed installing MFC redistributables" and STVD then can't start (MFC80.DLL missing), so I also ran Microsoft's VC++ 2005 SP1 redistributable (vcredist_x86.EXE). Nothing else was installed, no DLL overrides. Ubuntu's wine 9.0 crashes the same way. STVD is free from STMicroelectronics (STVD-ST7); sadly not directly accessible, the download link is e-mailed after providing an email: stvd-st7.zip sha1 f4c1b44dcee856295e1676e27fa66181079a28d0 sttoolset_pack42.exe sha1 bb6a9427bdac09c5307f14b4eb2b2730b59adfb9 Steps to reproduce: 1. Install STVD (sttoolset_pack42.exe, default options) and the VC++ 2005 redistributable. 2. Run C:\Program Files (x86)\STMicroelectronics\st_toolset\stvd\stvdebug.exe 3. File -> Open Workspace -> ...\st_toolset\stvd\Example\adc\ADC.stw 4. Project -> Settings Actual result: STVD crashes. Terminal output and the crash report are attached. Expected result: the Project Settings dialog opens, like on Windows. I looked into it a bit. The settings dialog is a property sheet. STVD removes its only page and then adds the real pages with PSM_ADDPAGE. Wine activates the first page as soon as it is added to the empty sheet, before STVD has set it up, and STVD crashes in that page's PSN_SETACTIVE handler. (With wine 9.0 it crashes right there; on 11.19 that exception is ignored and STVD dies a bit later in mfc80.dll.) The activation comes from these lines at the end of PROPSHEET_InsertPage in dlls/comctl32/propsheet.c: /* If it is the only page - show it */ if (psInfo->nPages == 1) PROPSHEET_SetCurSel(hwndDlg, 0, 1, 0); Removing that if statement fixed STVD completely for me, and the comctl32 propsheet tests still pass. I'm sure it's there for a reason, though, so I didn't want to go making a PR on my own, I have basically no experience with the wine codebase in general and what the correct fix is here. One thing I did notice with it removed: a sheet that removes its page and adds a new one in PSCB_INITIALIZED comes up blank, where Windows shows the new page. The attached (admittedly fully vibecoded, but I did my best to manually verify it makes at least some sense) test program checks this without STVD and shows the differing behavior between Windows and Wine. On Windows 11 the page added to the empty sheet isn't activated until PSM_SETCURSEL. Results from Windows 11 and Wine (with and without the lines) are included. -- 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 60504] New: x86_64: xmm6-xmm15 come back stale from a system call made while all xmm registers are zero
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60504 Bug ID: 60504 Summary: x86_64: xmm6-xmm15 come back stale from a system call made while all xmm registers are zero Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: lorenzvdv(a)proton.me Target Milestone: --- Distribution: --- Created attachment 82362 --> http://bugs.winehq.org/attachment.cgi?id=82362 C code to reproduce the bug On x86_64, a system call made while every xmm register is zero (and MXCSR is at its default, 0x1F80) returns with xmm6-xmm15 holding the values they had at an *earlier* system call. xmm6-xmm15 are callee-saved in the Win64 ABI, so compiled code that keeps a value there across a call into the system sees it change. The attached program sets xmm6-xmm15 to a pattern and calls Sleep(0). It then zeroes xmm0-xmm15 and calls Sleep(0) again. After the second call, xmm6-xmm15 should still be zero. Under Wine they hold the pattern from before the first call: ``` xmm6 after the second Sleep: {0x0000000000000006, 0x0000000000000100} MXCSR at its default: xmm6-xmm15 changed across Sleep(0) (expected: all zero) MXCSR.PE set: ok, xmm6-xmm15 zero ``` All ten registers are affected, not just xmm6. Setting MXCSR's sticky precision flag (PE, 0x20) beforehand makes the problem go away; nothing else in the program changes. **Likely cause (a guess):** with all xmm registers zero and MXCSR at its default, the SSE state is in its initial configuration. XSAVEOPT / XSAVEC / XSAVES then skip writing it (XSTATE_BV bit 1 clear), but the registers still seem to be restored from the save area's legacy region, which holds what an earlier call left there. Setting MXCSR.PE keeps the state out of its initial configuration, so it is always saved. This is the same code as bug 58335 (xsave64 with a zero mask in `__wine_syscall_dispatcher`, a skipped save followed by a restore), but this machine has AVX/AVX-512 and the mask is not zero. **How it showed up:** a compiled program kept a zero in xmm6 across calls. A memset that stores 16 bytes at a time left xmm0/xmm1 zero, so every xmm register happened to be zero at the next system call. The zero in xmm6 came back as an unrelated value from an earlier call, and a socket buffer's offsets were overwritten with it. The program works on Linux, where the system V ABI has no callee-saved xmm registers. **Steps to reproduce:** ``` printf 'LIBRARY kernel32.dll\nEXPORTS\nSleep\nGetStdHandle\nWriteFile\nExitProcess\n' > kernel32.def llvm-dlltool -m i386:x86-64 -d kernel32.def -l kernel32.lib clang --target=x86_64-pc-windows-msvc -O1 -ffreestanding -fno-builtin -fno-stack-protector -c repro.c -o repro.obj lld-link /entry:start /subsystem:console /nodefaultlib repro.obj kernel32.lib /out:repro.exe wine repro.exe ``` The attached repro.c is the only file needed. The program needs no C runtime. With mingw, `x86_64-w64-mingw32-gcc -O1 -nostdlib -e start repro.c -lkernel32 -o repro.exe` should do the same (untested here). The exit status is 1 when the registers came back changed and 0 when they did not. **Expected:** xmm6-xmm15 are zero after the second Sleep(0) (as on Windows). **Actual:** they hold the values from before the first Sleep(0). **System:** - Wine 11.19 (CachyOS package 11.19-1.1, not yet checked with an upstream build) - Linux 7.2.6-1-cachyos - AMD Ryzen 5 7600X (Zen 4: AVX-512, XSAVEOPT, XSAVEC, XSAVES) - 64-bit prefix The same happens with SwitchToThread() and recv() in place of Sleep(0), on the main thread and on other threads. -- 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 60338] New: On openSUSE Tumbleweed, Wine Staging 11.17 shows Wine applications such as Regedit and Notepad in Arabic when the system locale is Norwegian Nynorsk:
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60338 Bug ID: 60338 Summary: On openSUSE Tumbleweed, Wine Staging 11.17 shows Wine applications such as Regedit and Notepad in Arabic when the system locale is Norwegian Nynorsk: Product: Wine-staging Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bjarte.kaldestad(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Target Milestone: --- Distribution: --- On openSUSE Tumbleweed, Wine Staging 11.17 shows Wine applications such as Regedit and Notepad in Arabic when the system locale is Norwegian Nynorsk: LANG=nn_NO.UTF-8 The system locale itself is correct: $ locale LANG=nn_NO.UTF-8 ... $ locale -a | grep -Ei '^(nn_NO|nb_NO)' nb_NO nb_NO.utf8 nn_NO nn_NO.utf8 $ LC_ALL=nn_NO.UTF-8 locale language Norwegian Nynorsk $ LC_ALL=nn_NO.UTF-8 locale territory Norway Wine also detects the locale correctly: $ LANG=nn_NO.UTF-8 LC_ALL=nn_NO.UTF-8 \ wine reg query "HKCU\Control Panel\International" /v LocaleName HKEY_CURRENT_USER\Control Panel\International LocaleName REG_SZ nn-NO However, the Wine UI is Arabic. If I start Wine with Norwegian Bokmål instead: LANG=nb_NO.UTF-8 LC_ALL=nb_NO.UTF-8 wine notepad the UI is shown correctly in Norwegian. I then downgraded from Wine Staging 11.17 to Wine Staging 11.16. With 11.16, using the normal system locale: LANG=nn_NO.UTF-8 Wine applications are again shown correctly in Norwegian. So the regression appears to be: Wine Staging 11.16 + nn_NO.UTF-8 -> Norwegian UI Wine Staging 11.17 + nn_NO.UTF-8 -> Arabic UI Wine Staging 11.17 + nb_NO.UTF-8 -> Norwegian UI Wine version: wine-staging 11.17 Distribution: openSUSE Tumbleweed Expected behavior: nn_NO.UTF-8 / nn-NO should select Norwegian Nynorsk resources, or at minimum fall back to Norwegian/English, not Arabic. Actual behavior: Wine 11.17 selects Arabic UI resources when launched under nn_NO.UTF-8. This did not happen with Wine Staging 11.16. -- 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 8

[Bug 60503] New: CPU "Update Revision" value does not exist in Registry.
by WineHQ Bugzilla Oct. 15, 2026

Oct. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60503 Bug ID: 60503 Summary: CPU "Update Revision" value does not exist in Registry. 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: reelix(a)gmail.com Target Milestone: --- Distribution: --- Simply put, the `HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0` `Update Revision` value does not pull from the local CPU. This has been causing a large Warning message to appear in a few games (Aion 2 / Arknights: Endfield). This error can safely be ignored, but it can generally be a cause of alarm for users, so it would be better if it didn't happen :) Demo: 1.) Compile the following C program with: x86_64-w64-mingw32-gcc -static check_ucode.c -o check_ucode.exe -ladvapi32 ```c #include <windows.h> #include <stdio.h> #include <stdint.h> int main(void) { HKEY hKey; const wchar_t *subkey = L"HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0"; const wchar_t *valueName = L"Update Revision"; // 1. Open the key LONG res = RegOpenKeyExW(HKEY_LOCAL_MACHINE, subkey, 0, KEY_READ, &hKey); if (res != ERROR_SUCCESS) { fprintf(stderr, "[-] ERROR: CentralProcessor key does not exist. (Code: %ld)\n", res); return 1; } uint8_t buffer[64] = {0}; DWORD bufSize = sizeof(buffer); DWORD type = 0; // 2. Query 'Update Revision' res = RegQueryValueExW(hKey, valueName, NULL, &type, buffer, &bufSize); RegCloseKey(hKey); if (res != ERROR_SUCCESS) { fprintf(stderr, "[-] ERROR: 'Update Revision' value does not exist. (Code: %ld)\n", res); return 2; } // 3. Interpret either REG_DWORD or REG_BINARY uint32_t ucode = 0; if (type == REG_DWORD && bufSize >= sizeof(uint32_t)) { ucode = *(uint32_t *)buffer; } else if (type == REG_BINARY && bufSize >= 4) { ucode = buffer[0] | (buffer[1] << 8) | (buffer[2] << 16) | (buffer[3] << 24); } else { fprintf(stderr, "[-] ERROR: Value exists, but has an unexpected format (Type: %lu, Size: %lu bytes).\n", type, bufSize); return 3; } // 4. Output the value printf("[+] 'Update Revision' found: 0x%X\n", ucode); return 0; } ``` 2.) Run on Windows 3.) See the CPU Update Revision 4.) Run under Wine 5.) See ``` reelix@reelix-cachy  ~/wine-bug  wine --version wine-11.19 reelix@reelix-cachy  ~/wine-bug  wine ./check_ucode.exe [-] ERROR: 'Update Revision' value does not exist. (Code: 2) ``` -- 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 58805] New: Chrome Embedded Framework CEF Massive Memory usage
by WineHQ Bugzilla Oct. 14, 2026

Oct. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=58805 Bug ID: 58805 Summary: Chrome Embedded Framework CEF Massive Memory usage Product: Wine Version: 10.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: johnpgoodman(a)gmail.com Distribution: --- Created attachment 79459 --> http://bugs.winehq.org/attachment.cgi?id=79459 memory usage I noticed that recent versions of Logos Bible software make much more use of CEF and so each panel starts up a new process. I'm sure this is true of lots of other apps too. But the problem is on Mac or Windows CEF is very memory light but for some reason each process uses about 250mb of ram on wine. I've investigated this a little and grok suggests that the problem is likely this: Chromium Embedded Framework (CEF) apps like Logos Bible Software spawn multiple renderer processes (~1 per UI panel). On Windows/Mac, each uses 20-50MB RAM by sharing V8 JIT code, Skia graphics caches, and fonts across processes. In Wine on Linux, unshared per-process duplication inflates this to 250MB/process, exhausting RAM with 10+ panels (2.5GB+ total). Root causes: Wine's ntdll doesn't share executable pages; D3D11 re-translates shaders per-process; emulated sandbox adds overhead. It recommends a solution: 3 targeted patches to emulate native sharing: Shared V8 JIT Cache (ntdll/unixlib.c): Map V8's 128MB executable region to /dev/shm once per prefix. Unified Skia/ANGLE Cache (d3d11/utils.c): Global /tmp/wine-angle-cache for shader translations. CEF Sandbox Bypass (Launch flag + winevdm.c): Skip emulated sandboxing. And points out that All Wine CEF Apps would be affected e.g. Discord, VSCode, Steam etc so many 1000s of users. I haven't a great deal of expertise but I've a good track record of working with devs to do testing and builds etc to help patches through. I'd be very grateful for any assistance from a dev with this issue! 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.

2 1

[Bug 60502] New: mf: audio renderer requests a sample after OnClockStop; music stops for good when a MonoGame game replays a song
by WineHQ Bugzilla Oct. 14, 2026

Oct. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=60502 Bug ID: 60502 Summary: mf: audio renderer requests a sample after OnClockStop; music stops for good when a MonoGame game replays a song Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)list.winehq.org Reporter: marepetru2015(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82360 --> http://bugs.winehq.org/attachment.cgi?id=82360 it's the test program, its source, three 2-second test songs, and a README with how to run it and the results on Windows and Wine. Found while looking into the Picross for a Cause crash (bug #60501). MonoGame 3.7.1 plays songs through IMFMediaSession and the streaming audio renderer. When a song ends it calls Start(position 0) and then Stop() right away, to reset the position. If the same song is then started again, the session plays nothing and sends no further events (no MESessionEnded), so the music stops for good. What goes wrong (wine-11.19-226-ga312fc87a5): 1. After OnClockStop, audio_renderer_render() can still run once from the audio client's buffer event. It finds its queue empty and queues MEStreamSinkRequestSample (sar.c:2151) without looking at the clock state, unlike the ProcessSample path, which only requests while the clock is running (sar.c:1590). In a trace this request comes about 7 ms after MESessionStopped. 2. The session handles that request while stopped and counts it as pending in the transform node (the WMA decoder). The source drops pending requests when it is started again from a position. 3. On the next Start of the same presentation, the renderer's new requests only increase the pending count ("there's already requests pending, just increase the counter"), so nothing is ever requested from the source again. On Windows 10 22H2 the attached program replays songs without problems. A small check on Windows (OnClockStop, then the pending request answered with a sample) showed no MEStreamSinkRequestSample after the clock stopped. Windows does keep requesting while prerolling with the clock stopped (test_sar_time_source: "A third sample is requested only after the first two have been delivered"), so it can't simply require a running clock. A direction that worked for me in a local build: in audio_renderer_render(), only queue the request when the clock isn't stopped or the renderer is prerolling (SAR_PREROLLED, which OnClockStop clears). The existing mf tests gave the same results with it. Note: I'm not a developer. This analysis and the test program were made with the help of an AI assistant (Claude). Because of Wine's policy on LLM-generated code I'm not attaching a patch. I'm happy to test patches. To reproduce: unpack mfrepro.zip and run, in its folder, "MFREPRO_DELAY=200 wine mfrepro.exe 30 1 s1.wma s2.wma s3.wma". It stops after "Play s3.wma (session state 0)", the first replay. -- 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 60501] New: Picross for a Cause crashes after a song is played again (mf session requests a sample from a NULL source stream)
by WineHQ Bugzilla Oct. 14, 2026

Oct. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=60501 Bug ID: 60501 Summary: Picross for a Cause crashes after a song is played again (mf session requests a sample from a NULL source stream) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)list.winehq.org Reporter: marepetru2015(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82359 --> http://bugs.winehq.org/attachment.cgi?id=82359 it's the test program, its source, three 2-second test songs, and a README with how to run it and the results on Windows and Wine. Product: Wine Picross for a Cause (free on Steam, MonoGame 3.7.1 WindowsDX build) crashes after 10 minutes or more of play. ProtonDB has reports of this with every Proton version. I hit it with GE-Proton11-7 and reproduced it on upstream Wine (wine-11.19-226-ga312fc87a5) with the attached test program. The game picks a random song (5 WMA files, 1:49 to 3:24 long) whenever the previous one ends. The crash happens when a song that already played comes back after a different one. Backtrace on upstream Wine (from the attached test program): Unhandled exception: page fault on read access to 0x00000000 in wow64 32-bit code =>0 IMFMediaStream_RequestSample [include/mfidl.h:5785] in mf 1 session_request_sample_from_node+0xf3 [dlls/mf/session.c:4149] in mf 2 transform_node_deliver_samples+0x301 [dlls/mf/session.c:4072] in mf 3 session_request_sample_from_node+0x227 [dlls/mf/session.c:4177] in mf 4 session_request_sample+0x5e [dlls/mf/session.c:4214] in mf 5 session_events_callback_Invoke+0x808 [dlls/mf/session.c:4589] in mf 6 standard_queue_worker+0x2d [dlls/rtworkq/queue.c:393] in rtworkq In the game on GE-Proton11-7 it is the same call: "wine: Unhandled page fault on read access to 00000000 at address ... (mf +0x21b13)", right after the next song starts ("wmadec:transform_ProcessMessage Ignoring message 0x10000000"). How MonoGame plays music (MediaPlayer.WMS.cs / Song.WMS.cs in 3.7.1): - one IMFMediaSession for the whole game; - for each song, one topology (source node + output node holding an MFCreateAudioRendererActivate activate), created once and reused for every play; - a different song: SetTopology(MFSESSION_SETTOPOLOGY_IMMEDIATE, song topology) + Start; - when a song ends: Start(position 0) then Stop. What goes wrong: 1. A song's topology is used again, so its audio renderer is the same object as in its earlier presentation (the session doesn't shut down sinks of replaced topologies since 5d255e85, which matches Windows). The session's events_callback subscription on that stream sink from the earlier presentation is still pending. 2. While the topology is resolved, the renderer's SetCurrentMediaType queues MEStreamSinkFormatInvalidated and, through audio_renderer_preroll(), two MEStreamSinkRequestSample. 3. The session gets these through the old subscription before the new source has been started, so before MENewStream has set source_stream on the new presentation's source node. session_request_sample() then ends in IMFMediaStream_RequestSample(NULL) (session.c:4149). f34dda8a ("mf: Fix crash when stream is null during sample request") made the session subscribe to sinks only once the sources have started, but a sink that is still subscribed from an earlier presentation gets around that. On Windows 10 22H2 the attached program runs the same sequence (30 plays, 19 topology switches, songs played again after other songs) without any problem, and an early sample request is served once the sources have started. A direction that worked for me in a local build: while the presentation's sinks aren't subscribed yet (SESSION_FLAG_SINKS_SUBSCRIBED not set), count a sink's sample requests on its output node instead of passing them upstream, and serve the counted ones in session_subscribe_sinks(). With that, the test program runs all 30 plays (together with the fix from the related renderer bug, see below). Related: when the same sink is used by two topologies, session shutdown calls IMFMediaSink_Shutdown on it once per topology; on Windows it is shut down once. Related bug (filed separately): the music stops for good when the same song is played again right after it ended (the renderer requests a sample after OnClockStop). Note: I'm not a developer. This analysis and the test program were made with the help of an AI assistant (Claude). Because of Wine's policy on LLM-generated code I'm not attaching a patch. I'm happy to test patches. To reproduce: unpack mfrepro.zip and run "wine mfrepro.exe 30 2 s1.wma s2.wma s3.wma" in its folder (crashes on the 3rd play). README.txt in the zip describes the sequence and the results on Windows and 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 0

[Bug 40200] New: ftell function problems
by wine-bugs＠winehq.org Oct. 14, 2026

Oct. 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=40200 Bug ID: 40200 Summary: ftell function problems Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: eliidida(a)gmail.com Distribution: --- Hello, I have a console application for Windows so it's a .exe. The console .exe only has one function, no GUI or anything. The console application basically obfuscates a file. Command: ConsoleApp.exe FileName.dylib I have tried Wine (stable or development builds) and while I can run the console application fine, and it exits with "Success", the problem is the output file that is ran using Wine on Linux has a slight difference compared to the output file that was ran using the same .exe but on Windows. After investigating the console .exe program, we found out that the whole problem was due to a piece of code in the .exe "ftell function". Wine apparently doesn't support it? Or something similar because if we compare the two output files, the only difference is in here: http://i.imgur.com/vghTN2X.png Left is Wine on Linux (Ubuntu) and Right is normal Windows OS output file. This is the ftell code: https://imgur.com/UrkJ36V Can you verify this? I did ask on IRC and on the Forums, they told me to submit a bug report. Thank you for your time and I hope a fix for this comes as soon as possible so I can bring my project to life. -- 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 10

[Bug 56677] New: broken horizontal scroll
by WineHQ Bugzilla Oct. 14, 2026

Oct. 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=56677 Bug ID: 56677 Summary: broken horizontal scroll Product: Wine Version: 5.0.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hsen_d_a_s(a)mail.ru Distribution: --- Created attachment 76457 --> https://bugs.winehq.org/attachment.cgi?id=76457 broken horizontal scroll When working in applications, such as NotePad++, WinScp. When scrolling, the file tabs in NotePad++ or the directories in WinScp change. And the program does not scroll -- 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

[Bug 39641] New: Notepad++ not coming to front when opening files
by wine-bugs＠winehq.org Oct. 14, 2026

Oct. 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=39641 Bug ID: 39641 Summary: Notepad++ not coming to front when opening files Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sds(a)mailinator.com Distribution: --- 1) Whenever files are opened in Notepad++ (after application is already open), it opens the file but does not bring the application to the front. You have to manually click it's taskbar tab to bring it to the front. Hopefully you can find a way to make it so (so it's similar to Windows) 2) Also, I'm not sure how to reproduce this bug but when notepad++ is open for a while it becomes weird in the sense you can close a tab properly, can't copy text or do any regular functions (have to close and reopen to do so). And this doesn't happen all the time either. -- 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 10

[Bug 60500] New: WINMM_cs" wait timed out in thread 02c0, blocked by 0684, retrying (60 sec)
by WineHQ Bugzilla Oct. 14, 2026

Oct. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=60500 Bug ID: 60500 Summary: WINMM_cs" wait timed out in thread 02c0, blocked by 0684, retrying (60 sec) Product: Wine-staging Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: sexy_b14(a)hotmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82358 --> http://bugs.winehq.org/attachment.cgi?id=82358 Output log Hi Guys CrealiyScan 4.x will look up during startup with. 02c0:err:sync:RtlpWaitForCriticalSection section 00006FFFF8B24440 "../wine/dlls/winmm/winmm.c: WINMM_cs" wait timed out in thread 02c0, blocked by 0684, retrying (60 sec) 04e4:err:sync:RtlpWaitForCriticalSection section 00006FFFFFC23460 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 04e4, blocked by 04e0, retrying (60 sec) Cheers -- 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 30984] New: Some keys do not work in Trine and Skyrim
by wine-bugs＠winehq.org Oct. 14, 2026

Oct. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=30984 Bug #: 30984 Summary: Some keys do not work in Trine and Skyrim Product: Wine Version: 1.5.7 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: yves.embil(a)orange.fr Classification: Unclassified Regression SHA1: 43984f355a2905e16075a9df3d7fbe463761e853 Created attachment 40666 --> http://bugs.winehq.org/attachment.cgi?id=40666 result of the regression test In Trine the key to select the thief and Skyrim the key to open the console does not work,with wine-1.5.5 it works. -- 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 70

[Bug 45605] New: Letter keys doesn't work in DirectX aplications
by wine-bugs＠winehq.org Oct. 14, 2026

Oct. 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=45605 Bug ID: 45605 Summary: Letter keys doesn't work in DirectX aplications Product: Wine Version: 3.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: directx-dinput Assignee: wine-bugs(a)winehq.org Reporter: ilya77105(a)gmail.com Distribution: --- Created attachment 62035 --> https://bugs.winehq.org/attachment.cgi?id=62035 Screenshot without keys I will use Far Cry 3 for demonstration, but all applications, that i tested shows the same behavior. When English layout is not selected as default in keyboard settings (in OS settings, not Wine) games doesn't recognize keys at all (screenshot). When i select English layout as default, all is ok. Console output have no information about 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.

3 20

[Bug 60496] New: imc LICENSE Manager 4.5 reports "The license file is korrupt" (because creation time is emulated on Linux)
by WineHQ Bugzilla Oct. 14, 2026

Oct. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=60496 Bug ID: 60496 Summary: imc LICENSE Manager 4.5 reports "The license file is korrupt" (because creation time is emulated on Linux) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: aleksi(a)joal.fi Target Milestone: --- Distribution: --- Created attachment 82349 --> http://bugs.winehq.org/attachment.cgi?id=82349 Trace showing read-back failing, but not the SetFileTime call. (WINEDEBUG=+file,+seh) The application writes a file 'Imc.lic', sets creation and last-write time, stores both in the file and compares them on the next read. Wine on Linux ignores the set creation time and reports creation time = mtime. This is related to bug 36958, I want to mention this affected application. -- 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 50847] New: Neutron 3 Advanced Freezes Reaper when loading plugin with virtual:virtual_setup_exception stack overflow error
by WineHQ Bugzilla Oct. 13, 2026

Oct. 13, 2026

https://bugs.winehq.org/show_bug.cgi?id=50847 Bug ID: 50847 Summary: Neutron 3 Advanced Freezes Reaper when loading plugin with virtual:virtual_setup_exception stack overflow error Product: Wine Version: 6.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: moseskim84(a)gmail.com Distribution: --- Created attachment 69658 --> https://bugs.winehq.org/attachment.cgi?id=69658 Yabridge Debug (level 0) Hello, I am having this problem running on the system: Manjaro Arch Kernel 5.11.2 Wine 6.4-staging (TKG branch) --> allows for Ozone 9 to actually work Yabridge VST host (3.0.2) Reaper 6.25 Libs enabled: mf42.dll, mfc42u.dll I am using the TKG branch of Wine (from Lutris) because it actually gets Ozone 9 to work. I traced Ozone crashing to the fact that the current winehq builds do not support child windows in DXVK. The TKG branch incorporated a patch which allowed child windows to render and so the entire Izotope Ozone 9 system works perfectly now, but I can't get Neutron to work at all. It freezes with the following error when I load a plugin onto a track: [Wine STDERR] 00f4:err:virtual:virtual_setup_exception stack overflow 3280 bytes in thread 00f4 addr 0x7bc55da5 stack 0x130330 (0x130000-0x131000-0x230000) I did a backtrace through Yabridge (level 0 and 1) and attached them. Level 0 is just the wine terminal output, level 1 has the host/VST calls to each other once the VST is loaded and the reaper.log is the debugging output. I left out the repetitive parts for sake of size. Please let me know what other information I can apply to help. -- 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 44887] New: Pressure sensitivity lost when file requester is opened in ZBrush
by wine-bugs＠winehq.org Oct. 13, 2026

Oct. 13, 2026

https://bugs.winehq.org/show_bug.cgi?id=44887 Bug ID: 44887 Summary: Pressure sensitivity lost when file requester is opened in ZBrush Product: Wine Version: 3.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: f2267911(a)nwytg.com Distribution: --- ZBrush (4r8 and 2018) works quite fine but when a file requester (to load or save a tool) is opened, ZBrush does not response to the pressure sensitivity. Before loading a tool the pressure sensitivity worked fine. -- 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 58952] New: Zbrush (2022.06) Decimation Master plugin does not function correctly in .exe or .dll mode
by WineHQ Bugzilla Oct. 13, 2026

Oct. 13, 2026

http://bugs.winehq.org/show_bug.cgi?id=58952 Bug ID: 58952 Summary: Zbrush (2022.06) Decimation Master plugin does not function correctly in .exe or .dll mode 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: brandon(a)garagebay9.com Distribution: --- Program: Zbrush 2022.06 (this is not the latest release, but it is the last release with a permanent license version, so it is in heavy use) Issue: the Decimation Master plugin is a key workflow component that processes extremely dense meshes at the conclusion of the sculpting process, and once they are pre-processed, it provides a dynamic interface to the artist to reduce the mesh in vertex / poly count from millions or more to tens of thousands (which makes the outputted meshes practical to upload, use in game engines, or 3D print). Decimation Master has two compatibility modes, a separate .exe and a .dll mode. Currently, .exe mode gets stuck in the mid 90% range when pre-processesing meshes, although it can be cancelled with Esc and the Zbrush remains otherwise usable. .dll mode successfully pre-processes a mesh, but will crash zBrush with an "unrecoverable error" prompt when the button is pressed to actually decimate the mesh to the target density. As a result, neither are working, and one fully hard-crashes Zbrush with 100% reliability. NOTE: THIS ISSUE IS NOT PRESENT IN THE 8.26-GE RELEASE OF THE WINE-GE FORK BY GLORIOUS EGGROLL, AVAILABLE FOR INSPECTION HERE:https://github.com/GloriousEggroll/wine-ge-custom, WHICH MAY HELP IN IDENTIFYING THE SPECIFIC CAUSE OS: Debian 13 / Trixie Kernel: 6.16.3+deb13-amd64 Wine version: 10 Stable, 10.18 Staging (also present in prior Stable and Staging versions, per my own experience and discussion on ZbrushCentral regarding Zbrush on WINE) I attempted to capture this in a log using WINEDEBUG = +heap,+err but was unsuccessful. I'm happy to help in tracking this down further if someone has specific settings and procedures they want me to run log captures with. -- 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 60317] New: Metrohm Nova 2.1.9: crash after the start
by WineHQ Bugzilla Oct. 13, 2026

Oct. 13, 2026

http://bugs.winehq.org/show_bug.cgi?id=60317 Bug ID: 60317 Summary: Metrohm Nova 2.1.9: crash after the start Product: Wine Version: 11.17 Hardware: x86-64 URL: https://www.metrohm.com/cs_cz/service/software-center/ nova.html OS: Linux Status: UNCONFIRMED Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: torfbug(a)mailo.com Target Milestone: --- Distribution: Mint Created attachment 82080 --> http://bugs.winehq.org/attachment.cgi?id=82080 Wine output concatenated with the program's own diagnostics Nova 2.1.9 (a software for electrochemical measurements with Metrohm equipment and manipulation with the data generated in their proprietary *.nox format) installs successfully with wine, but crashes just after the start with a popup message "Nova will be closed due to unrecoverable error" (the wine output concatenated with the program's own traceback is attached). -- 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