https://bugs.winehq.org/show_bug.cgi?id=51086
Bug ID: 51086 Summary: Could not load kernel32.dll Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: johnallanlambert1@gmail.com Distribution: ---
I can't open any wine or wine-related program, and when I type winecfg in terminal I get the following error: wine: could not load kernel32.dll, status c0000135
I have tried deleting the ~/.wine folder, reinstalling wine, and changing between 32-bit and 64-bit wine prefixes.
This bug completely prevents me from using wine at all.
Wine version: 6.7 Linux distribution: Manjaro KDE Everything on my system is up to date.
https://bugs.winehq.org/show_bug.cgi?id=51086
ASOwnerYT johnallanlambert1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |6.7 Distribution|--- |ArchLinux
--- Comment #1 from ASOwnerYT johnallanlambert1@gmail.com --- Also it looks like someone on the forum is experiencing a similar issue, which is why I think it's a bug with the Wine software.
https://bugs.winehq.org/show_bug.cgi?id=51086
Jared Johnstone jared@johnstone.net.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jared@johnstone.net.au
--- Comment #2 from Jared Johnstone jared@johnstone.net.au --- I also got "wine: could not load kernel32.dll, status c0000135" tonight in a new prefix on wine-6.7 (Staging) however it seems the issue went away when I recreated the directory and it seemed to populate it correctly the second time, solved it for me on Archlinux with kernel 5.11.16.
My existing default prefix continued to work but this one wouldn't until I re-created the directory.
Not entirely sure what caused this and why re-creating was enough.
https://bugs.winehq.org/show_bug.cgi?id=51086
Max qbodtecy@laste.ml changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |qbodtecy@laste.ml
--- Comment #3 from Max qbodtecy@laste.ml --- I'm seeing the same error on an up to date Arch Linux with kernel 5.12.1 and 6.8 wine-staging.
win32 prefixes are generated and working correctly, win64 prefixes fail with the error above. It also seems like existing win64 prefixes broke during update as I can't seem to launch any 64-bit applications.
https://bugs.winehq.org/show_bug.cgi?id=51086
Giacomo Orlandi gia_@inwind.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gia_@inwind.it
--- Comment #4 from Giacomo Orlandi gia_@inwind.it --- I think I'm also affected by this issue. It might be a different bug, as I *think* it only started with wine 6.8 And the error message is slightly different: `wine: failed to load start.exe: c0000135` instead of `wine: could not load kernel32.dll, status c0000135`
Please let me know if I should create a new bug
I'm on Ubuntu 20.04.
### Vanilla Wine
`rm -rf ~/.wine && WINEARCH=win32 /opt/wine-devel/bin/wine notepad.exe` Failed with: `wine: failed to load start.exe: c0000135`
`rm -rf ~/.wine && WINEARCH=win64 /opt/wine-devel/bin/wine notepad.exe` Failed with: `wine: failed to load start.exe: c0000135`
`rm -rf ~/.wine && WINEARCH=win64 /opt/wine-devel/bin/wine64 notepad.exe` Works!
### Wine Staging
`rm -rf ~/.wine && WINEARCH=win32 /opt/wine-staging/bin/wine notepad.exe` Works!
`rm -rf ~/.wine && WINEARCH=win64 /opt/wine-staging/bin/wine notepad.exe` Works!
rm -rf ~/.wine && WINEARCH=win64 /opt/wine-staging/bin/wine64 notepad.exe works Works!
Battlenet on an existing prefix, probably created on wine-staging 6.5: `WINEPREFIX=~/'games/BattleNet-wine' WINARCH=win64 /opt/wine-staging/bin/wine64 ~/'games/BattleNet-wine/drive_c/Program Files (x86)/Battle.net/Battle.net Launcher.exe'` Works!
However (by mistake) I started Battlenet on that same prefix, using vanilla Wine64: `WINEPREFIX=~/'games/BattleNet-wine' WINARCH=win64 /opt/wine-devel/bin/wine64 ~/'games/BattleNet-wine/drive_c/Program Files (x86)/Battle.net/Battle.net Launcher.exe'` Works!
`WINEPREFIX=~/'games/BattleNet-wine' WINARCH=win64 /opt/wine-devel/bin/winecfg` Failed with: `wine: failed to load start.exe: c0000135`
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #5 from Giacomo Orlandi gia_@inwind.it --- Update: I just found out that I can start notepad.exe on a 32 bit prefix by specifying the full path.
So this works: rm -rf ~/.wine && WINEARCH=win32 /opt/wine-devel/bin/wine ~/.wine/drive_c/windows/notepad.exe
And this fails: rm -rf ~/.wine && WINEARCH=win32 /opt/wine-devel/bin/wine notepad.exe ... wine: failed to load start.exe: c0000135
I haven't found a way to run winecfg successfully on a win32 prefix, on vanilla Wine: rm -rf ~/.wine && WINEARCH=win32 /opt/wine-devel/bin/winecfg ... wine: failed to load start.exe: c0000135
Would it help if I run a regression test? (I've never tried) Or do the Wine developers already fully understand this issue, and they just need to find the time to fix it?
https://bugs.winehq.org/show_bug.cgi?id=51086
Markus Ueberall ueberall@projektzentrisch.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ueberall@projektzentrisch.d | |e
https://bugs.winehq.org/show_bug.cgi?id=51086
matt gardotd426@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gardotd426@gmail.com
--- Comment #6 from matt gardotd426@gmail.com --- I can confirm this is a bug. New wineprefixes cannot be created with 6.8 staging. Tested on Arch Linux. The "Wine prefix at /path/to/prefix is being updated" window just hangs, and when you try again it gives the kernel32.dll error.
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #7 from matt gardotd426@gmail.com --- I will also add that old prefixes created with 6.6 or so will work when being updated to 6.8. The updating window still hangs, but you can kill the process, launch again, and everything works. So something is wrong with 6.7 or 6.8 to where updating prefixes never completes and creating new (64-bit) prefixes fails.
I've bisected a bug in the kernel before, but never wine, but if you guys need help bisecting I can give it a shot. I am familiar with building wine from source so that shouldn't be an issue
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #8 from Max qbodtecy@laste.ml --- Still very much a problem with the just released wine-staging 6.9. Although now I'm not convinced that it's (entirely) wines fault.
I've downgraded step by step all the way to wine-staging 6.2 and still can't successfully create a win64 prefix. So, the versions affected would be 6.2 through 6.9, which is quite curious, as I don't remember them being broken. Seeing as every reporter is on Arch or derivatives I'd guess that some update to another component is at fault.
Interestingly versions 6.2 through 6.5 do create a prefix, but only after the following error: 0024:err:environ:run_wineboot boot event wait timed out Unfortunately those are useless, as syswow64 is entirely empty.
This wineboot timeout seems to be the only common error between all versions, as only newer ones show c0000135 afterwards.
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #9 from matt gardotd426@gmail.com --- Yeah, definitely still an issue. Proton builds using wine 6.9 are failing to create wineprefixes. The process will stall, then the kernel32.dll error shows up, and a partial wineprefix gets built, but it's only 100MB instead of 700MB like it should be, and it doesn't run anything.
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #10 from Max qbodtecy@laste.ml --- It appears that my speculation above was correct.
While trying to work around the issue I've stumbled upon this: https://github.com/Frogging-Family/wine-tkg-git/issues/396
I can confirm that uninstalling gst-editing-services solves the issue on my end.
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #11 from matt gardotd426@gmail.com --- It's kind of not good that gst-editing-services is conflicting with wine/proton, considering the fact that GNOME is probably the most popular desktop environment of all.
https://bugs.winehq.org/show_bug.cgi?id=51086
Jared Johnstone jared@johnstone.net.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|jared@johnstone.net.au |
https://bugs.winehq.org/show_bug.cgi?id=51086
Alexander Vereeken Alexander88207@Protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Alexander88207@Protonmail.c | |om
--- Comment #12 from Alexander Vereeken Alexander88207@Protonmail.com --- I can confirm this problem also on FreeBSD 13 amd64 while i386 builds works fine.
https://bugs.winehq.org/show_bug.cgi?id=51086
Daniel Menelkir menelkir@itroll.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |menelkir@itroll.org
--- Comment #13 from Daniel Menelkir menelkir@itroll.org --- I'm using FreeBSD 13. 32bit wine works as expected but 64bit have this issue. I've tried different env variables to test (even a clean environment (jail)) and all of them ended in this error at some point.
https://bugs.winehq.org/show_bug.cgi?id=51086
Alex S iwtcex@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iwtcex@gmail.com
--- Comment #14 from Alex S iwtcex@gmail.com --- We actually have https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255336 for the FreeBSD issue, which I believe has something to do with https://github.com/wine-staging/wine-staging/blob/534f6ae34e89615fa424ee3e30....
https://bugs.winehq.org/show_bug.cgi?id=51086
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|kernel32 |-unknown CC| |z.figura12@gmail.com Status|UNCONFIRMED |RESOLVED Summary|Could not load kernel32.dll |winegstreamer hangs in | |gst_init_check() while | |registering libgstges.so | |(GStreamer Editing Services | |plugin) Resolution|--- |NOTOURBUG
--- Comment #15 from Zebediah Figura z.figura12@gmail.com --- This is a GStreamer bug; the plugin is hanging in its registration function.
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #16 from Alex S iwtcex@gmail.com --- (In reply to Zebediah Figura from comment #15)
This is a GStreamer bug; the plugin is hanging in its registration function.
Are you entirely sure? How exactly anything hanging could lead to the "could not load kernel32.dll" error message? Why would winecfg load gstreamer in the first place? (And as far FreeBSD's Wine is concerned, it's typically built without gstreamer support.)
Now, it's almost certain there is some kind of mixup, but in my opinion the actual bug report message should take priority over everything else.
https://bugs.winehq.org/show_bug.cgi?id=51086
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|winegstreamer hangs in |winegstreamer hangs in |gst_init_check() while |gst_init_check() while |registering libgstges.so |registering libgstges.so |(GStreamer Editing Services |(GStreamer Editing Services |plugin) |plugin); may manifest as | |hang during prefix creation | |and subsequent failure to | |load applications with | |"wine: could not load | |kernel32.dll, status | |c0000135"
--- Comment #17 from Zebediah Figura z.figura12@gmail.com --- (In reply to Alex S from comment #16)
(In reply to Zebediah Figura from comment #15)
This is a GStreamer bug; the plugin is hanging in its registration function.
Are you entirely sure? How exactly anything hanging could lead to the "could not load kernel32.dll" error message? Why would winecfg load gstreamer in the first place? (And as far FreeBSD's Wine is concerned, it's typically built without gstreamer support.)
Now, it's almost certain there is some kind of mixup, but in my opinion the actual bug report message should take priority over everything else.
When wineboot creates the prefix, it does several tasks, and one is registering a set of builtin DLLs. That includes winegstreamer. winegstreamer loads libgstreamer on load, which does a scan for plugins and attempts to register them all into the local cache.
Another task wineboot does is to copy system DLLs into the prefix. If a DLL isn't present in the prefix, it can't be subsequently loaded, and will return STATUS_DLL_NOT_FOUND (i.e. c0000135). That includes kernel32.
Granted, wine could be more robust at one or more of these steps. We could include a timeout when registering builtin DLLs. We don't actually need to load libgstreamer when registering it (and probably shouldn't anyway). But at the same time, this bug is going to happen whenever someone tries to load libgstreamer, so it's not like the bug report is actually going to go away. It's a sticky situation.
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #18 from Alex S iwtcex@gmail.com --- (In reply to Zebediah Figura from comment #17)
Fair enough.
https://bugs.winehq.org/show_bug.cgi?id=51086
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |b1779506@trbvn.com
--- Comment #19 from Zebediah Figura z.figura12@gmail.com --- *** Bug 51428 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=51086
Mauro mombelli.mauro@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mombelli.mauro@gmail.com
--- Comment #20 from Mauro mombelli.mauro@gmail.com --- *** Bug 51516 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=51086
Nirbheek Chauhan nirbheek.chauhan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nirbheek.chauhan@gmail.com
--- Comment #21 from Nirbheek Chauhan nirbheek.chauhan@gmail.com --- Hi! I'm a gstreamer developer, and I can't seem to find a stack trace anywhere for this. Difficult for us to figure out what the issue is without that. Could someone post that please?
Ideally we'd discuss this in an issue in the freedesktop gitlab [https://gitlab.freedesktop.org/gstreamer/gstreamer], but we can do that once we've verified that it is indeed something that gstreamer is doing wrong.
https://bugs.winehq.org/show_bug.cgi?id=51086
--- Comment #22 from Zebediah Figura z.figura12@gmail.com --- (In reply to Nirbheek Chauhan from comment #21)
Hi! I'm a gstreamer developer, and I can't seem to find a stack trace anywhere for this. Difficult for us to figure out what the issue is without that. Could someone post that please?
Ideally we'd discuss this in an issue in the freedesktop gitlab [https://gitlab.freedesktop.org/gstreamer/gstreamer], but we can do that once we've verified that it is indeed something that gstreamer is doing wrong.
https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/121 might be the relevant GStreamer bug, but I don't know. I haven't been able to reproduce it yet myself; I've only gathered this information from a GST_DEBUG=6 log, where I see registration get lost somewhere in libgstges. Unfortunately I probably lost the log as well.
https://bugs.winehq.org/show_bug.cgi?id=51086
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |igo95862@yandex.ru
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- *** Bug 51621 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=51086
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imre.steiner@oneidentity.co | |m
--- Comment #24 from Alexandre Julliard julliard@winehq.org --- *** Bug 52498 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=51086
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|qbodtecy@laste.ml |
https://bugs.winehq.org/show_bug.cgi?id=51086
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com