Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#68771 - [wine] latest version hangs when running anything

Attached to Project: Community Packages
Opened by Jeremy Brown (brownjava) - Saturday, 28 November 2020, 13:27 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 28 November 2020, 15:20 GMT
Task Type Bug Report
Category Packages: Multilib
Status Assigned
Assigned To Felix Yan (felixonmars)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No


The latest binary package of Wine (5.22-1) doesn't seem to work correctly on my machine. If I attempt to run any executable, it hangs forever. Even winecfg does this:

jeremy@fourroses ~> winecfg
wine: created the configuration directory '/home/jeremy/.wine'
0048:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0048:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0048:err:ole:apartment_get_local_server_stream Failed: 0x80004002

I've tried blasting away the contents of my `~/.wine` directory and starting from scratch, but no dice.

If I build wine manually from source, it works fine. Additionally rebuilding the PKGBUILD generates a version of wine that works. So I think the binary package might just be built bad.

This has been reported on the forums as well:
This task depends upon

Comment by Emil (xexaxo) - Saturday, 28 November 2020, 17:04 GMT
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
Comment by Jeremy Brown (brownjava) - Saturday, 28 November 2020, 20:40 GMT
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`.
Comment by Emil (xexaxo) - Monday, 30 November 2020, 11:34 GMT
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.
Comment by Paul (grochu112) - Sunday, 13 December 2020, 01:04 GMT
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
Comment by Paul (grochu112) - Tuesday, 05 January 2021, 02:06 GMT
Using git dissection, I was able to establish the first faulty commit:

145cfce1135a7e59cc4c89cd05b572403f188161 is the first bad commit
commit 145cfce1135a7e59cc4c89cd05b572403f188161
Author: Zhiyi Zhang <>
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 <>
Signed-off-by: Liam Middlebrook <>
Signed-off-by: Alexandre Julliard <>

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(-)
Comment by Emil (xexaxo) - Wednesday, 06 January 2021, 11:42 GMT
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.
Comment by Spout (sutupud) - Wednesday, 06 January 2021, 17:11 GMT
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...
Comment by Emil (xexaxo) - Wednesday, 06 January 2021, 17:24 GMT
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.
Comment by Spout (sutupud) - Wednesday, 06 January 2021, 17:29 GMT
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.
Comment by Paul (grochu112) - Wednesday, 06 January 2021, 20:00 GMT
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?
Comment by Emil (xexaxo) - Thursday, 07 January 2021, 13:08 GMT
@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
Comment by Paul (grochu112) - Saturday, 09 January 2021, 13:59 GMT
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.
Comment by Felix Yan (felixonmars) - Saturday, 09 January 2021, 14:39 GMT
This is weird. It at least works correctly here with X-Server and Intel GPU.
Comment by Amin Vakil (aminvakil) - Saturday, 09 January 2021, 14:43 GMT
It works on latest KDE (plasmashell 5.20.5) and Intel GPU on Xorg too.
Comment by Paul (grochu112) - Sunday, 10 January 2021, 21:26 GMT
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.
   wine.log (43.4 KiB)
Comment by Emil (xexaxo) - Monday, 11 January 2021, 14:20 GMT
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.
Comment by Felix Yan (felixonmars) - Wednesday, 27 January 2021, 09:28 GMT
Someone told me this upstream bug is related:

Please try the VK_ICD_FILENAMES workaround in and see if it fixes anything for you.
Comment by Andrew Rembrandt (drew33) - Thursday, 28 January 2021, 12:23 GMT
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)
Comment by Emil (xexaxo) - Thursday, 18 February 2021, 18:10 GMT
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?
Comment by Emil (xexaxo) - Tuesday, 23 February 2021, 19:16 GMT
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.
Comment by Michael (ZeroBeat) - Monday, 24 May 2021, 09:28 GMT
@ 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.
Comment by Michael (ZeroBeat) - Wednesday, 02 June 2021, 08:44 GMT