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

[Bug 49055] Multiple .NET WPF 4.x applications show black screen or have broken user interface rendering

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=49055 realmaitreal(a)deadmail.lat changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |realmaitreal(a)deadmail.lat --- Comment #2 from realmaitreal(a)deadmail.lat --- Created attachment 81735 --> http://bugs.winehq.org/attachment.cgi?id=81735 testcase: viewport-scoped Clear() escapes the viewport on a presented additional swapchain Attaching a self-contained testcase that reduces this to one wrong pixel. The defect does not look WPF-specific. Once a swapchain created by CreateAdditionalSwapChain has been presented, a Clear(0, NULL, D3DCLEAR_TARGET) -- which D3D9 scopes to the current viewport -- repaints the whole back buffer instead of only the viewport. The testcase sweeps {IDirect3DDevice9, IDirect3DDevice9Ex} x {D3DSWAPEFFECT_COPY, D3DSWAPEFFECT_DISCARD} x {implicit swapchain, additional swapchain} x {Present, no Present}, with a fresh device and window per case (sharing either one between cases masks the failure), and reads pixel (10,10) after: SetViewport(0, 0, 400, 300); Clear(0, NULL, D3DCLEAR_TARGET, red) [optionally] Present() SetViewport(100, 100, 100, 100); Clear(0, NULL, D3DCLEAR_TARGET, blue) (10,10) is outside the second viewport, so it has to still be red. Twelve of the sixteen cases pass. The four that fail are exactly those where the render target is an additional swapchain's back buffer and a Present has happened -- they read blue, i.e. the second clear reached the whole surface: Device9 COPY implicit no present (10,10)=0xff0000 ok Device9 COPY implicit after present (10,10)=0xff0000 ok Device9 COPY additional no present (10,10)=0xff0000 ok Device9 COPY additional after present (10,10)=0x0000ff FAIL Device9 DISCARD implicit no present (10,10)=0xff0000 ok Device9 DISCARD implicit after present (10,10)=0xff0000 ok Device9 DISCARD additional no present (10,10)=0xff0000 ok Device9 DISCARD additional after present (10,10)=0x0000ff FAIL Device9Ex COPY implicit no present (10,10)=0xff0000 ok Device9Ex COPY implicit after present (10,10)=0xff0000 ok Device9Ex COPY additional no present (10,10)=0xff0000 ok Device9Ex COPY additional after present (10,10)=0x0000ff FAIL Device9Ex DISCARD implicit no present (10,10)=0xff0000 ok Device9Ex DISCARD implicit after present (10,10)=0xff0000 ok Device9Ex DISCARD additional no present (10,10)=0xff0000 ok Device9Ex DISCARD additional after present (10,10)=0x0000ff FAIL 4 failing case(s) Neither the swap effect nor Device9 vs Device9Ex changes this, so the two things that arm it are the additional swapchain and the preceding Present. Same result for i386 and x86_64 builds of the testcase. It is not perfectly deterministic: in roughly one run in eight, one of those four reads correct. No case outside those four has failed here, over a dozen runs on each architecture. Why this matches the reported symptom: WPF's MilCore composes through exactly that path -- Direct3DCreate9Ex, CreateDeviceEx, then one CreateAdditionalSwapChain per HWND with D3DSWAPEFFECT_COPY, clearing per-viewport rather than per-surface and presenting partial rectangles. So the client area ends up holding the last clear colour, and moving the pointer over a control repaints that small region and makes it appear -- which is what comment 0 describes with the 'info' icon. It also explains why DisableHWAcceleration works around it: the software rasteriser never creates a wined3d swapchain. Environment: wine-11.14 on macOS 15 (winemac.drv, OpenGL renderer, Apple M2 via Rosetta). To be upfront about the tree, this is a local fork carrying patches in ntdll and winemac.drv, none of them touching d3d. I rebuilt dlls/wined3d from unmodified wine-11.14 source, with and without wine-staging 11.14, and the results above are unchanged in every case. The original report is x86-64 Linux and I have not been able to check there, so it would be worth someone confirming the testcase on Linux -- it builds with mingw and runs in a couple of seconds. As a sanity check on the testcase itself, the identical binary run against a non-wined3d d3d9 implementation on the same machine passes all sixteen cases. -- 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.

Aug. 7, 2026

[Bug 58530] regedit /e should exit silently on failure

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58530 --- Comment #3 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Windows 95 OSR2.5 regedit behaves in the same way. -- 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.

Aug. 7, 2026

[Bug 58228] Move child object page unable to fully load because it is too long

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58228 Stian Low <wineryyyyy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy(a)gmail.com --- Comment #2 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Rosanne DiMesio from comment #1) > Still a problem; I ran into this again while trying to move a test assigned MR-47 pending fix: - https://gitlab.winehq.org/winehq/appdb/-/merge_requests/47 I was concerned this bug may have been caused by my changes to support Bugzilla separation from AppDB last year to solve traffic problems but it was reported before I ever contributed to WineHQ and I've never touched the files until now so it was not related but I figured it was fairly straightforward enough to fix while I checked. Please let me know if it breaks anything. I do not have enough time for further testing at the moment. Paging features are automatically supported for CMS apps without any code changes where AppDB may be able to migrate to eventually as an upgrade: - https://bugs.winehq.org/show_bug.cgi?id=60100 -- 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.

Aug. 7, 2026

[Bug 60138] Top of Notion Cut Off

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60138 --- Comment #3 from spamemail392g(a)gmail.com --- (In reply to spamemail392g from comment #2) > Still happens on Wine 11.0 stable. Interesting, the graphical error is only the same on the login screen. When logged in and in the workspace, the top is cut off and replaced with a large white bar. -- 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.

Aug. 7, 2026

[Bug 60138] Top of Notion Cut Off

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60138 --- Comment #2 from spamemail392g(a)gmail.com --- Still happens on Wine 11.0 stable. -- 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.

Aug. 7, 2026

[Bug 60137] Notion Installer Immediately Crashes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60137 --- Comment #2 from spamemail392g(a)gmail.com --- I was able to successfully boot up the installer to install it on a stable release (11.0). -- 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.

Aug. 7, 2026

[Bug 60119] Wine Takes Over As URL Handler for Apps

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60119 --- Comment #2 from spamemail392g(a)gmail.com --- Kubuntu 26.04 LTS. -- 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.

Aug. 7, 2026

[Bug 60097] wineserver hangs with Assertion failed: (info->count), function enum_tcp_connections, file sock.c

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60097 fanoush <fanoush(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |11.14 --- Comment #5 from fanoush <fanoush(a)gmail.com> --- Ok so today it happened on 11.14 version too > 0180:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet > 0460:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet > 0674:fixme:cryptnet:check_ocsp_response_info check responder id > 0674:fixme:cryptnet:check_ocsp_response_info check responder id > Assertion failed: (info->count), function enum_tcp_connections, file sock.c, line 4270. so took 3 days of having it runing, now I replaced wineserver with patched one and will wait for the "info count is zero!" message and see whether it still works just fine after that -- 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.

Aug. 7, 2026

[Bug 52386] err:module:LdrInitializeThunk "libclang_rt.asan_dynamic-i386.dll" failed to initialize when using clang address sanitizer

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=52386 --- Comment #11 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Created attachment 81734 --> http://bugs.winehq.org/attachment.cgi?id=81734 debugging-wine-11.14.txt After some patches to LLVM got accepted I tried to check where we are here. I tested quite a few llvm-mingw releases since this bug got opened. Added notes of it in attached file. It looks since LLVM 20.1.0 the instruction size decoder understands enough instructions to intercept most needed functions of wine-11.14, the winehq debian packages. At least the ucrt-i686 variant is able to detect the use-after-free.cc test case. Wine seems to have gained more compatibility to Windows as all msvcrt-i686 builds show now: "((__interception::real_memcpy)) != (0)". This is also shown when running with a native Windows. Following seems to have more details: https://github.com/mstorsjo/llvm-mingw/issues/552 In the end llvm-mingw dropped sanitizer support in msvcrt builds. There appeared a few more "unhandled instruction", for which I placed another pull request to LLVM: https://github.com/llvm/llvm-project/pull/214707 The x86_64 case, which is more subject of #50993, I did give only a short test with recent llvm-mingw build and it looks working too. (Given the system has enough memory.) When I build the testcase with llvm-mingw-20211002-msvcrt-i686 it seems to fail here also with native Windows. A build by llvm-mingw-20211002-ucrt-i686 works with native Windows. Should therefore this bug be resolved as notourbug? -- 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.

Aug. 7, 2026

[Bug 58228] Move child object page unable to fully load because it is too long

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58228 --- Comment #1 from Rosanne DiMesio <dimesio(a)earthlink.net> --- Still a problem; I ran into this again while trying to move a test assigned to an invalid entry, as reported on the forum (https://forum.winehq.org/viewtopic.php?p=151282#p151282) Since the entry to be moved to was World of Warcraft, I had to temporarily rename it to 00 World of Warcraft to get it to display on the first page, then rename it back after the move. That worked, but we shouldn't have to do that. Other long displays, such as the list of operating systems, break the display into pages, defaulting to 25 items per page but with the option to increase it to 50, 100, or 200. We need something like that for the list to merge entries. -- 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.

Aug. 7, 2026