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

[Bug 60162] WPF apps crash on startup (x86 only?)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60162 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com, | |rbernon(a)codeweavers.com Regression SHA1| |717a37b81e9dc086c7b48febcda | |925989896efe6 -- 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. 12, 2026

[Bug 60162] WPF apps crash on startup (x86 only?)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60162 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression, | |source, testcase URL| |https://dl.winehq.org/wine/ | |wine-mono/11.2.0/wine-mono- | |11.2.0-tests.zip -- 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. 12, 2026

[Bug 60162] New: WPF apps crash on startup (x86 only?)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60162 Bug ID: 60162 Summary: WPF apps crash on startup (x86 only?) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: NEW Severity: major Priority: P2 Component: opengl Assignee: wine-bugs(a)list.winehq.org Reporter: madewokherd(a)gmail.com Target Milestone: --- Distribution: --- To reproduce, download and extract https://dl.winehq.org/wine/wine-mono/11.2.0/wine-mono-11.2.0-tests.zip and run tests/tests-x86/wpfapptest.exe. 717a37b81e9dc086c7b48febcda925989896efe6 is the first 'bad' commit commit 717a37b81e9dc086c7b48febcda925989896efe6 Author: Rémi Bernon <rbernon(a)codeweavers.com> Date: Fri Jul 10 10:50:05 2026 +0200 opengl32: Move unix-side context wrapper allocation to win32u. So the win32u interface can be used directly without a client-side context. -- 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. 12, 2026

[Bug 58921] WebView2 does not work with Windows version setting 8.1 or newer

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58921 Wehrwolfmann <wehrwolfmann(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wehrwolfmann(a)gmail.com --- Comment #9 from Wehrwolfmann <wehrwolfmann(a)gmail.com> --- The DirectComposition part of this still reproduces with wine-11.15 (vanilla, 64-bit, clean prefix, no DLL overrides, no DXVK), with the WebView2 runtime 151.0.4129.78 installed in the prefix. One more affected application, in case it helps triaging: Razer Axon 2.9.1.0, whose entire UI is WebView2. The per-application override from comment #0 (Version=win7 for msedgewebview2.exe only, the rest of the prefix staying on win10) still works on 11.15, so the workaround has not rotted. I have attached to bug 55432 a ~90 line repro that needs neither WebView2 nor any application: it only performs the DirectComposition call Chromium makes at startup once the reported Windows version is >= 8.1. The D3D11 device and its IDXGIDevice are created fine; only DCompositionCreateDevice/2/3 fail, all three with E_NOTIMPL, which matches dlls/dcomp/device.c in current master. Since the DirectComposition part of this bug is the same hole as bug 55432, it may be worth marking this one as depending on 55432 so the dcomp work is tracked in one place. -- 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. 12, 2026

[Bug 55432] PlanetSide 2 launcher is completely white (needs dcomp.dll.DCompositionCreateDevice implementation)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=55432 --- Comment #7 from Wehrwolfmann <wehrwolfmann(a)gmail.com> --- Created attachment 81789 --> http://bugs.winehq.org/attachment.cgi?id=81789 Minimal DirectComposition probe, no WebView2 or application required. 3. Save Changes. -- 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. 12, 2026

[Bug 55432] PlanetSide 2 launcher is completely white (needs dcomp.dll.DCompositionCreateDevice implementation)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=55432 Wehrwolfmann <wehrwolfmann(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wehrwolfmann(a)gmail.com --- Comment #6 from Wehrwolfmann <wehrwolfmann(a)gmail.com> --- Still present in wine-11.15 (vanilla, 64-bit, clean prefix). Since the reports in this bug so far were taken with DXVK, here is a measurement made without DXVK, without Steam and without any application -- a ~90 line program that only loads dcomp.dll and calls the three device creation entry points (attached as dcomp_min.c, build with x86_64-w64-mingw32-gcc dcomp_min.c -o dcomp_min.exe -ld3d11 -ldxgi -lole32): reported Windows version: 10.0 build 19045 D3D11CreateDevice hr=0x00000000 feature_level=0xb000 QI IDXGIDevice hr=0x00000000 DCompositionCreateDevice(IDCompositionDevice) hr=0x80004001 DCompositionCreateDevice2(IDCompositionDevice2) hr=0x80004001 DCompositionCreateDevice3(IDCompositionDesktopDevice) hr=0x80004001 fixme:dcomp:DCompositionCreateDevice ..., {c37ea93a-e7aa-450d-b16f-9746cb0407f3}, ... fixme:dcomp:DCompositionCreateDevice2 ..., {75f6468d-1b8e-447c-9bc6-75fea80b5b25}, ... fixme:dcomp:DCompositionCreateDevice3 ..., {5f4633fe-1e08-4cb8-8c75-ce24333f5602}, ... The D3D11 device and its IDXGIDevice are created fine; only the DirectComposition device creation fails, which matches dlls/dcomp/device.c in current master, where all three entry points are FIXME + E_NOTIMPL. This is not limited to game launchers. Anything built on Chromium's compositor takes the same path once the prefix reports Windows 8.1 or newer, which currently includes every application embedding the WebView2 runtime -- see bug 58921, where forcing the Windows version down to win7/win8 for the Chromium process alone is the workaround. -- 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. 12, 2026

[Bug 60161] New: riched20: colour table entries using \ctint/\cshade or theme colour keywords are parsed as three entries, shifting all \cfN indices

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60161 Bug ID: 60161 Summary: riched20: colour table entries using \ctint/\cshade or theme colour keywords are parsed as three entries, shifting all \cfN indices Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: richedit Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81788 --> http://bugs.winehq.org/attachment.cgi?id=81788 inimal reproducer: three RTF colour tables that must render identically. Wine's RTF reader only accepts \red, \green and \blue inside \colortbl. Any other control word that the RTF specification allows in a colour table entry -- \ctint, \cshade and the theme colour keywords \cmaindarkone, \cmainlightone, \caccentone ... -- is not recognised, so ReadColorTbl() terminates the entry early, emits "err:richedit:ReadColorTbl malformed entry", and starts a *new* colour entry at the next token. Consequences: 1. One source entry turns into several colour table entries, so every \cfN in the document afterwards selects the wrong colour. 2. The bogus entries are created with rtfCRed/CGreen/CBlue = -1, i.e. "use the default colour", so the affected text ends up with CFE_AUTOCOLOR instead of the colour the document asked for. The relevant code is dlls/riched20/reader.c, ReadColorTbl(): if (!RTFCheckCM (info, rtfControl, rtfColorName)) cp->rtfCRed = cp->rtfCGreen = cp->rtfCBlue = -1; else { ... do { switch (info->rtfMinor) { case rtfRed: ... case rtfGreen: ... case rtfBlue: ... } RTFGetToken (info); } while (RTFCheckCM (info, rtfControl, rtfColorName)); } if (info->rtfClass == rtfEOF) break; if (!RTFCheckCM (info, rtfText, ';')) ERR ("malformed entry\n"); The keyword table in the same file (lines 1847-1849 of current master) knows exactly three colour table keywords: { rtfColorName, rtfRed, "red", 0 }, { rtfColorName, rtfGreen, "green", 0 }, { rtfColorName, rtfBlue, "blue", 0 }, \ctint, \cshade and the theme colour keywords do not appear anywhere in reader.c, so they are classified as unknown control words and break the entry apart. This is not a corner case: it is the shape Word (2007 and newer) and WordPad write for any document that uses theme colours, and it is what Inno Setup installers ship as their licence text. It is the likely cause of the long-standing "err:richedit:ReadColorTbl malformed entry" messages, e.g. in bug 20482. STEPS TO REPRODUCE Build and run the attached riched_colortbl.c (x86_64-w64-mingw32-gcc riched_colortbl.c -o riched_colortbl.exe -lgdi32 -luser32). It streams three RTF documents into a RichEdit 2.0 control with EM_STREAMIN and then reads the effective text colour of the single character back with EM_GETCHARFORMAT. All three documents request the same colour -- pure red -- and per the RTF specification must render identically: A {\rtf1\ansi\deff0{\fonttbl{\f0 Arial;}} {\colortbl;\red255\green0\blue0;}\cf1 X\par} B {\rtf1\ansi\deff0{\fonttbl{\f0 Arial;}} {\colortbl;\ctint255\cshade255\red255\green0\blue0;}\cf1 X\par} C {\rtf1\ansi\deff0{\fonttbl{\f0 Arial;}} {\colortbl;\red0\green0\blue0; \cmaindarkone\ctint255\cshade255\red255\green0\blue0;}\cf2 X\par} CURRENT BEHAVIOUR (wine-11.15, 64-bit, clean prefix, no overrides) expected for every line: crTextColor=0x0000ff (R=255 G=0 B=0) A plain colortbl stream error=0 textlen=1 effects=0x04000001 crTextColor=0x0000ff (R=255 G=0 B=0) B \ctint\cshade stream error=0 textlen=1 effects=0x44000001 crTextColor=0x007fff (R=255 G=127 B=0) [CFE_AUTOCOLOR] C Word theme colour stream error=0 textlen=1 effects=0x44000001 crTextColor=0x007fff (R=255 G=127 B=0) [CFE_AUTOCOLOR] with WINEDEBUG=+richedit: err:richedit:ReadColorTbl malformed entry (5x for the three documents) EXPECTED BEHAVIOUR All three lines report crTextColor=0x0000ff without CFE_AUTOCOLOR, and no "malformed entry" message is printed: \ctint, \cshade and the theme colour keywords are part of a single colour table entry and do not create entries of their own. SUGGESTED FIX Add the missing colour table keywords to the keyword table in dlls/riched20/reader.c and skip them in ReadColorTbl() instead of terminating the entry: * \ctintN and \cshadeN (tint/shade applied to the following \red\green\blue) * the theme colour keywords \cmaindarkone, \cmainlightone, \cmaindarktwo, \cmainlighttwo, \caccentone ... \caccentsix, \chyperlink, \cfollowedhyperlink, \cbackgroundone, \cbackgroundtwo, \ctextone, \ctexttwo Only the following \red/\green/\blue values need to be stored; the tint/shade factors and the theme name do not change which colour the entry resolves to for the purposes of \cfN lookup. -- 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. 12, 2026

[Bug 60160] Error when trying to run Rapydmark memory tests

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60160 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.overclock.net/p | |osts/29596010/ Keywords| |download --- Comment #1 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Please upgrade and try again. https://gitlab.winehq.org/wine/wine/-/wikis/Download -- 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. 12, 2026

[Bug 12425] win16 test suite: user32 comm16 test crashes/hangs

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=12425 --- Comment #13 from Janne <janne.kekkonen(a)gmail.com> --- Hello, I tested this with Wine 11.14 on a clean 32-bit prefix configured as Windows 2000. The Win16 test suite was compiled with OpenWatcom 2.0. The Makefile was modified from this: CFLAGS =-D_X86_ -DSTANDALONE '-i=C:\WATCOM\h\win;C:\WATCOM\h'-zW -e25 -zq -od -d2 -w4 -wcd=126 -wcd=102 -wcd=112 -bw-bt=windows to this: CFLAGS =-D_X86_ -DSTANDALONE -DNULL=0 '-i=C:\WATCOM\h\win;C:\WATCOM\h' -zW -e25 -zq -od -d2 -w4 -wcd=126 -wcd=102 -wcd=112 -bw-bt=windows Building with the modified Makefile was successful. comm16.exe was started with this command: WINETEST_PLATFORM=wine wine comm16.exe --log && ! grep ' [0-9]*[1-9] failures' *.log && touch comm16.ok A crash occurred with this line at the top of the backtrace: =>0 0x77873664 BuildCommDCB16+0x54(device="COM1:2400,n,8,1", lpdcb=00000000) [/usr/src/packages/BUILD/dlls/user.exe16/comm.c:427] in user.exe16 (0x0123fb68) The backtrace and source code show that lpDCB was/is NULL: https://github.com/austin987/win16test/blob/master/src/comm16.c#L63 In Wine, there is no check for lpDCB being NULL before calling memset: https://gitlab.winehq.org/wine/wine/-/blob/wine-11.15/dlls/user.exe16/comm.… Would adding a check before memset resolve this? For example: if (lpdcb == NULL) { return -1; } -- 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. 12, 2026

[Bug 60141] CertCreateSelfSignCertificate with default parameters makes insecure RSA 512 cert

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60141 --- Comment #4 from Kedar Hirve [MSFT] <kedarh(a)microsoft.com> --- Thank you for fixing this and the other bug. That was a really fast turnaround! -- 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. 12, 2026