- Wine-bugs - list.winehq.org

[Bug 59370] New: WebView2 109: Window renders blank (white/black) - Chromium compositor D3D11 shared texture path broken
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=59370 Bug ID: 59370 Summary: WebView2 109: Window renders blank (white/black) - Chromium compositor D3D11 shared texture path broken Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: stan(a)stanstaykov.com Distribution: --- Created attachment 80314 --> http://bugs.winehq.org/attachment.cgi?id=80314 Experiment Log WebView2-based applications (Superwhisper, and likely other Electron/Tauri/WebView2 apps) display blank white or black windows. The application launches, audio plays, windows appear, but no UI content is visible. Affected configurations: Native Wayland (winewayland.drv) XWayland Multiple Wine versions tested (11.x, custom builds) WebView2 runtime: 109.0.1518.78 Download link: https://superwhisper.com (free trial available) Root Cause Analysis Extensive debugging (50+ experiments) traced the failure to Wine's D3D11 shared texture and DirectComposition implementation. What Works Chromium renderer produces content - DevTools Protocol (CDP) screenshots show correct UI D3D11 device creation succeeds - Feature queries return expected values Draw calls execute - wined3d logs show active rendering ANGLE contexts created - eglInitialize, eglCreateContext, eglMakeCurrent succeed Wayland surfaces commit - SHM buffers are attached and committed What Fails No EGL surfaces created - eglCreateWindowSurface/eglCreatePbufferSurface never called (surfaceless ANGLE) No shared texture APIs called - IDXGIResource1::CreateSharedHandle and ID3D11Device::OpenSharedResource never invoked UpdateSubresource writes zeros - Texture uploads happen but data is all zeros PS shader resources are blank - Textures bound to pixel shader contain no data Final composite samples blank inputs - Even with forced patterns upstream, final pass reads zeros Architecture Mismatch Chromium's compositor architecture expects: ANGLE renders → D3D11 shared textures → viz compositor → DComp swapchain → present Wine's implementation gap: ANGLE runs surfaceless (no window/pbuffer surfaces) Chromium uses internal SharedImageBackingD3D for GPU→compositor handoff This shared-image mailbox system bypasses normal D3D11 API surfaces Wine's D3D11 never sees the actual rendered content Key Evidence Experiment AK (CDP screenshot): DevTools screenshot: NONBLANK (renderer works) Wayland SHM dump: BLANK (presentation broken) Experiment AP (libEGL proxy): eglInitialize: succeeds eglCreateContext: succeeds (multiple contexts) eglCreateWindowSurface: never called eglCreatePbufferSurface: never called eglSwapBuffers: never called Experiment BM (shared handle probe): CreateSharedHandle: never called OpenSharedResource: never called Experiment BT (UpdateSubresource trace): Uploads occur to textures later bound as SRVs All BGRA texture uploads have nz=0 (first 64 bytes zero) Data generation upstream is the failure point Reproduction Steps Install WebView2 runtime 109.0.1518.78 Install Superwhisper (or any WebView2-based app) Launch with Wine Observe blank white/black window (audio may play) Attempted Workarounds (all failed) DXVK (d3d11/dxgi replacement) Software rendering (llvmpipe) SwiftShader Vulkan ICD --disable-gpu / --disable-gpu-compositing / --in-process-gpu --disable-direct-composition Various ANGLE backends (--use-angle=gl, swiftshader, vulkan) Force builtin/native DLL combinations DComp stub implementations (even with successful Present calls) Forced texture writes (patterns appear in intermediate RTVs but not final output) Technical Attachments Full experiment log attached (~50 experiments with detailed findings). Impact This likely affects all WebView2-based Windows applications: Electron apps using WebView2 backend Tauri apps Native Windows apps embedding web content Any Chromium-embedded application using DirectComposition WebView2 adoption is growing rapidly, so this gap will affect an increasing number of applications. Suggested Fix Direction The shared-image path between ANGLE and Chromium's viz compositor needs Wine support for: D3D11 shared textures with NT handles - ID3D11Texture2D with D3D11_RESOURCE_MISC_SHARED_NTHANDLE Cross-process texture sharing - IDXGIResource1::CreateSharedHandle / ID3D11Device1::OpenSharedResource1 Keyed mutex synchronization - IDXGIKeyedMutex for producer/consumer sync Alternatively, a more invasive approach would be patching ANGLE's Windows backend to use a Wine-compatible sharing mechanism. keywords: d3d11, dxgi, dcomp, webview2 -- 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 4

[Bug 58564] New: Several NuGet "signature's certificate not trusted" errors while building WPF Projects Under Wine
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=58564 Bug ID: 58564 Summary: Several NuGet "signature's certificate not trusted" errors while building WPF Projects Under Wine Product: Wine Version: 10.12 Hardware: x86-64 URL: https://builds.dotnet.microsoft.com/dotnet/Sdk/8.0.412 /dotnet-sdk-8.0.412-win-x64.exe && wine dotnet-sdk-8.0.412-win-x64.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: Debian This was reported on the forum: https://forum.winehq.org/viewtopic.php?t=41073 Steps to reproduce can be found in that link or below: Steps to reproduce: 1. wget https://builds.dotnet.microsoft.com/dotnet/Sdk/8.0.412/dotnet-sdk-8.0.412-w… && wine dotnet-sdk-8.0.412-win-x64.exe 2. git clone https://github.com/iplus-framework/iPlus 3. wine cmd 4. cd iPlus/gip.ext.design\project 5. dotnet build gip.ext.design.csproj /p:Configuration=Debug /p:Platform="Any CPU" There appear several errors like: Z:\home\louis\ramdisk\iPlus\gip.ext.design\project\gip.ext.design.csproj : erro r NU3037: Package 'System.Private.ServiceModel 4.10.0' from source 'https://api .nuget.org/v3/index.json': The repository countersignature validity period has expired. Z:\home\louis\ramdisk\iPlus\gip.ext.design\project\gip.ext.design.csproj : erro r NU3028: Package 'System.Private.ServiceModel 4.10.0' from source 'https://api .nuget.org/v3/index.json': The repository countersignature's timestamping certi ficate is not trusted by the trust provider. In the link there's some more info --> "https://github.com/NuGet/Home/issues/13252, this appears to be related to .NET's enhanced certificate validation introduced in recent versions" -- 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 4

[Bug 59352] New: Metatrader 5 does not launch, gives an error message instead
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=59352 Bug ID: 59352 Summary: Metatrader 5 does not launch, gives an error message instead Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: luke2135(a)gmail.com Distribution: --- MetaTrader 5 and MetaEditor 5 does not launch. An error message appears stating "A debugger has been found running in your system please unload it from memory and restart your program." It seems to effect Wine version 10.0. It is possible 11.1 (Staging) fixes this bug. -- 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 59193] New: Wine and MT4 don't work together very well
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=59193 Bug ID: 59193 Summary: Wine and MT4 don't work together very well Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: j-nws23(a)planet.nl Distribution: --- ✅ WINE Bug Report Author: ChatGPT Title: MT4 floating “Market Watch” window forces Wine topmost/focus-stealing behavior for all Wine windows Wine version: 9.0~repack-4build3 (Ubuntu package) Distribution: Linux Mint 22.2 Cinnamon 6.4.8 Muffin (X11 session) Application affected: MetaTrader 4 (MT4), build 1443 Also affects unrelated Wine applications (IrfanView, winecfg, etc.) Overview When MetaTrader 4's Market Watch panel is set to floating, MT4 triggers a Wine-wide focus and stacking problem: MT4’s main window and its floating windows become always-on-top Hovering the mouse over MT4 steals focus without clicking Other Wine applications (e.g., IrfanView, Winecfg) become topmost or behave incorrectly Docking the Market Watch window immediately restores normal behavior The issue does not occur in native Windows The bug appears to be caused by how MT4 requests window styles for the floating tool window, and how Wine interprets them. Steps to Reproduce Install MetaTrader 4 build 1443 in Wine 9.0 on Linux Mint 22.2 Cinnamon (X11). Start MT4. Open View → Market Watch. Right-click the Market Watch panel and select Docked → uncheck (floating mode). Move the floating Market Watch panel anywhere. Move the mouse over MT4 or over other Wine windows such as Winecfg or IrfanView. Actual Behavior MT4 forces itself to the top of the stacking order. MT4 grabs focus on mouse hover, without any click. Any other Wine window: may be pushed behind MT4 may adopt the same "tool window" styling may become unresponsive to normal focus rules Behavior persists until Market Watch is docked again. Expected Behavior MT4 floating tool windows should not force global focus-stealing. Other Wine applications should retain normal stacking and focus behavior. Floating Market Watch should behave like the floating Data Window, which does not cause any of these issues. Additional Notes The issue occurs even with a fresh Wine prefix. Both “direct rendering” and Mesa/i915 driver stack are normal. No compositor issues exist (Cinnamon compositor fully active). This behavior did not happen on Windows. MT4’s Data Window uses a different style and does not trigger the bug, suggesting MT4 applies the WS_EX_TOOLWINDOW or WS_EX_TOPMOST flag to Market Watch but Wine may be misinterpreting or forcing additional behaviors. Suggested Component Likely related to: win32u user32 window style handling for tool windows Workaround Docking the Market Watch window restores normal behavior and stops focus stealing. Impact This behavior makes MT4 nearly unusable under Wine with floating panels and affects unrelated Wine applications by corrupting stacking and focus behavior across the session. -- 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 59346] New: WineMine: lacking fallback option for "difficulty", "Width", ... reading in Registry leading to wrong menu check mark
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=59346 Bug ID: 59346 Summary: WineMine: lacking fallback option for "difficulty", "Width", ... reading in Registry leading to wrong menu check mark Product: Wine Version: 11.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Created attachment 80282 --> http://bugs.winehq.org/attachment.cgi?id=80282 Incorrect width for beginner Open Regedit and change "Difficulty" to an invalid value (eg: 99) Start Winmine Opens with last used row/col but does not set any difficulty (does not recognize from row/col and does not set custom) Guilty Code: SetDifficulty function where CheckMenuItem( hMenu, IDM_BEGINNER + difficulty, MF_CHECKED ); while p_board->difficulty is not checked for being in acceptable bounds : programs/winemine/main.c -- 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 39005] New: "http://xml.org/sax/features/namespace-prefixes" default value
by wine-bugs＠winehq.org 26 Feb '26

26 Feb '26

https://bugs.winehq.org/show_bug.cgi?id=39005 Bug ID: 39005 Summary: "http://xml.org/sax/features/namespace-prefixes" default value Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: msxml3 Assignee: wine-bugs(a)winehq.org Reporter: ott(a)mirix.org Distribution: --- The specification is ambigous about this feature: "the "http://xml.org/sax/features/namespace-prefixes" feature is set to True. (It is False by default.)" (https://msdn.microsoft.com/en-us/library/ms757829%28v=vs.85%29.aspx) "only if the "http://xml.org/sax/features/namespace-prefixes" feature is set to True. This feature is set to False by default." (https://msdn.microsoft.com/en-us/library/ms762302%28v=vs.85%29.aspx) "The default value is true." (https://msdn.microsoft.com/en-us/library/ms759146%28v=vs.85%29.aspx) "namespace-prefixes | Boolean | True" (https://msdn.microsoft.com/en-us/library/ms762317%28v=vs.85%29.aspx) It should clarified from Microsoft's implementation whether the feature is enabled by default or not. Maybe the "namespace-prefixes" and "http://xml.org/sax/features/namespace-prefixes" are two different features? Perhaps it also makes sense notify Microsoft about the inconsistency. -- 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 2

[Bug 59309] New: Wine regression, FreeArc external algorithm (cls-lolz_x64.exe) stopped working since wine 10.7
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=59309 Bug ID: 59309 Summary: Wine regression, FreeArc external algorithm (cls-lolz_x64.exe) stopped working since wine 10.7 Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: obscurexwing(a)disroot.org Distribution: --- //the actual problem The cls-lolz module acts as an external algorithm for FreeArc to handle high-ratio compression FreeArc with CLS-LOLZ to unpack data now just does nothing since wine 10.7, every version of wine after version 10.6 are exposed to this bug, including new 11.1. Expected behaviour (like on wine 10.6) : if program uses FreeArc with CLS-LOLZ, data unpacking process will spawn "cls-lolz_x64.exe" in task manager, and unpacking process will start Actual behaviour (10.7-11.1) : if program uses FreeArc with CLS-LOLZ, data unpacking will not happen, process "cls-lolz_x64.exe" will not appear in task manager, and files unpacking process completely stuck at this point //where you can find CLS-LOLZ ? For example, actual program placed here : https://github.com/CarldricGaming/Mini-Compressor 1.Download archive from github releases 2.Install program 3.Go to \%INSTALLPATH%\_MiniCompressor\Releases\Compression\FreeArc\LZ\ 4.Program that need to catch your attention placed here, with name "lolz_x64.exe" 5.Run with cmd through wine, like this : wine cmd C: cd _MiniCompressor\Releases\Compression\FreeArc\LZ\ lolz_x64.exe and you will get something like lolz v22c4b [Dec 30 2018 20:15:58] Settings: *this will output various launch options like -mt -bc -bm etc* -- 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 59272] New: COM ports resolved relative to working directory instead of dosdevices
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

http://bugs.winehq.org/show_bug.cgi?id=59272 Bug ID: 59272 Summary: COM ports resolved relative to working directory instead of dosdevices Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: hilgert(a)mail.ru Distribution: --- Wine incorrectly resolves COM port paths relative to the current working directory instead of using the symlinks in ~/.wine/dosdevices/, causing CreateFile() calls for COM ports to fail when the application is launched from subdirectories. STEPS TO REPRODUCE: 1. Create a symlink in dosdevices: ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1 2. Create a test application that calls: CreateFile("COM1", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); 3. Run the application from C:\: cd ~/.wine/drive_c/ wine test.exe Result: COM1 opens successfully via /dev/ttyUSB0 4. Run the application from a subdirectory: cd ~/.wine/drive_c/subdir/ wine test.exe Result: CreateFile fails with ERROR_FILE_NOT_FOUND EXPECTED BEHAVIOR: COM ports should always resolve through dosdevices symlinks regardless of working directory, matching Windows behavior where COM1 is a global device namespace. ACTUAL BEHAVIOR: Wine attempts to open "C:\subdir\COM1" as a regular file instead of resolving COM1 through dosdevices. DEBUG TRACE: trace:file:CreateFileW L"COM1" GENERIC_READ GENERIC_WRITE creation 3 attributes 0x0 trace:file:NtCreateFile name=L"\\??\\C:\\subdir\\COM1" warn:file:NtCreateFile L"\\??\\C:\\subdir\\COM1" not found (c0000034) WORKAROUND: Creating a symlink directly in the working directory allows the application to open the port, but this is not portable and breaks when changing directories: ln -s /dev/ttyUSB0 ~/.wine/drive_c/subdir/COM1 ADDITIONAL NOTES: This affects serial communication applications that rely on standard COM port naming conventions. The issue appears to be in how Wine's file path resolution handles device names. On real Windows, device names like COM1, LPT1, etc. are resolved through the device namespace regardless of the current directory. -- 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 7

[Bug 53843] New: coturn support
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

https://bugs.winehq.org/show_bug.cgi?id=53843 Bug ID: 53843 Summary: coturn support Product: Packaging Version: unspecified Hardware: x86-64 OS: other Status: UNCONFIRMED Severity: blocker Priority: P2 Component: wine-packages Assignee: wine-bugs(a)winehq.org Reporter: Neustradamus(a)hotmail.com CC: dimesio(a)earthlink.net Can you look to add the WINE support of coturn directly in software? There is a ticket here, answer is needed: - https://github.com/coturn/coturn/issues/1044 Thanks in advance. -- 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 5

[Bug 57706] New: 0414:err:msxml:mxwriter_QueryInterface interface {e19c7100-9709-4db7-9373-e7b518b47086} not implemented
by WineHQ Bugzilla 26 Feb '26

26 Feb '26

https://bugs.winehq.org/show_bug.cgi?id=57706 Bug ID: 57706 Summary: 0414:err:msxml:mxwriter_QueryInterface interface {e19c7100-9709-4db7-9373-e7b518b47086} not implemented Product: Wine Version: 10.0-rc5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msxml3 Assignee: wine-bugs(a)winehq.org Reporter: winehq.tabloid372(a)passmail.net Distribution: --- Hi Nikolay, How can I work out the correct stub to add form the guid? -- 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 4