Staging causes spam of explorer.exe processes #874
Comments
|
Sounds like prefix incompatibility. Can you reproduce that on a fresh prefix? |
Yep, and I can reproduce this on a fresh install of Ubuntu 22.04 too. |
|
I'll have to test that on buntu then, because that issue doesn't exist on Arch. |
It definitely does, it exist on Manjaro too. |
|
I have never experienced it and I'm testing my wine builds daily, so it has to require a specific environment to trigger. |
Me and a few other people have been trying to figure this out for about a week now, we all have different machines with different specs and different distributions, we have yet to find a common denominator for all of us. |
|
Can you reproduce this with the default config or are you using a custom one, or a profile? |
|
If you are referring to the build configuration, I have tried the default one, Caffe's and even custom ones - my conclusion from that is that the problem does not stem from the configuration, but from changes made since 'v7.6' or 'v7.7'. |
|
That would only be confirmed by building a "plain" staging build through wine-tkg and see how that build goes for someone affected. |
|
Importantly, this seems to only affect Intel CPU + Nvidia GPU's running proprietary drivers. My gut lays with some sort of incompatibility around the nvidia drivers. There is NixOS/nixpkgs#195126 which goes slightly into a bit of detail around trying to launch Overwatch 2. And a more generic one fufexan/nix-gaming#27 which was specifically about wine-tkg having explorer.exe explosions. I have yet to really conciser it to be an upstream issue, as i still feel like I must simply be doing something wrong with compiling wine-tkg or how i am running packaged versions like But i have so far heard 2nd hand this |
|
This is me running wine-tkg trough one built by the github action. Specifically Currently, the Logs are of me running Blizzard, clicking run on Overwatch 2, and closing blizzard after the game fails to launch. I created a brand new prefix using this specific wine-tkg-staging version. This is the 2nd run of that prefix. I pulled out a couple of clues from the log file which i think are important. Full file is also below. 0440:fixme:virtual:NtQueryVirtualMemory (0xffffffffffffffff,0x9ea0000,info_class=3,0x11ca60,48,(nil)) Unknown information class
0440:fixme:virtual:NtQueryVirtualMemory (0xffffffffffffffff,0x9ea0000,info_class=3,0x11ca60,48,(nil)) Unknown information class
0440:fixme:heap:RtlSetHeapInformation handle 000000000A310000, info_class 0, info 000000000011DC40, size 4 stub!
wine: Unhandled page fault on read access to FFFFFFFFFFFFFFFF at address 0000000181A3230B (thread 0440), starting debugger...0310:fixme:cryptasn:CRYPT_GetBuiltinDecoder Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.4
0310:fixme:cryptasn:CRYPT_GetBuiltinDecoder Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.4
021c:err:vulkan:X11DRV_vkCreateWin32SurfaceKHR Failed to allocate client window for hwnd=0x100f8
02e8:fixme:file:NtLockFile I/O completion on lock not implemented yet
02e8:fixme:virtual:prefetch_memory (process=0xffffffff,flags=0) NtSetInformationVirtualMemory(VmPrefetchInformation) partial stub
err: Failed to create surface
[1015/233950.061:ERROR:angle_platform_impl.cc(40)] rx::SwapChain11::reset(615): Could not create additional swap chains or offscreen surfaces, HRESULT: 0x80070057
[1015/233950.061:ERROR:gl_surface_egl.cc(787)] EGL Driver message (Critical) eglCreateWindowSurface: Bad allocation.
[1015/233950.061:ERROR:gl_surface_egl.cc(1394)] eglCreateWindowSurface failed with error EGL_BAD_ALLOC
[1015/233950.061:ERROR:in_process_command_buffer.cc(450)] ContextResult::kSurfaceFailure: Failed to create surface.These errors may be tainted by my setup however. I can attempt to reproduce it on a fresh install of Fedora 36 if this is indecisive. Full log file: log.txt |
Honestly I wish, one of my friends that experiences the same issue is using an AMD CPU. |
Running with AMD CPU & GPU - Error still persists. |
This is a totally different problem though. |
|
@Kid0h Are you only spinning your own builds or are you also using prebuilts from bottles or lutris? Have you tested our own CI builds? |
|
Running 2022-10-16 12:32:04,594: Starting Lutris 0.5.11
2022-10-16 12:32:04,647: Using NVIDIA drivers 515.76 for x86_64
2022-10-16 12:32:04,647: GPU: NVIDIA GeForce RTX 2060
2022-10-16 12:32:04,648: GPU: 10DE:1F08 1458:3FC1 (nvidia drivers)
2022-10-16 12:32:04,853: Startup complete
2022-10-16 12:32:19,450: No valid prefix detected in /mnt/scrap/Launchers/BattleNet/pfx, creating one...
2022-10-16 12:32:19,450: Creating a win64 prefix in /mnt/scrap/Launchers/BattleNet/pfxOne thing that may be of note with this, after saying to lutris to force close the blizzard launcher it gives output such as: 2022-10-16 12:34:44,289: Couldn't load shell folder name for Desktop
2022-10-16 12:34:44,290: Couldn't load shell folder name for Personal
2022-10-16 12:34:44,290: Couldn't load shell folder name for My Music
...Before heading into the loop of. 002c:err:msg:get_server_queue_handle Cannot get server thread queue
002c:err:win:get_desktop_window failed to create desktop window
0040:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
002c:err:msg:get_server_queue_handle Cannot get server thread queue
002c:err:win:get_desktop_window failed to create desktop window
0048:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0048:err:system:update_display_cache failed to read display config
0040:err:system:update_display_cache failed to read display config
0040:err:msg:get_server_queue_handle Cannot get server thread queue
0048:err:msg:get_server_queue_handle Cannot get server thread queue
0048:err:win:get_desktop_window failed to create desktop window
0040:err:win:get_desktop_window failed to create desktop window
0048:err:module:DelayLoadFailureHook failed to delay load shell32.dll.SHGetDesktopFolder
wine: Call from 000000007B013B68 to unimplemented function shell32.dll.SHGetDesktopFolder, aborting
0040:err:module:DelayLoadFailureHook failed to delay load shell32.dll.SHGetDesktopFolder
wine: Call from 000000007B013B68 to unimplemented function shell32.dll.SHGetDesktopFolder, aborting
wine: Unimplemented function shell32.dll.SHGetDesktopFolder called at address 000000007B013B68 (thread 0048), starting debugger...
wine: Unimplemented function shell32.dll.SHGetDesktopFolder called at address 000000007B013B68 (thread 0040), starting debugger...
0048:err:seh:start_debugger Couldn't start debugger L"winedbg --auto 68 96" (2)
Read the Wine Developers Guide on how to set up winedbgI think that may be of importance, as it acts as if it cannot build the prefix, and then attempts to read a missing prefix. Giving the Full log file: log.txt Caffe-7.18 has their full TKG recepie listed here, built on Arch Linux with glibc 2.33. |
|
Following this issue: bottlesdevs/wine#44 |
|
Wine-versions built against https://github.com/Tk-Glitch/wine-tkg/tree/c3ce53427372163d7dd899455929cac47c546599 also seem to show this pattern, similar to |
|
Make sure you're not hitting #396 |
|
Removing |
|
Considering the totally broken state of the fshack these days I'm not really surprised someone would hit issues with it, however since the issue supposedly only affects staging and is as old as 7.7, I find it funny that it's only reported now. First, and since this is OW2 related, it reportedly works with wine-staging 7.13 and is only broken on 7.14+. Thing is, due to fshack needing a full rewrite to be made compatible with newer wine (which will happen down the line), we are currently reverting a large portion of winex11/user32/win32u changes to allow for the fshack to work on those newer wine revisions. Those reverts contain the change(s) that broke OW2, which is why it runs on our 7.14+ builds when the fshack feature is patched in, while it doesn't on regular staging 7.14+.
Indeed, if the prefix creation fails, you get a broken state. Attempting to then use that prefix which is broken and incomplete will lead to issues such as unimplemented functions and other random stuff, but that prefix is totally dead and should be wiped.
From the linked issue everyone seems to use an Nvidia GPU (CPU doesn't matter here), and while @fzxn stated they have an AMD GPU I'd like to see a log so we can be sure it's the same issue. edit: Also as a side note, I have grabbed the caffe build to test it out on my end, and faced zero issue with it. |
|
When running spessifically this wine build https://github.com/Frogging-Family/wine-tkg-git/actions/runs/3258899186 It builds the new prefix correctly. BattleNet launches. Clicking Launch on Overwatch 2 pops up a Wine Debugger window that quickly closes again. And the game fails to start (which BattleNet recognizes by changing Running wine from |
That build doesn't have the fshack patched in, so you're hitting the upstream issue I talked about above. |
Exactly, like this comment says, disabling the fullscreen hack makes 3D applications crash with a page fault. |
|
btw, I'll leave the known upstream issue link here: https://bugs.winehq.org/show_bug.cgi?id=53765 |
Honestly, i am not fully sure how. Even running wine logs set to full, there is not a single line written by wine. It does not even open the Running with a different compiled prefix without the |
This is interesting, and shows the same error of My bigger question would be, what magic dust is it that lets |
I have explained it above. See #874 (comment) |
…ack reverts without patching the fshack in. In relation to #874
|
Indeed you have. More so speculation with which part of |
|
I just pushed a test option above. For the ones wanting to test it out building their own, add The test will bring the reverts making OW2 work on 7.14+ without patching the fs hack in. If the issue lies within the reverts, the problem will persist, but if it's due to some bad interaction within the fs hack, it should work. Please let me know how it goes, thanks. |
|
Come with disappointing news. It is still the same kind of error. So it likely comes from the revert that the fshack relies on to apply. Than fshack itself. Running old prefix gives the output below. Attempting to build a new prefix hangs silently, giving no window such as But the files such as WINE REGISTRY Version 2
;; All keys relative to REGISTRY\\User\\.Default
#arch=win64
[] 1665933877
#time=1d8e17366d8bfccNew Started initial process 6722 from gamemoderun /home/sofi/.local/share/lutris/runners/wine/wine-tkg-staging-fsync-git-7.18.r11.gaabde227-327-x86_64/bin/wine /mnt/scrap/Launchers/BattleNet/drive_c/Program Files (x86)/Battle.net/Battle.net.exe
Start monitoring process.
gamemodeauto:
wineserver: using server-side synchronization.
002c:fixme:winediag:LdrInitializeThunk Wine TkG (staging) 7.18 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please don't report bugs about it on winehq.org and use https://github.com/Frogging-Family/wine-tkg-git/issues instead.
0034:err:msg:get_server_queue_handle Cannot get server thread queue
0034:err:win:get_desktop_window failed to create desktop window
0034:err:msg:get_server_queue_handle Cannot get server thread queue
0034:err:win:get_desktop_window failed to create desktop window
0084:err:wineusb:DriverEntry Failed to initialize Unix library, status 0xc0000135.
0084:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\wineusb": c0000135
003c:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 126
0044:err:system:update_display_cache failed to read display config
004c:err:system:update_display_cache failed to read display config
00b0:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
00b0:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
00b0:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
00b0:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
004c:err:msg:get_server_queue_handle Cannot get server thread queue
004c:err:win:get_desktop_window failed to create desktop window
004c:err:module:DelayLoadFailureHook failed to delay load shell32.dll.SHGetDesktopFolder
wine: Call from 000000007B013C2E to unimplemented function shell32.dll.SHGetDesktopFolder, aborting
wine: Unimplemented function shell32.dll.SHGetDesktopFolder called at address 000000007B013C2E (thread 004c), starting debugger...
0044:err:msg:get_server_queue_handle Cannot get server thread queue
0044:err:win:get_desktop_window failed to create desktop window
0044:err:module:DelayLoadFailureHook failed to delay load shell32.dll.SHGetDesktopFolder
wine: Call from 000000007B013C2E to unimplemented function shell32.dll.SHGetDesktopFolder, aborting
wine: Unimplemented function shell32.dll.SHGetDesktopFolder called at address 000000007B013C2E (thread 0044), starting debugger... |
|
Unfortunately I got the same results, I tried testing with Bottles too. |
|
@Kid0h where is your game currently installed? Like the full |
If you're talking about the game itself (as in what battle.net installed), then it's: |
|
Interesting. But i just tested this spessifically too. It does not matter if it is in |
|
I did some Overwatch-specific testing and figured some stuff out. The version that starts spamming explorer.exe for some people is 7.7. Version 7.6 doesn't spam explorer.exe. The first version that can launch the game without it crashing after 5 minutes is 7.15. Earlier Caffe versions don't seem to work. This is good because it means that the change that lets Overwatch run on most people's systems is different from the change that spams explorer.exe, most likely. |
….winehq.org/wine/wine/-/merge_requests/1152 This allows OW2 to run without our fshack specific reverts #874
|
The fix above should allow for the game to run without fs hack so people encountering that issue can simply disable the fs hack and the game will work. |
|
@Tk-Glitch Honestly, I can't thank you enough, have been using the latest Ubuntu CI build and it's been great (except this issue). |
|
Well, I'd love to know. Since I cannot reproduce the issue on any machine I have access to (intel+nvidia and amd+amd desktops, intel+intel and intel+nvidia laptops and a Steamdeck which is amd+amd), I'm unable to find the source of the issue without a detailed log of the wine failure (which nobody was able to provide yet). Admittedly all those machines are running on Archlinux (counting SteamOS as Arch) with plasma (some xorg, some wayland), which is why I was under the impression that it was distro-specific. |
|
Here's "OW2 caffe" runner (downloaded through lutris) with debug output set to "full" (~65MB): view in browser / download |
|
Thanks! |
|
Following 198006c, Valve based builds will now include a fix for OW2 crashing after a few seconds, while not suffering from the issues upstream has these days with explorer.exe crashes or mouse inconsistencies, making it the best way to play the game on Linux currently. |
|
With the fshack now forcefully disabled until it gets rebased, we can close this. |
General info
There are already many issues on other repos which refer to the same problem, here is the best place for it as the problem is with
wine-tkg-stagingitself, and is NOT distro, hardware, driver, lutris or bottles specific.The bug
The issue is that some users cannot use
wine-tkg-stagingwith any executable - as soon as you try to open anything with it, a never ending army ofexplorer.exeprocesses starts spawning - causing all cores of the CPU to reach 100%.This behaviour is present from version
v7.7and up, this issue occurs only withwine-tkgstaging and not in other branches, that means that somewhere in the commits betweenv7.6andv.7.7there is a change that causes this issue.Logs
There are mainly 4 lines in the log that repeat themselves as soon as you start an any application/executable:
err:msg:get_server_queue_handle Cannot get server thread queueerr:win:get_desktop_window failed to create desktop windowwine: Call from 000000007B0138E8 to unimplemented function shell32.dll.SHGetDesktopFolder, abortingwine: Unimplemented function shell32.dll.SHGetDesktopFolder called at address 000000007B0138E8 (thread 0044), starting debugger...The first 2 lines have a thread id suffix and a ":" before the "err", all of these lines endlessly repeat themselves until you kill wine.
I think it's important to note that they repeat themselves each time with a different thread id suffix, but the
Unimplemented function shell32.dll.SHGetDesktopFolderfunction address stays the same (for each wine process, not windows process), and the start of the function address stays the same (000000007B01) regardless ofwine-tkg-stagingversion - so always.The text was updated successfully, but these errors were encountered: