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

[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