[Bug 49055] New: Multiple .NET WPF 4.x applications show black screen or have broken user interface rendering
https://bugs.winehq.org/show_bug.cgi?id=49055 Bug ID: 49055 Summary: Multiple .NET WPF 4.x applications show black screen or have broken user interface rendering Product: Wine Version: 5.7 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, separated from https://bugs.winehq.org/show_bug.cgi?id=45774#c6 Solmis v2.4 requires at least .NET Framework 4.5.2 ('winetricks -q dotnet452') Additionally 'winetricks -q corefonts' later. http://solmis.agoraplus.com/ http://solmis.agoraplus.com/ZippedInstall/Install.zip With .NET Framework 4.5.2 installed, click-once installer technology (dfsvc) is used which downloads additional 88 MB. After the splash window there is a login dialog supposedly shown but the client area is rendered (overlayed?) black. Moving the mouse cursor into bottom right corner and clicking the 'info' icon (briefly revealed) makes the user interface render. --- snip --- $ WINEDEBUG=+process,+loaddll wine ./setup.exe >>log.txt 2>&1 ... 00e0:trace:process:SetEnvironmentVariableW (L"__COR_COMMAND_LINE_APP_FULL_NAME__" L"http://solmis.agoraplus.com/Solmis.Client.application#Solmis.Client.applicat..., Version=2.4.3.140, Culture=neutral, PublicKeyToken=bbf7981b5975ac11, processorArchitecture=x86/Solmis.Client.exe, Version=2.4.3.140, Culture=neutral, PublicKeyToken=bbf7981b5975ac11, processorArchitecture=x86"...) 00e0:trace:process:CreateProcessInternalW app (null) cmdline L"\"C:\\users\\focht\\Local Settings\\Application Data\\Apps\\2.0\\WOQPTZWG.M8V\\PQEDRA2Y.KYX\\solm..tion_bbf7981b5975ac11_0002.0004_38571e05ef5065e8\\Solmis.Client.exe\"" 00fc:fixme:dwmapi:DwmAttachMilContent (00030042) stub 0134:fixme:driver:GdiEntry13 stub 0134:fixme:dwrite:dwritefactory_CreateMonitorRenderingParams (0x1): monitor setting ignored 0134:fixme:d3d:wined3d_check_device_format_conversion output 0x4f47488, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B8G8R8X8_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub! 00fc:fixme:path:parse_url failed to parse L"PresentationFramework-SystemCore" 00fc:fixme:path:parse_url failed to parse L"PresentationFramework-SystemXml" 00fc:fixme:path:parse_url failed to parse L"PresentationFramework-SystemData" 00fc:fixme:path:parse_url failed to parse L"UIAutomationTypes" ... 0134:fixme:dwmapi:DwmIsCompositionEnabled 0F42FDF4 0134:fixme:d3d:wined3d_check_device_format_conversion output 0x4f47488, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_B8G8R8A8_UNORM, dst_format WINED3DFMT_B8G8R8X8_UNORM stub! 0144:fixme:d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts. 0144:fixme:d3d:state_lastpixel Last Pixel Drawing Disabled, not handled yet 0134:fixme:path:parse_url failed to parse L"Solmis.Client.resources" 0134:fixme:d3d9:Direct3DShaderValidatorCreate9 Returning stub validator 0F464038. --- snip --- Workaround: https://docs.microsoft.com/en-us/dotnet/framework/wpf/graphics-multimedia/gr... --- snip --- $ wine reg add "HKCU\\SOFTWARE\\Microsoft\\Avalon.Graphics" /v DisableHWAcceleration /t REG_DWORD /d 1 /f --- snip --- Although I mentioned this workaround in bug 45871 ("Several .NET 4.7 WPF applications crash with HLSL shader parsing failure when using builtin 'd3dcompiler_47.dll'") as well, d3dcompiler is not used in this case. $ sha1sum Install.zip d406efdd6a61a7291bbb8a8dad58847182dfa557 Install.zip $ du -sh Install.zip 40M Install.zip $ wine --version wine-5.7-97-g7ccc45f754 Regards -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49055 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://web.archive.org/web | |/20190725054518/http://solm | |is.agoraplus.com/ZippedInst | |all/Install.zip Keywords| |dotnet, 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.
https://bugs.winehq.org/show_bug.cgi?id=49055 Jinoh Kang <jinoh.kang.kr(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr(a)gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=49055 brandow <brandowlucas@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brandowlucas@gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=49055 --- Comment #1 from brandow <brandowlucas@gmail.com> --- I can reproduce the same with NinjaTrader 8 login screen.
--- snip --- $ wine reg add "HKCU\\SOFTWARE\\Microsoft\\Avalon.Graphics" /v DisableHWAcceleration > /t REG_DWORD /d 1 /f --- snip ---
Fixes the issue in my case. https://web.archive.org/web/20260630193746/https://download.ninjatrader.com/... After installation, ninjatrader will be installed at: drive_c⁄ Program_Files/NinjaTrader 8/bin/NinjaTrader.exe and its runtime dependencies at: drive_c/users/%USERPROFILE%/documents/NinjaTrader 8 It requires dotnet48 installed in order to launch (https://bugs.winehq.org/show_bug.cgi?id=59948). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=49055 realmaitreal@deadmail.lat changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |realmaitreal@deadmail.lat --- Comment #2 from realmaitreal@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.
http://bugs.winehq.org/show_bug.cgi?id=49055 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #3 from Stian Low <wineryyyyy@gmail.com> --- (In reply to realmaitreal from comment #2)
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. Attached test copied to ./dlls/d3d9/tests/visual.c with results:
******************* WINE_D3D_CONFIG=csmt=0x1,renderer=gl WINEDEBUG=-all WINE_D3D_CONFIG=csmt=0x1,renderer=gl WINEPREFIX=/home/any/wine_stianlow_wow64_new_pfx_d3d9_tests PATH=/home/any/tmp/wine_stianlow_wow64_new_install/bin:$PATH ~/tmp/wine_stianlow/tools/runtest -T /home/any/tmp/wine_stianlow_wow64_new_build -p /home/any/tmp/wine_stianlow_wow64_new_build/dlls/d3d9/tests/x86_64-windows/d3d9_test.exe visual visual.c:29429:Driver string: "atiumdag.dll" visual.c:29430:Description string:"ATI Radeon HD 5600 Series" visual.c:29433:Device name string:"\\.\DISPLAY1" visual.c:29435:Driver version9.21.10.1280 Clear(0, NULL, D3DCLEAR_TARGET) clears the viewport only. (10,10) lies outside the 100x100 viewport at (100,100), so after a full-surface red clear it must stay 0xff0000. Fresh device per case. Device9 COPY implicit no present (10,10)=0xff0000ok Device9 COPY implicit after present (10,10)=0xff0000ok Device9 COPY additional no present (10,10)=0xff0000ok Device9 COPY additional after present (10,10)=0xff0000ok Device9 DISCARD implicit no present (10,10)=0xff0000ok Device9 DISCARD implicit after present (10,10)=0xff0000ok Device9 DISCARD additional no present (10,10)=0xff0000ok Device9 DISCARD additional after present (10,10)=0xff0000ok Device9Ex COPY implicit no present (10,10)=0xff0000ok Device9Ex COPY implicit after present (10,10)=0xff0000ok Device9Ex COPY additional no present (10,10)=0xff0000ok Device9Ex COPY additional after present (10,10)=0xff0000ok Device9Ex DISCARD implicit no present (10,10)=0xff0000ok Device9Ex DISCARD implicit after present (10,10)=0xff0000ok Device9Ex DISCARD additional no present (10,10)=0xff0000ok Device9Ex DISCARD additional after present (10,10)=0xff0000ok ******************* WINE_D3D_CONFIG=csmt=0x1,renderer=vulkan WINEDEBUG=-all WINE_D3D_CONFIG=csmt=0x1,renderer=vulkan WINEPREFIX=/home/any/wine_stianlow_wow64_new_pfx_d3d9_tests PATH=/home/any/tmp/wine_stianlow_wow64_new_install/bin:$PATH ~/tmp/wine_stianlow/tools/runtest -T /home/any/tmp/wine_stianlow_wow64_new_build -p /home/any/tmp/wine_stianlow_wow64_new_build/dlls/d3d9/tests/x86_64-windows/d3d9_test.exe visual visual.c:29429:Driver string: "aticfx32.dll" visual.c:29430:Description string:"AMD Radeon Graphics (RADV RENOIR)" visual.c:29433:Device name string:"\\.\DISPLAY1" visual.c:29435:Driver version9.21.23013.1023 Clear(0, NULL, D3DCLEAR_TARGET) clears the viewport only. (10,10) lies outside the 100x100 viewport at (100,100), so after a full-surface red clear it must stay 0xff0000. Fresh device per case. Device9 COPY implicit no present (10,10)=0xff0000ok Device9 COPY implicit after present (10,10)=0xff0000ok Device9 COPY additional no present (10,10)=0xff0000ok Device9 COPY additional after present (10,10)=0xff0000ok Device9 DISCARD implicit no present (10,10)=0xff0000ok Device9 DISCARD implicit after present (10,10)=0xff0000ok Device9 DISCARD additional no present (10,10)=0xff0000ok Device9 DISCARD additional after present (10,10)=0xff0000ok Device9Ex COPY implicit no present (10,10)=0xff0000ok Device9Ex COPY implicit after present (10,10)=0xff0000ok Device9Ex COPY additional no present (10,10)=0xff0000ok Device9Ex COPY additional after present (10,10)=0xff0000ok Device9Ex DISCARD implicit no present (10,10)=0xff0000ok Device9Ex DISCARD implicit after present (10,10)=0xff0000ok Device9Ex DISCARD additional no present (10,10)=0xff0000ok Device9Ex DISCARD additional after present (10,10)=0xff0000ok -- 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.
http://bugs.winehq.org/show_bug.cgi?id=49055 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase -- 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.
http://bugs.winehq.org/show_bug.cgi?id=49055 --- Comment #4 from realmaitreal@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.
http://bugs.winehq.org/show_bug.cgi?id=49055 --- Comment #5 from Stian Low <wineryyyyy@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.
http://bugs.winehq.org/show_bug.cgi?id=49055 --- Comment #6 from Stian Low <wineryyyyy@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.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla