Arch Linux

Seems very unlikely to be "built bad". Nevertheless you can compare the .BUILDINFO (it's in the tarball) of your build vs the official.

The forum thread seems all over the place - for OP downgrading wine did not help. Does it work in your case, which version?

Looking at the pacman logs - the issue could be also related to nvidia, xorg or kernel (or a mix of all four). My money goes that it's nvidia related (regardless of package) - each of my Intel and AMD (single GPU each) work fine.

Aside: you do _not_ need to "blast away" your ~/.wine - `WINEPREFIX=~/.wine-test winecfg` works just fine

I compared my .BUILDINFO with the official package, and they are identical.

Just tried downgrading to 1.51-1 (presumably what I was using before, since it was in my package cache), and that version does indeed work for me. Doing `pacman -Syu` to get back to the latest, now it appears to work, but it looks like it did upgrade some other packages as well, including `xf86-video-intel`.

As the gfx driver developer in me expected - driver related ;-)

For the sake of fellow forum members you can walk through /var/log/pacman.log and confirm which exact package caused this.
But as-is, I think this can be closed.

Exactly the same issue affected my setup.

Unfortunately at this point I'm unable to determine what was the exact package update configuration that introduced the problem.

However I've walked back the A.L.A. for wine package.
As a result I've established that the last version functional with my current setup is "wine-5.10-1".

It is also worth to mention that I tried compiling wine-5.22 by myself.
It changed nothing.

---
Setup specs:

Optimus with:
- NVIDIA GeForce GTX 1050 Ti
- Intel UHD Graphics 630

GPU drivers:
- bumblebee
- nvidia
- xf86-video-intel

Desktop env:
- X-Server (NOT Wayland)
- KDE Plasma 5

Using git dissection, I was able to establish the first faulty commit:

145cfce1135a7e59cc4c89cd05b572403f188161 is the first bad commit
commit 145cfce1135a7e59cc4c89cd05b572403f188161
Author: Zhiyi Zhang <zzhang@codeweavers.com>
Date: Wed Jun 17 20:02:04 2020 +0800

winex11.drv: Add a Vulkan UUID property for GPUs.

A Vulkan UUID property is used to find the corresponding GPU in SetupAPI.

Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Liam Middlebrook <lmiddlebrook@nvidia.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>

dlls/winex11.drv/display.c | 15 +++++--
dlls/winex11.drv/x11drv.h | 2 +
dlls/winex11.drv/xrandr.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 113 insertions(+), 3 deletions(-)

This commit landed in wine 5.11, so the bug report against 5.22 seems odd.
Perhaps wine was updated alongside mesa, the latter of which shipping MESA_device_select layer?

An easy way to test is $ NODEVICE_SELECT=1 winecfg
If that works, I'd suggest reporting a bug against Mesa.

I also had problems with wine 5.22 not starting various applications, but they were resolved and worked fine again from 6.0rc1 up to the current 6.0rc5.
So I would try with the latest version, it seems that 5.22 was buggy.

I don't know why the newer versions are not available in the repos. Maybe because the're called 'rc'? But with wine's relese scheme that means they are only rc in regard to the next 6.0 (stable) version, and should actually be more stable than any of the 5.1+ versions, since the codebase is in bugfix only mode and no new featueres are allowed, contrary to all the other releases...

RC stands for Release Candidate - aka beta, which Arch does not (usually) package.

Aside: mentioning "problems" and "not starting various programs" is far too vague to be useful - sorry.

Well, then it should not really package any of the non .0 versions, as they are all kind of beta, while the .0 series is stable.
Other distros package the .0 series separately as stable and the others as dev. Anyway, I remember there being wine rc versions in the past in the repos.

Before dissecting I have compiled and tested 6.0-rc5.
The problem was still there. (!)

I have also tried switching to Wayland.
The problem does not occur there.
However I prefer X-Server.
(KDE on Wayland is "quite not there" yet.)

Also I agree that the cause of problem might be actually X11/Mesa. (!)
Since Proton stopped working for me at the same time as Wine did.
(However besides Wine and Proton I haven't encounter any other issues with X-Server.)

Maybe X11/Mesa bug should be reported instead?

@grochu112 does NODEVICE_SELECT=1 (aka NODEVICE_SELECT=1 winecfg) make any difference?

I've noticed that you're using bumblebee - to scope a little better I would suggest:
- try with bumblebee removed (you can reinstate it later)
- which bumblebee backend are you using primus or virtualgl
- are you having the issue when running wine on the intel, nvidia gpu or both - winecfg (for the former) vs optirun/primusrun winecfg (for the latter)
- you're having primus_vk please include a permutation of the above w/ and w/o it

Using NODEVICE_SELECT=1 winecfg made no difference.
Same goes for uninstalling bumblebee.
(Including killing daemon, but just to to be sure I rebooted whole machine.)

The issue occurs on:
- X-Server + Intel GPU (either with or without bumblebee; $ winecfg)
- X-Server + Nvidia GPU ($ optirun -b virtualgl winecfg)
- X-Server + Nvidia GPU ($ optirun -b primus winecfg)
- X-Server + Nvidia GPU ($ optirun -b none winecfg)

The issue does not occur:
- Wayland + Intel GPU (only tested with bumblebee; $ winecfg)
- Wayland + Nvidia GPU ($ optirun -b virtualgl winecfg)
- Wayland + Nvidia GPU ($ optirun -b primus winecfg)
- Wayland + Nvidia GPU ($ optirun -b none winecfg)

In every case tested with KDE desktop.

From my point of view, it is starting to look more and more like a X-Server issue.

This is weird. It at least works correctly here with X-Server and Intel GPU.

It works on latest KDE (plasmashell 5.20.5) and Intel GPU on Xorg too.

I had run wine with some extra debug flags. (WINEDEBUG=warn+all winecfg)
Maybe someone more experienced will be able to notice something suspicious.
Attaching log from the launch.

The log does not say much I'm afraid.

With my GFX driver developer hat on - I would suggest something like the following:
- apply a wine patch like the attached - see exactly where we get stuck
- continue stripping bits - with bb/primus removed, proceed with
- remove with primus_vk and/or disable - DISABLE_PRIMUS_LAYER=1 winecfg
- disable nvidia vulkan implicit layer - DISABLE_LAYER_NV_OPTIMUS_1=1 winecfg
- remove the nvidia drivers
- still "stuck" - get an strace - strace -o wine-stuck winecfg

Aside you really do NOT want primus (GL or Vulkan one) with modern drivers. Bumblebee on its own is fine - to powers off the GPU when not in use.

Someone told me this upstream bug is related: https://bugs.winehq.org/show_bug.cgi?id=49764

Please try the VK_ICD_FILENAMES workaround in https://gitlab.freedesktop.org/mesa/mesa/-/issues/4112 and see if it fixes anything for you.

I can confirm the VK_ICD_FILENAMES workaround does work for me (NVIDIA Optimus laptop with Intel integrated graphics - wine-staging, wine, lutris etc now all work correctly) - up to date KDE Plasma XOrg intel modesetting driver (with optimus-manager)

The mentioned reports talk about a crash, while here we have a hang.
In either case - setting VK_ICD_FILENAMES is a workaround which you don't want in the long run. Have you tried my suggestion?

Having a closer look at the issue - the root is likely the same, despite the different symptoms.

Do you have mangoHUD or any other implicit Vulkan layers?
Or in other words: What files do you have in /usr/share/vulkan/implicit_layer.d/ and which packages provide them?

Edit: if my presumption above is correct, mesa 20.3.4-3 should have a workaround for this issue.

@ Paul (grochu112), I can confirm that the commit, you mentioned on "Tuesday, 05 January 2021, 02:06 GMT"
caused the trouble. The last working version for me is is wine 5.10.

Moved this issue to upstream:
https://bugs.winehq.org/show_bug.cgi?id=51210

Just for reference this is still an issue on Wine 7

The issue still exists on wine 7.0rc5-1 because there is no fix on upstream, yet.

0074:err:plugplay:enumerate_new_device Unable to install a function driver for device L"WINEBUS\\VID_845E&PID_0001\\0&0000&0&0".
0074:err:plugplay:enumerate_new_device Unable to install a function driver for device L"WINEBUS\\VID_845E&PID_0002\\0&0000&0&0".
wine: Unhandled page fault on execute access to 00007F6424EB45C0 at address 00007F6424EB45C0 (thread 0064), starting debugger...
00ac:err:module:import_dll Library win32u.dll (which is needed by L"C:\\windows\\system32\\gdi32.dll") not found
00ac:err:module:import_dll Library gdi32.dll (which is needed by L"C:\\windows\\system32\\user32.dll") not found
00ac:err:module:import_dll Library win32u.dll (which is needed by L"C:\\windows\\system32\\user32.dll") not found
00ac:err:module:DelayLoadFailureHook failed to delay load user32.dll.GetProcessWindowStation
wine: Call from 000000007B0123AE to unimplemented function user32.dll.GetProcessWindowStation, aborting
wine: Unhandled page fault on execute access to 00007FD7D55D45C0 at address 00007FD7D55D45C0 (thread 00c0), starting debugger...
wine: Unhandled page fault on execute access to 00007F932E065270 at address 00007F932E065270 (thread 00b8), starting debugger...
00c8:err:module:import_dll Library win32u.dll (which is needed by L"C:\\windows\\system32\\gdi32.dll") not found
00c8:err:module:import_dll Library gdi32.dll (which is needed by L"C:\\windows\\system32\\user32.dll") not found
00c8:err:module:import_dll Library win32u.dll (which is needed by L"C:\\windows\\system32\\user32.dll") not found
00c8:err:module:DelayLoadFailureHook failed to delay load user32.dll.GetProcessWindowStation
wine: Call from 000000007B0123AE to unimplemented function user32.dll.GetProcessWindowStation, aborting
00d0:err:module:import_dll Library win32u.dll (which is needed by L"C:\\windows\\system32\\gdi32.dll") not found
00d0:err:module:import_dll Library gdi32.dll (which is needed by L"C:\\windows\\system32\\user32.dll") not found
00a4:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
00a4:err:winediag:nodrv_CreateWindow The explorer process failed to start.
00d0:err:module:import_dll Library win32u.dll (which is needed by L"C:\\windows\\system32\\user32.dll") not found
00d0:err:module:DelayLoadFailureHook failed to delay load user32.dll.GetProcessWindowStation
wine: Call from 000000007B0123AE to unimplemented function user32.dll.GetProcessWindowStation, aborting
002c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
002c:err:winediag:nodrv_CreateWindow The explorer process failed to start.
00e4:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
00e4:err:winediag:nodrv_CreateWindow The explorer process failed to start.
00ec:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
00ec:err:winediag:nodrv_CreateWindow The explorer process failed to start.
011c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
011c:err:winediag:nodrv_CreateWindow The explorer process failed to start.
wine: configuration in L"/home/zerobeat/.wine" has been updated.
wine: Unhandled page fault on execute access to 00007F3F3AFCC5C0 at address 00007F3F3AFCC5C0 (thread 0134), starting debugger...

Looking back, there were various symptoms clumped into this issue.

Various rework was done with wine 8.0, which could have fixed this. It's possible that it's outstanding, in which case active user participation is required with upstream - their report is NEEDINFO for 1.5 years.

My personal inclination is we should close the Arch bug - Arch devs and Wine developers are two disjoint teams. The latter is better suited at fixing the issue.

I fully agree. We can close it here.