[Bug 51086] New: Could not load kernel32.dll
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(a)winehq.org Reporter: johnallanlambert1(a)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. -- 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=51086 ASOwnerYT <johnallanlambert1(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |6.7 Distribution|--- |ArchLinux --- Comment #1 from ASOwnerYT <johnallanlambert1(a)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. -- 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=51086 Jared Johnstone <jared(a)johnstone.net.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jared(a)johnstone.net.au --- Comment #2 from Jared Johnstone <jared(a)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. -- 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=51086 Max <qbodtecy(a)laste.ml> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qbodtecy(a)laste.ml --- Comment #3 from Max <qbodtecy(a)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. -- 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=51086 Giacomo Orlandi <gia_(a)inwind.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gia_(a)inwind.it --- Comment #4 from Giacomo Orlandi <gia_(a)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` -- 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=51086 --- Comment #5 from Giacomo Orlandi <gia_(a)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? -- 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=51086 Markus Ueberall <ueberall(a)projektzentrisch.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ueberall(a)projektzentrisch.d | |e -- 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=51086 matt <gardotd426(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gardotd426(a)gmail.com --- Comment #6 from matt <gardotd426(a)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. -- 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=51086 --- Comment #7 from matt <gardotd426(a)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 -- 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=51086 --- Comment #8 from Max <qbodtecy(a)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. -- 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=51086 --- Comment #9 from matt <gardotd426(a)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. -- 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=51086 --- Comment #10 from Max <qbodtecy(a)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. -- 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=51086 --- Comment #11 from matt <gardotd426(a)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. -- 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=51086 Jared Johnstone <jared(a)johnstone.net.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|jared(a)johnstone.net.au | -- 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=51086 Alexander Vereeken <Alexander88207(a)Protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Alexander88207(a)Protonmail.c | |om --- Comment #12 from Alexander Vereeken <Alexander88207(a)Protonmail.com> --- I can confirm this problem also on FreeBSD 13 amd64 while i386 builds works fine. -- 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=51086 Daniel Menelkir <menelkir(a)itroll.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |menelkir(a)itroll.org --- Comment #13 from Daniel Menelkir <menelkir(a)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. -- 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=51086 Alex S <iwtcex(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |iwtcex(a)gmail.com --- Comment #14 from Alex S <iwtcex(a)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.... -- 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=51086 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|kernel32 |-unknown CC| |z.figura12(a)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(a)gmail.com> --- This is a GStreamer bug; the plugin is hanging in its registration function. -- 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=51086 --- Comment #16 from Alex S <iwtcex(a)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. -- 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=51086 Zebediah Figura <z.figura12(a)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(a)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. -- 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=51086 --- Comment #18 from Alex S <iwtcex(a)gmail.com> --- (In reply to Zebediah Figura from comment #17) Fair enough. -- 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=51086 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |b1779506(a)trbvn.com --- Comment #19 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 51428 has been marked as a duplicate of this bug. *** -- 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=51086 Mauro <mombelli.mauro(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mombelli.mauro(a)gmail.com --- Comment #20 from Mauro <mombelli.mauro(a)gmail.com> --- *** Bug 51516 has been marked as a duplicate of this bug. *** -- 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=51086 Nirbheek Chauhan <nirbheek.chauhan(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nirbheek.chauhan(a)gmail.com --- Comment #21 from Nirbheek Chauhan <nirbheek.chauhan(a)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. -- 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=51086 --- Comment #22 from Zebediah Figura <z.figura12(a)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. -- 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=51086 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |igo95862(a)yandex.ru --- Comment #23 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 51621 has been marked as a duplicate of this bug. *** -- 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=51086 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imre.steiner(a)oneidentity.co | |m --- Comment #24 from Alexandre Julliard <julliard(a)winehq.org> --- *** Bug 52498 has been marked as a duplicate of this bug. *** -- 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=51086 Jeff Zaroyko <jeffz(a)jeffz.name> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|qbodtecy(a)laste.ml | -- 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=51086 Robert Walker <bob.mt.wya(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya(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=51086 Giacomo Orlandi <gia_@inwind.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|gia_@inwind.it | -- 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