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 --- Comment #6 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to realmaitreal from comment #4) > x86_64 renderer=gl csmt=0x1 4 failing (4 runs) > x86_64 renderer=gl csmt=0x0 4 failing (1 run) Just noticed csmt=0x0 which is not handled and will probably default to csmt=0x1. csmt=0x2 forces single threading but it seems likely to produce the same results regardless if the bug you describe is related to the delayed blitting behavior I described for vk_blitter_clear_rendertargets. -- 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. 11, 2026

[Bug 60152] WineWayland driver doesn't work anymore in Wine 11.15

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60152 --- Comment #8 from Benjamin Legendre <legendre.benjamin(a)gmail.com> --- I've done some investigations. In my case, the driver is broken when using `WINEDLLOVERRIDES=winemenubuilder.exe=d` or when there is some DLL overrides in my prefix. `WINEPREFIX=/home/ben/myprefix wine notepad` works `WINEPREFIX=/home/ben/th-manual WINEDLLOVERRIDES=winemenubuilderd=d wine notepad` crash with reported issue. -- 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. 11, 2026

[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 --- Comment #5 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to realmaitreal from comment #4) > So CSMT is not the variable -- it fails with csmt on and off. The renderer > is: GL fails deterministically, Vulkan is clean. On GL it is the same four > cases every time, the ones where the render target is an additional > swapchain's back buffer and a Present has happened. gl failing vs vulkan seems to be the opposite of d3d10core.c/d3d11.c tests cases I recently reported for MR-10567: - https://gitlab.winehq.org/wine/wine/-/merge_requests/10567#note_148492 Sorry if gitlab struggles to load such a bloated mess of a merge. I tried suggesting splitting but it is what it is now. Here's the relevant comments from MR-10567 note_148492: > Also the reason for vulkan tests failing has been determined: > vk_blitter_clear_rendertargets delays blitting for ClearRenderTargetView > which may cause some order of operations discrepancy which leads to srgb > correction not being applied properly. > I'll have to take a closer look how to properly fix it. > Forcing attachment_count > 0 for vk_blitter_clear_rendertargets > forces immediate blitting and allows all vulkan tests to pass > for srgb ClearRenderTargetView. Seems similar to deterministic bug you describe which also happens regardless of CSMT but I've only encountered for vulkan but not gl so far which seems to handled blitting immediately but I'll double check if it also may delay blitting under some circumstances. -- 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. 11, 2026

[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 --- Comment #4 from realmaitreal(a)deadmail.lat --- (In reply to Stian Low from comment #3) Thanks for running it. Combining your result with a re-run here on stock wine, I need to walk back part of comment #2. I re-ran the attached testcase on stock WineHQ-devel 11.14 -- not the fork from comment #2 -- with a fresh prefix, on macOS 26.5.2, Apple M2 under Rosetta: x86_64 renderer=gl csmt=0x1 4 failing (4 runs) x86_64 renderer=gl csmt=0x0 4 failing (1 run) x86_64 default (picks gl) 3 failing (1 run; the ~1-in-8 flake) x86_64 renderer=vulkan csmt=0x1 0 failing (4 runs) i386 renderer=gl csmt=0x1 4 failing (2 runs) So CSMT is not the variable -- it fails with csmt on and off. The renderer is: GL fails deterministically, Vulkan is clean. On GL it is the same four cases every time, the ones where the render target is an additional swapchain's back buffer and a Present has happened. That bears on whether this testcase belongs on this bug at all. This report is x86-64 Linux, and if GL genuinely passes there, then what I attached is a macOS GL bug rather than the cause of the black screen reported here, and it should move to its own report. The reasoning in comment #2 was a plausibility argument from WPF's use of CreateAdditionalSwapChain; it was never direct evidence that this particular clear behaviour is what breaks WPF on Linux. Before I split it off, one check on your port, since it decides the question: does it create a fresh HWND for each of the sixteen cases? The standalone testcase builds a new window and a new device per case, and reusing either one masks the failure here -- all sixteen then pass. If the visual.c port shares a window, the Linux GL run is inconclusive rather than a genuine pass, and the attribution may still stand. If it does already use a fresh window per case, I will move this to a separate macOS bug and stop cluttering 49055. -- 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. 11, 2026

[Bug 60157] Blair Witch needs IMFClockConsumer interface support

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60157 --- Comment #2 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Created attachment 81779 --> http://bugs.winehq.org/attachment.cgi?id=81779 mf* output -- 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. 11, 2026

[Bug 59846] Worms Forts: Under Siege (GOG.com) crashes on start when trying to play the intro

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59846 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|dsound |quartz CC| |leslie_alistair(a)hotmail.com --- Comment #1 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Reproduced the issue. Work around winetricks quartz The crash occurs because the dst and src surfaces are not the same type. source is YV12 destination is RGB24 The destination is created via the application "allocator" and I couldn't find the location (d3d*) of where it was creating the destination Surface. Not sure, if we actually need to convert to the destination type. Guess a few tests could prove one way or another. -- 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. 11, 2026

[Bug 58145] Out of Ctrl 1.2 (Unity game): DX11 launch error; DXVK workaround in Wine<=10.6

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58145 --- Comment #14 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to ToastyBug from comment #13) > WINE_D3D_CONFIG="renderer=gl" wine OutOfCtrl_v1_2_EXE/OutOfCtrl.exe > It makes no difference > virtual machine? Thanks for testing. I'll prep a Mac VM as the next best thing. Similar popup error is reproducible for my system via some UnityPlayer.dll flags: - https://docs.unity3d.com/2020.3/Documentation/Manual/PlayerCommandLineArgum… Maybe one/more combos of those flags will help your system get further: - wine OutOfCtrl_v1_2_EXE/OutOfCtrl.exe -force-d3d11 - wine OutOfCtrl_v1_2_EXE/OutOfCtrl.exe -force-d3d12 - wine OutOfCtrl_v1_2_EXE/OutOfCtrl.exe -force-metal - wine OutOfCtrl_v1_2_EXE/OutOfCtrl.exe -force-glcore Although some of these Unity flags may be dependent on wine and require wine specific flags to also be set for full compatibility and not to be overridden by wine. Seems worth a try in hope for some more debugging hints. -- 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. 11, 2026

[Bug 26040] Odell Down Under Demo: Pagefault on read access when moving fish around the map

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=26040 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexhenrie24(a)gmail.com --- Comment #8 from Alex Henrie <alexhenrie24(a)gmail.com> --- Created attachment 81778 --> http://bugs.winehq.org/attachment.cgi?id=81778 Hack: Don't call DestroyIcon32 in FreeResource16 There's some kind of use-after-free going on, because removing the call to DestroyIcon32 in FreeResource16 fixes it. I don't know if Wine is freeing the memory too early or if the game is buggy and works on Windows only by chance. $ sha256sum windemo.zip df953b8da44fac985ba9c95a8a87bcb6a56d01d0a8ca2febdb885be79336a4fa -- 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. 11, 2026

[Bug 16096] Background music doesn't work in Anno 1503

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=16096 Anton Baskanov <baskanov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |baskanov(a)gmail.com --- Comment #16 from Anton Baskanov <baskanov(a)gmail.com> --- The game uses wave tracks in ADPCM format, which we currently pass directly to IDirectSound8::CreateSoundBuffer(), which expectedly fails. I tried uncompressing Menu.wav: mv Menu.wav Menu.orig.wav && ffmpeg -i Menu.orig.wav Menu.wav After that the first second of the menu track started playing in a loop. The issue turned out to be performance_IsPlaying() always returning S_FALSE. Changing it to S_OK allowed the track play to the end. -- 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. 11, 2026

[Bug 50382] Lego Star Wars Saga fails to render some objects (needs "string" type parsing)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=50382 --- Comment #20 from Francisco Casas <fcasas(a)codeweavers.com> --- I sent an improved version of the previously mentioned patches as: https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/2154 -- 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. 11, 2026