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

[Bug 60187] New: Ownerless layered popup windows are mapped override-redirect, so the window manager keeps them above every other window and on every virtual desktop
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60187 Bug ID: 60187 Summary: Ownerless layered popup windows are mapped override-redirect, so the window manager keeps them above every other window and on every virtual desktop Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: Wagner.a18(a)yahoo.com Target Milestone: --- Distribution: --- `is_window_managed()` in `dlls/winex11.drv/window.c` classifies an ownerless `WS_POPUP` window carrying `WS_EX_LAYERED | WS_EX_TOOLWINDOW | WS_EX_NOACTIVATE` as unmanaged, so winex11.drv maps it override-redirect. Override-redirect is the right choice for the transient UI it was designed for (menus, tooltips), but applications also use exactly these flags for long-lived windows — most notably custom frame decorations. Codejock Xtreme Toolkit Pro draws the drop shadow of its main frame into such a window (caption `XTPFrameShadow`), and it stays mapped for as long as the main frame is in its restored state. Because the window is override-redirect, the window manager cannot place it in the normal stacking order and cannot assign it a virtual desktop. The result is a window that: - floats above every other window on the screen, including windows of other applications, regardless of which window has focus - appears on every virtual desktop, while the main frame it belongs to stays on the one it was opened on On Windows the same window is an ordinary top-level window that participates normally in the Z order and disappears with the rest of the application. ## Steps to reproduce 1. Build the attached reproducer: `winegcc -mwindows -o repro repro.c -luser32 -lgdi32` 2. Run it: `wine repro.exe.so` 3. Give another application focus so that it overlaps the reproducer's main window 4. Switch to another virtual desktop ## Current behaviour The semi-transparent grey `ReproOverlay` rectangle stays on top of the other application, and it remains visible after switching virtual desktops. Walking the X window tree shows the overlay is override-redirect while the main window is not: 0x3c00001 592x366 +204+230 VIEWABLE ovr=0 repro main window 0x3c00004 620x420 +190+190 VIEWABLE ovr=1 ReproOverlay ## Expected behaviour The overlay should be stacked with its application and confined to the virtual desktop that application is on, i.e. it should be a managed window. With the patch below applied, the same reproducer maps the overlay as a managed window: 0x3a00001 592x366 +204+230 VIEWABLE ovr=0 repro main window 0x3a00004 620x420 +190+190 VIEWABLE ovr=0 ReproOverlay and the window manager now tracks it like any other window: ReproOverlay WM_STATE : Normal _NET_WM_DESKTOP : 0 _NET_WM_STATE : DEMANDS_ATTENTION, SKIP_TASKBAR, SKIP_PAGER, _KDE_NET_WM_STATE_SKIP_SWITCHER Note `_NET_WM_DESKTOP`, which an override-redirect window cannot carry at all - that is what confines the overlay to one virtual desktop. The skip states come from the existing `WS_EX_NOACTIVATE` handling, so the window does not show up in the taskbar or the window switcher. One observation: KWin also sets `_NET_WM_STATE_DEMANDS_ATTENTION` on the overlay, presumably because it is mapped without ever taking focus. With the three skip states set there is no UI element left for it to affect, so this appears harmless, but it is a behaviour difference worth mentioning. ## Analysis The window falls through every branch of `is_window_managed()`: - it is `WS_POPUP`, so the `WS_CHILD` early-out does not apply - it is shown with `SWP_NOACTIVATE` and is not the active window - it has neither `WS_CAPTION` nor `WS_THICKFRAME` - it is `WS_POPUP` but has no `WS_SYSMENU` and is not fullscreen - it has no `WS_EX_APPWINDOW` - it owns no popups so the function returns FALSE and the window is created with `attr.override_redirect = TRUE`. Observed flags of the real-world case (Codejock `XTPFrameShadow`, read with `GetWindowLongW` from a separate process attached to the same prefix): STYLE 0x94000000 : WS_POPUP WS_VISIBLE WS_CLIPSIBLINGS EXSTYLE 0x08080080 : WS_EX_TOOLWINDOW WS_EX_LAYERED WS_EX_NOACTIVATE owner : NULL ## Proposed patch Treat ownerless layered popups as managed unless they are click-through. `WS_EX_TRANSPARENT` is what separates this case from short-lived drag images, which do need to stay unmanaged. ```diff --- a/dlls/winex11.drv/window.c +++ b/dlls/winex11.drv/window.c @@ -461,6 +461,16 @@ static BOOL is_window_managed( HWND hwnd, UINT swp_flags, BOOL fullscreen ) /* application windows are managed */ ex_style = NtUserGetWindowLongW( hwnd, GWL_EXSTYLE ); if (ex_style & WS_EX_APPWINDOW) return TRUE; + /* Ownerless layered popups that aren't click-through belong to applications + * drawing their own frame decorations - Codejock's XTPFrameShadow puts the + * drop shadow of its main frame into one. They live as long as the frame + * does, so leaving them unmanaged makes the window manager stack them in + * its override-redirect layer, above every other window and on every + * virtual desktop. Click-through ones (WS_EX_TRANSPARENT) are short-lived + * drag images and have to stay unmanaged. */ + if ((style & WS_POPUP) && !NtUserGetWindowRelative( hwnd, GW_OWNER ) && + (ex_style & (WS_EX_LAYERED | WS_EX_TRANSPARENT)) == WS_EX_LAYERED) + return TRUE; /* windows that own popups are managed */ if (has_owned_popups( hwnd )) return TRUE; /* default: not managed */ ``` No decoration or taskbar regression is expected for such windows: `get_mwm_decorations_for_style()` already returns 0 for both `WS_EX_TOOLWINDOW` and `WS_EX_LAYERED`, and `WS_EX_NOACTIVATE` already causes `SKIP_TASKBAR | SKIP_PAGER | SKIP_SWITCHER` to be set. The heuristic is open to discussion — the point of the report is the mapping decision, not this particular discriminator. ## Environment - Wine 11.15 - KDE Plasma / KWin on Wayland, application running through XWayland - Only verified against KWin. The mapping decision itself is WM-independent, but the precise stacking and virtual-desktop consequences are KWin's behaviour for override-redirect windows. ## Reproducer ```c /* winegcc -mwindows -o repro repro.c -luser32 -lgdi32 */ #include <windows.h> static LRESULT CALLBACK proc( HWND h, UINT m, WPARAM w, LPARAM l ) { if (m == WM_DESTROY) { PostQuitMessage( 0 ); return 0; } if (m == WM_PAINT) { PAINTSTRUCT ps; HDC dc = BeginPaint( h, &ps ); FillRect( dc, &ps.rcPaint, (HBRUSH)GetStockObject( GRAY_BRUSH ) ); EndPaint( h, &ps ); return 0; } return DefWindowProcA( h, m, w, l ); } int WINAPI WinMain( HINSTANCE inst, HINSTANCE prev, char *cmd, int show ) { WNDCLASSA c = { 0 }; HWND main_wnd, overlay; MSG msg; c.lpfnWndProc = proc; c.hInstance = inst; c.hCursor = LoadCursorA( NULL, (LPCSTR)IDC_ARROW ); c.lpszClassName = "ReproMain"; RegisterClassA( &c ); c.lpszClassName = "ReproOverlay"; RegisterClassA( &c ); main_wnd = CreateWindowExA( 0, "ReproMain", "repro main window", WS_OVERLAPPEDWINDOW | WS_VISIBLE, 200, 200, 600, 400, NULL, NULL, inst, NULL ); /* Same flags Codejock's XTPFrameShadow uses for the frame drop shadow. * No owner, and deliberately no WS_EX_TRANSPARENT. */ overlay = CreateWindowExA( WS_EX_LAYERED | WS_EX_TOOLWINDOW | WS_EX_NOACTIVATE, "ReproOverlay", "ReproOverlay", WS_POPUP, 190, 190, 620, 420, NULL, NULL, inst, NULL ); SetLayeredWindowAttributes( overlay, 0, 128, LWA_ALPHA ); SetWindowPos( overlay, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE | SWP_SHOWWINDOW ); while (GetMessageA( &msg, NULL, 0, 0 )) { TranslateMessage( &msg ); DispatchMessageA( &msg ); } return 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.

1 0

[Bug 60183] New: wg_format_from_caps has no image/* branch — Media Foundation Source Reader fails to decode WebP sprites (MEError 0xc00d3e85)
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60183 Bug ID: 60183 Summary: wg_format_from_caps has no image/* branch — Media Foundation Source Reader fails to decode WebP sprites (MEError 0xc00d3e85) Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)list.winehq.org Reporter: mendez.gabriele(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81858 --> http://bugs.winehq.org/attachment.cgi?id=81858 MF Source Reader fails to decode WebP sprites (Unhandled caps image/webp → MEError 0xc00d3e85), PNG through same path works. WINEDEBUG=+mfplat,+mfreadwrite,+mf, wine 11. A Windows game (Internet Survivor Survivors, Steam app 4625810, DXライブラリ/DxLib engine) decodes sprite images stored as WebP through the Media Foundation Source Reader. On wine, this fails: every WebP sprite produces MEError 0xc00d3e85 and an empty texture, while PNG and MP4 files going through the exact same MFCreateSourceReaderFromURL path decode correctly. The root cause is a missing branch in wg_format_from_caps: wine's GStreamer backend successfully typefinds image/webp, loads libgstwebp, creates the "webpdec" element and links it — but wine's glue layer (wg_format_from_caps in dlls/winegstreamer/wg_format.c) has no case for image/* caps at all, so it falls through to the GST_FIXME "Unhandled caps" path and the conversion from GStreamer caps to MF media type never happens. Relevant fact: wg_format_from_caps() in wine master (as of 2026-08-16) only handles: audio/x-raw, video/x-raw, audio/mpeg, audio/x-wma, video/x-cinepak, video/x-indeo, video/x-wmv, video/mpeg, video/x-h264. There is no image/* major type. Any image format decoded via GStreamer will hit the same wall — not just WebP. The game works on real Windows because the OS ships the "WebP Image Extensions" Store package, which registers the MF/WIC handler for image/webp. Environment: - wine base: wine 11 (via proton-cachyos-slr, CachyOS Proton build) - GPU: AMD Radeon RX 6400 (RADV, Mesa 26.1.6-arch3.1) - Kernel: 7.1.8-1-cachyos - Compositor: Hyprland (Wayland), game launched through gamescope Steps to reproduce: 1. Launch the game (Internet Survivor Survivors, Steam 4625810) under wine/Proton. 2. Play until any enemy drops coins or until a WebP sprite is loaded. 3. Observe: the sprite is invisible (empty texture). The game continues normally. 4. (Instrumented) Launch with WINEDEBUG=+mfplat,+mfreadwrite,+mf to capture the Source Reader traces. Expected behavior: WebP sprites decode to textures and render visibly, same as PNG. Actual behavior: WebP sprites produce MEError 0xc00d3e85 and render as empty/black. Trace evidence (from WINEDEBUG=+mfplat,+mfreadwrite,+mf, 667k-line log): 1. GStreamer side works — image/webp is typefound, libgstwebp loads, webpdec element is created and linked: 0:00:00.009092474 GST_TYPEFIND gsttypefind.c:72:gst_type_find_register: registering typefind function for image/webp 0:00:00.011216905 GST_EVENT gstevent.c:912:gst_event_new_caps: creating caps event image/webp 0:00:00.012228410 GST_PLUGIN_LOADING gstplugin.c:999:_priv_gst_plugin_load_file_for_registry: plugin "...libgstwebp.so" loaded 0:00:00.012233630 GST_ELEMENT_FACTORY gstelementfactory.c:490:gst_element_factory_create_with_properties: creating element "webpdec" 0:00:00.012308701 GST_PADS gstpad.c:2449:gst_pad_link_prepare: trying to link typefind:src and webpdec0:sink 0:00:00.012313270 GST_PADS gstpad.c:2630:gst_pad_link_full: linked typefind:src and webpdec0:sink, successful 0:00:00.012331264 GST_STATES gstelement.c:2798:gst_element_continue_state: <webpdec0> completed state change to READY 2. Wine's glue then fails — wg_format_from_caps hits the unhandled-caps FIXME: 0:00:00.011275646 FIXME WINE wg_format.c:681:wg_format_from_caps: Unhandled caps image/webp. (Also from winedmo:) 0288:fixme:dmo:demuxer_create Unknown MIME type for format "webp_pipe", url "C:\\users\\steamuser\\AppData\\Local\\Temp\\tmp1c21.tmp" 3. MEError 0xc00d3e85 is queued for every WebP sprite: 01c4:trace:mfplat:eventqueue_QueueEventParamVar 00000000007131C0, MEError, {00000000-0000-0000-0000-000000000000}, 0xc00d3e85, (null) 01c4:trace:mfplat:MFCreateMediaEvent MEError, {00000000-0000-0000-0000-000000000000}, 0xc00d3e85, (null), 0000000004A3DEE8. 4. The full chain for one sprite (goldcoinbig): - Game calls MFCreateSourceReaderFromURL on the original PNG: 0194:trace:mfplat:MFCreateSourceReaderFromURL L"Z:\\...\\Data\\img\\item\\goldcoinbig.png", 0000000000000000, 000000000A8F1220. - Game then extracts a WebP copy to %TEMP% and calls MFCreateSourceReaderFromURL on it: 0194:trace:mfplat:MFCreateSourceReaderFromURL L"C:\\users\\steamuser\\AppData\\Local\\Temp\\tmp32aa.tmp", 0000000000000000, 000000000A8F1220. - GStreamer processes it (typefind → webpdec, see #1 above)... - Wine glue aborts (see #2 above)... - MEError fires (see #3 above). - Result: empty texture, sprite invisible. 5. For comparison, PNG through the same Source Reader produces zero errors: 01c4:trace:mfplat:MFCreateSourceReaderFromURL L"Z:\\...\\Data\\img\\Shot\\berry_circle_b\\magiccircleb0320.png", 0000000000000000, 000000000A7C3480. (No MEError follows — clean decode.) 6. The WebP files are static lossless (VP8L), not animated: - 96 WebP files dumped from %TEMP%, every one is RIFF...WEBP with VP8L chunk. - No ANIM or ANMF chunks present in any file. Suggested fix: Add an image/* branch to wg_format_from_caps() in dlls/winegstreamer/wg_format.c, mapping image/webp (and potentially other image formats) to the appropriate MF media type (MFMediaType_Image with MFImageFormat_WebP, or a raw video format equivalent). The GStreamer decoder pipeline already works end to end — only the caps-to-MF-type conversion is missing. Additionally, the winedmo demuxer_create() in dlls/winedmo/unix_demuxer.c should handle the "webp_pipe" MIME type (currently falls through to "Unsupported MIME type"). See also: - Bug 59848 (feature request: "Please add WebP, AVIF and JXL support") — this report provides a concrete game reproduction and trace evidence for the WebP case. - wine master wg_format.c: https://github.com/wine-mirror/wine/blob/master/dlls/winegstreamer/wg_forma… -- 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 9

[Bug 57777] New: "Hoshi no Otome to Rikka no Shimai" (AdvHD.exe): unable to run with font errors
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

https://bugs.winehq.org/show_bug.cgi?id=57777 Bug ID: 57777 Summary: "Hoshi no Otome to Rikka no Shimai" (AdvHD.exe): unable to run with font errors Product: Wine Version: 10.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sd369888(a)outlook.com Distribution: --- Created attachment 77977 --> https://bugs.winehq.org/attachment.cgi?id=77977 logs The game "Hoshi no Otome to Rikka no Shimai" (AdvHD.exe), crashes when I try to run it in wine, and throws an error: 0024:fixme:font:NtGdiRemoveFontMemResourceEx (0x77386331) stub. I have only installed wine geko and did not touch anything of my wine installation. The heap log is here: https://oshi.at/PLup -- 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 20

[Bug 60177] New: Microsoft Agent 2.0: Characters.Load fails with 0x80042001 (custom marshaling of the notify sink never reaches AgentSvr)
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60177 Bug ID: 60177 Summary: Microsoft Agent 2.0: Characters.Load fails with 0x80042001 (custom marshaling of the notify sink never reaches AgentSvr) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Microsoft Agent 2.0 does not work under Wine. Any app built on it fails the same way: the client connects to the server, but every Characters.Load returns 0x80042001, "The specified Agent client was not found". The character file is never even opened. Three lines of VBScript are enough, no third-party app needed. With MS Agent 2.0 Core installed into the prefix, run this with the 32-bit cscript (wine C:\windows\syswow64\cscript.exe /nologo agent.vbs): Set a = CreateObject("Agent.Control.2") a.Connected = True a.Characters.Load "Bonzi", "C:\windows\msagent\chars\Bonzi.acs" Steps 1 and 2 succeed, step 3 fails with 0x80042001. What I see with WINEDEBUG=+ole. AgentSvr starts fine and hands the client its IAgentEx through MS Agent's own custom marshaler (AgentMPx.dll) — that direction works, the client gets a usable proxy. Then the client marshals its notify sink back: CoMarshalInterface {00000000-0000-0000-c000-000000000046}, dwDestContext=2, custom CoMarshalInterface completed with hr 0 and the server never unmarshals it — there is not a single "Using custom unmarshaling" in the server process for the whole run. So the server has no registered client and answers Load with "client not found". With WINEDEBUG=+file you can see the character file is located and then dropped: FindFirstFileExW on C:\windows\Msagent\CHARS\Bonzi.acs finds it, but NtCreateFile is never called on it. The failure is well before any file I/O. I also tried the workaround from the AppDB entry for Animation:Master (start AgentSvr.exe by hand first, set it to Windows 98 in winecfg). It changes nothing here. Tested on wine-11.15, 32-bit MS Agent 2.0 Core in a clean WoW64 prefix. I can attach the +ole logs for both the script and a real application if that helps. -- 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 5

[Bug 55002] New: Product Manager by IK Multimedia does not let you type text
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=55002 Bug ID: 55002 Summary: Product Manager by IK Multimedia does not let you type text Product: Wine Version: 8.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hadresadri(a)gufum.com Distribution: --- IK Multimedia Manager https://www.ikmultimedia.com/products/productmanager/ will not let you input text in the home screen which essentially renders it useless as you can't log in. Also, I have discovered with bottles this can be avoided however even if you do manager to get it open it won't let you download anything, it will just freeze and crash -- 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 7

[Bug 54716] New: Hard Time (2007): incorrect text rendering caused by font anti-aliasing
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=54716 Bug ID: 54716 Summary: Hard Time (2007): incorrect text rendering caused by font anti-aliasing Product: Wine Version: 4.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: liamstevens2287(a)gmail.com Distribution: --- Created attachment 74224 --> https://bugs.winehq.org/attachment.cgi?id=74224 A screenshot of 2007's 'Hard Time' showing incorrect font rendering on the left, with the intended appearance on the right. Distros tested: Arch Linux, EndeavourOS, SteamOS Versions tested: Wine 4.21, 7.2, 8.3, 8.4, and all versions of Valve Proton 2007 indie game 'Hard Time' incorrectly displays white outlines around all text, caused by font anti-aliasing being forced. On Windows, the game correctly runs with no AA without tweaking required by the user. Disabling font anti-aliasing at the Xorg level or by using your DE's options works around this, as there is no way to disable font AA in Wine itself (that I can tell). The game is free, and the official download is located at http://www.mdickie.com/downloads.htm (direct link at http://www.mdickie.com/downloads/new/hardtime_setup.exe) Attached is an image of two screenshots with font anti-aliasing enabled on the left, and disabled on the right to show the intended appearance. As this is my first Wine bug, please do tell me if there is any other information which is needed. Many 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 3

[Bug 60181] New: Bengali fonts don't handle subjoined letters
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60181 Bug ID: 60181 Summary: Bengali fonts don't handle subjoined letters Product: Wine Version: 11.15 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: afifsworld132(a)gmail.com Target Milestone: --- Created attachment 81849 --> http://bugs.winehq.org/attachment.cgi?id=81849 Log of appwiz.cpl with +gdi,+uniscribe,+font System: MacBook Pro M1 (2020), macOS 14.1.1, Wine Staging 11.15, DXMT 0.80 I have been trying to localize Bangla (Bangladesh) for wine. When I ran my changes, I saw the text's were broken up due to conjoined letters not being properly handled (য-ফলা,ব-ফলা,র-ফলা). A screenshot of it and a log are given. -- 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 6

[Bug 55538] New: Bad graphics rendering in VirtualDJ
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=55538 Bug ID: 55538 Summary: Bad graphics rendering in VirtualDJ Product: Wine Version: 8.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bique.alexandre(a)gmail.com Distribution: --- Created attachment 75096 --> https://bugs.winehq.org/attachment.cgi?id=75096 VirtualDJ Screenshot VirtualDJ is a DJ software. https://virtualdj.com The graphics rendering in VirtualDJ is broken. The font looks crippled. There are a bunch of gradients which are plain black. The interface flickers. I'm using Archlinux, Gnome/X11, nvidia. This message comes a lot: 0190:fixme:d2d:d2d_text_renderer_DrawGlyphRun Ignoring options 0x2. This also happens: vkd3d:fixme:d3d12_device_MakeResident iface 0000000003A4AC10, object_count 1, objects 0000000001C872C8 stub! vkd3d:fixme:d3d12_root_signature_init_descriptor_table_push_constants Push constants size 260 exceeds maximum allowed size 256. Try VKD3D_CONFIG=virtual_heaps. 0110:fixme:win:RegisterTouchWindow hwnd 0000000000040084, flags 0x2 stub! 0190:err:sync:RtlpWaitForCriticalSection section 000000014448FB50 (null) wait timed out in thread 0190, blocked by 0110, retrying (60 sec) 0190:err:sync:RtlpWaitForCriticalSection section 000000014448FB50 (null) wait timed out in thread 0190, blocked by 0110, retrying (60 sec) 0190:err:sync:RtlpWaitForCriticalSection section 000000014448FB50 (null) wait timed out in thread 0190, blocked by 0110, retrying (60 sec) Cheers, Alex -- 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 11

[Bug 60180] New: UpdateLayeredWindow ignores a PALETTEINDEX colour key (ULW_COLORKEY)
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60180 Bug ID: 60180 Summary: UpdateLayeredWindow ignores a PALETTEINDEX colour key (ULW_COLORKEY) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Microsoft Agent 2.0 (AgentSvr.exe, part of the free MS Agent runtime) draws its character in a layered window. With +relay narrowed down to the layered-window calls, this is all it does: Call user32.UpdateLayeredWindow(...,010000fe,00000000,00000001) Ret user32.UpdateLayeredWindow() retval=00000001 dwFlags is ULW_COLORKEY, pblend is NULL, and crKey is 0x010000FE, i.e. PALETTEINDEX(254). The character bitmaps inside the .acs file are 8-bit paletted and entry 254 is the transparent colour, which on screen is #00FFFF. SetWindowRgn is never called, so the colour key is the only thing that is supposed to cut the background away. Wine returns success but the window stays completely opaque: the character sits on a solid cyan rectangle instead of on the desktop. It looks like the key is compared against the raw COLORREF and PALETTEINDEX is never resolved through the source DC palette. I checked the same trace on 7.0 and on 10.0: identical call, same crKey, and SetWindowRgn is not called on either. This is not a regression - I get the same cyan rectangle on every version where the character loads at all. Colour keying itself is not missing in general - bug 15118 implemented it back in 2012. What looks unhandled here is specifically the PALETTEINDEX form of crKey. I have not tested a plain RGB key against this application myself, so treat that last part as a reading of the trace rather than a measurement. -- 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 60182] New: Nested user-mode callback limit is 64, Windows stops around 32; deep WM_SHOWWINDOW recursion then makes unrelated CreateWindowEx calls fail
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60182 Bug ID: 60182 Summary: Nested user-mode callback limit is 64, Windows stops around 32; deep WM_SHOWWINDOW recursion then makes unrelated CreateWindowEx calls fail Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)list.winehq.org Reporter: Wagner.a18(a)yahoo.com Target Milestone: --- Distribution: --- ================================================================================ DESCRIPTION ================================================================================ dlls/win32u/message.c limits how deeply window messages may nest: #define MAX_WINPROC_RECURSION 64 static LRESULT dispatch_win_proc_params(...) { if (thread_info->msg_call_depth > MAX_WINPROC_RECURSION) return 0; Windows has the same kind of limit, and it applies under the same condition (only to messages that do not take the client-side fast path), but it stops at roughly half that depth. Measured with the two probes attached to this report: Windows Wine 11.15 ShowWindow(SW_HIDE) recursion 31 65 nested SendMessage, no hook 300* 300* nested SendMessage, with a WH_CALLWNDPROC hook installed 31 65 WS_VISIBLE set inside handler yes yes * 300 is the probe's own cap; neither system stopped before it. So Wine's structure is already right - both systems count only the messages that go through a kernel/user callback, which is why a plain same-thread SendMessage is unlimited until a hook is installed. Only the ceiling differs. Two things follow that are worth stating explicitly, because both were wrong guesses on the way here: - Wine sending WM_SHOWWINDOW before it clears WS_VISIBLE is NOT a bug. Windows does the same; the flag is still set inside the handler there too. - The recursion itself is not the bug. Windows recurses as well, it just stops sooner. ================================================================================ WHY THE HIGHER LIMIT IS HARMFUL ================================================================================ Exceeding the limit is not graceful. dispatch_win_proc_params() returns 0 *without calling the window procedure*, and the caller cannot tell that apart from a window procedure that legitimately returned 0. For WM_NCCREATE a return of 0 means "the window refuses to be created", so every CreateWindowEx() issued while the counter is pinned fails: warn:win:NtUserCreateWindowEx 0x70240: aborted by WM_NCCREATE An application that recurses deeply for its own reasons therefore does not just lose the recursion, it loses unrelated window creation happening inside it. The lower Windows ceiling keeps applications out of that region; Wine's does not. ================================================================================ STEPS TO REPRODUCE ================================================================================ Both probes are C# using P/Invoke, so they need no toolchain: csc.exe ships with every Windows install and runs under Wine as well. %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\csc.exe /nologo ShowHideProbe.cs ShowHideProbe.exe %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\csc.exe /nologo NestProbe.cs NestProbe.exe (Use Framework instead of Framework64 on 32-bit Windows.) ShowHideProbe hides a window from inside its own WM_SHOWWINDOW handler and reports the nesting depth reached plus whether WS_VISIBLE is still set. NestProbe sends a plain WM_APP message to a window from that window's own handler, once without a hook and once with WH_CALLWNDPROC installed. ACTUAL (wine-11.15) EXPECTED (measured on Windows 10) ShowHideProbe: depth 65 ShowHideProbe: depth 31 NestProbe: 300 / 65 NestProbe: 300 / 31 ================================================================================ REAL-WORLD IMPACT ================================================================================ Found in LASAL Class 2 (Sigmatek), an MFC 14 application using CodeJock Xtreme Toolkit. While building its docking panes, CodeJock hides a pane from that pane's own WM_SHOWWINDOW handler. With Wine's ceiling the recursion ran to 257 (with the limit temporarily raised for measurement) instead of stopping where Windows would, one window being notified 256 times in a row with cmd=SW_HIDE show_flag=0 was_visible=1. With msg_call_depth pinned, the WM_NCCREATE of docking panes still being created is answered with 0. The first failing class is XTPDockingPaneAutoHidePanel. MFC turns the CreateWindowEx failure into a CResourceException and shows its generic AFX_IDP_FAILED_RESOURCE_LOAD message box ("A required resource was unavailable"). Because that box is modal, MFC calls EnableWindow(FALSE) on the main frame: the splash screen never goes away, the menu bar is never painted, and no click is accepted. The dialog reappears on every menu hover. The application is unusable, while the message points at a missing resource that does not exist - no resource lookup ever fails. ================================================================================ SUGGESTED FIX ================================================================================ Lowering the ceiling to match the measurement is sufficient; nothing else was needed: -#define MAX_WINPROC_RECURSION 64 +#define MAX_WINPROC_RECURSION 32 With this one-line change and no other patch, LASAL Class 2 starts normally: 0 "aborted by WM_NCCREATE" (was 4), no leftover splash screen, no message box, and the main window reaches its full title. dlls/user32:win and dlls/user32:msg produce byte-identical failure sets with and without the change (5 resp. 1 pre-existing failures), compared against a purpose-built unpatched tree. Two caveats worth a maintainer's judgement: - Exact value. With MAX_WINPROC_RECURSION at 32 Wine reports depth 33 where Windows reports 31, because the check is "depth > MAX" against a zero-based counter. Matching Windows exactly would need the comparison adjusted as well. I left that alone since the constant's history is unknown to me. - The failure mode. Even at the correct depth, returning 0 for a WM_NCCREATE that was never dispatched is indistinguishable from a genuine refusal. If Windows behaves differently once the ceiling is reached, that is a separate issue this report does not settle. All numbers above for "Windows" were measured on a Windows 10 VM; the Wine numbers on wine-11.15 (Arch Linux package build). -- 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