Wine not working after update
wine --version 53 ✘
wine-10.9
winecfg ✔
002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc0daff
wine: could not load kernel32.dll, status c0000135
rm -rf ~/.wine does not help
Works here but i had these errors at first startup :
00d4:err:hid:udev_bus_init UDEV monitor creation failed
0148:err:environ:init_peb starting L"C:\\windows\\syswow64\\rundll32.exe" in experimental wow64 mode
0150:err:environ:init_peb starting L"C:\\windows\\syswow64\\iexplore.exe" in experimental wow64 mode
Wine update broke the update process the first time, i could not boot back to Manjaro and i had to restore the previous save point with timeshift and update from another mirror.
Seems there is issues with the last wine update…
All my wine apps are dead…
With my old ~./wine directory, winecfg throw:
wine: '/home/h2/.wine' is a 32-bit installation, it cannot support 64-bit applications.
When I rename ~./wine as ~./wine.old, winecfg create à new ~./wine directory and throw:
002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc0daff
wine: could not load kernel32.dll, status c0000135
I have the same error message when I try to reinstall one of my Windows apps. What can I do?
Edit: I have temporarily downgraded wine to 10.7.1 with:
yay -S downgrade
sudo downgrade wine
(https://www.reddit.com/r/archlinux/comments/1leronq/wine_kernel32dll_status_c0000135_is_not_working/)
Posts moved into a dedicated topic, hopefully this will result in more specific attention to the issue. 
Transition to the new WoW64 wine and wine-staging
2025-06-16
We are transitioning the wine and wine-staging package to a pure wow64 build. This change removes the dependency on the multilib repository for wine and wine-staging.
The main reason for this is to align with upstream Wine development, which simplifies packaging and the dependency chain.
Potential Issues:
- OpenGL Performance: A known limitation of the new WoW64 mode is reduced performance for 32-bit applications that use OpenGL directly
- Breaking Changes: Existing 32-bit prefixes needs to be recreated
If you are facing issues with 32 bit prefixes, please recreate these and reinstall the application.
… can’t replicate 
wine --version
wine-10.9
winecfg
wine: created the configuration directory '/home/jo/.wine'
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
004c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0054:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0054:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0054:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0054:err:ole:apartment_get_local_server_stream Failed: 0x80004002
004c:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
004c:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
004c:err:ole:apartment_get_local_server_stream Failed: 0x80004002
004c:err:ole:start_rpcss Failed to open RpcSs service
0094:fixme:file:NtLockFile I/O completion on lock not implemented yet
0094:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
009c:err:environ:init_peb starting L"Z:\\usr\\share\\wine\\mono\\wine-mono-10.0.0\\support\\removeuserinstalls-x86.exe" in experimental wow64 mode
00a4:err:environ:init_peb starting L"Z:\\usr\\share\\wine\\mono\\wine-mono-10.0.0\\support\\installinf-x86.exe" in experimental wow64 mode
0094:fixme:msi:internal_ui_handler internal UI not implemented for message 0x0b000000 (UI level = 1)
0094:fixme:msi:internal_ui_handler internal UI not implemented for message 0x0b000000 (UI level = 1)
00fc:err:environ:init_peb starting L"C:\\windows\\syswow64\\rundll32.exe" in experimental wow64 mode
00fc:fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet
0104:err:environ:init_peb starting L"C:\\windows\\syswow64\\iexplore.exe" in experimental wow64 mode
002c:err:setupapi:do_file_copyW Unsupported style(s) 0x10
002c:err:setupapi:do_file_copyW Unsupported style(s) 0x10
0128:err:setupapi:do_file_copyW Unsupported style(s) 0x10
002c:err:setupapi:do_file_copyW Unsupported style(s) 0x10
0128:err:setupapi:do_file_copyW Unsupported style(s) 0x10
I do have wine-mono and wine-gecko installed
and for the app below also vb6run via:
winetricks vb6run
Freshly installing an app (MyPhoneExplorer) into it’s own dedicated WINEPREFIX
(not into ~/.wine)
also works.
My previous post (about wine 10.9-1), on wincfg throwing (after renaming ~./wine as ~./wine.old):
002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc0daff
wine: could not load kernel32.dll, status c0000135
was about my KDE box where inxi --cpu returns:
CPU:
Info: dual core model: Pentium E5800 bits: 64 type: MCP cache: L2: 2 MiB
Speed (MHz): avg: 1203 min/max: 1203/3203 cores: 1: 1203 2: 1203
But on my more recent xfce box, where inxi --cpu returns:
CPU:
Info: dual core model: Intel Core i3-4000M bits: 64 type: MT MCP cache:
L2: 512 KiB
Speed (MHz): avg: 2400 min/max: 800/2400 cores: 1: 2400 2: 2400 3: 2400
4: 2400
winecfg works great as all my Windows apps…
I think it could be related, because a few months ago I had to freeze spotify on an old version because the processor of my KDE box was too old…
Maybe you have not really removed the old default wine prefix?
You keep writing ~./wine
but the directory name is .wine and it is located at:
~/.wine
ls -l ~/.wine
will probably still show it
rm -rf ~/.wine
will remove it
ls -l ~/.wine
will not show it anymore
No, .wine is the name of the folder, and it is located in the home folder of the user whose name is ~. So, the full path to the .wine folder is ~/.wine.
(I said to and not of)
Well, that is exactly what I said.
Anyway:
did you check that you actually removed the folder - using the sequence of the three commands in my previous post?
The last one should come up with a response like this:
ls -l ~/.wine
ls: cannot access '/home/h2/.wine': No such file or directory
Then, running winecfg will recreate the directory.
… and after that, you still get the same error?
Of course, any file manager will let you do this as well
~/.wine
is a “hidden” directory …
You could check the type of prefix you currently have:
grep '#arch' ~/.wine/user.reg
and/or
grep '#arch' ~/.wine/system.reg
Both should return:
#arch=win64
There seems some apparent confusion in terms.
A WINEprefix is comprised of directories; such as one might expect to find in disk C:\ of a Windows installation. That complete heirarchy is called a WINEprefix.
The .wine directory is the default wineprefix for your user, although other locations are possible;
For example, /usr/share/wineprefixes/... can potentially be accessible by all users of your system, rather than just you. In fact, a wineprefix can be created virtually anywhere you like, though, that would require manual configuration.
The ~/ indicates the profile directory of the current user (much like a shortcut); the variable can be used instead of using a full path like /home/armag67/.
The full path to your WINEprefix would become either ~/.wine or /home/armag67/.wine.
I hope this was useful.
Regards.
See Transition to the new WoW64 wine and wine-staging;
I’d suggest creating new 64-bit prefixes, which should ideally support your 32-bit applications via WOW64.
After renaming the ~/.wine directory to another name:
[h2@h2-imedias1800 ~]$ ls -l ~/.wine
ls: impossible d'accéder à '/home/h2/.wine': Aucun fichier ou dossier de ce nom
After upgrading wine:
[h2@h2-imedias1800 ~]$ winecfg
wine: created the configuration directory '/home/h2/.wine'
002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6fffffc0daff
wine: could not load kernel32.dll, status c0000135
[h2@h2-imedias1800 ~]$ grep '#arch' ~/.wine/system.reg
#arch=win64
[h2@h2-imedias1800 ~]$ grep '#arch' ~/.wine/user.reg
#arch=win64
Please prefix your commands with LC_ALL=C to have the command output in English.
You say that you renamed the wineprefix ~/.wine to something else, yet you still asked for a directory of ls ~/.wine…
Do you not see the problem with that?
I know this is absurd, but it was meant to show that I hadn’t messed up the .wine path.
You can see that winecfg creates a new .wine folder and then crashes.
So the problem isn’t a 32/64-bit inconsistency.
Well, I just installed WINE 10.9 to a VM and created a fresh 64-bit wineprefix. I launched winecfg in the same command and winecfg launched without issue.
It asked permission to install mono, which I granted;
WINEARCH=win64 WINEPREFIX=~/.wine winecfg
I launched the 32-bit mp3tag installer for Windows, and apart from some theming inconsistencies, it ran without issue.
Whatever the problem is, it doesn’t seem to be WINE, but perhaps something that interacts with WINE in some way; but this is only conjecture.
Please create another user account on your computer for testing, create a wineprefix there, and report back whether or not it was successful. If it succeeds in the new account, then the issue is likely limited to your main account.
Try running the command under Wayland, as well, if it still fails in X11. Let us know the results.
Regards.
Just an afterthought;
Depending on the system, sometimes winecfg can take a while to complete, and errors in the terminal are common.
Are you certain you allowed enough time?
Yes.
I think that the culprit is my to old proc and that 32-bit applications support via WOW64 needs a more recent processor that mine. Waiting the next update and see…
Yes, maybe.
However, try creating a test account to make sure; the problem might only be limited to your current account; and if that’s true, then no amount of waiting for an update will be of much use.
Regards.
Hard to test for anyone but you.
If that’s indeed the case then the pretty much only way to keep using Windows apps through wine is to use something like Bottles, where you can use specific (and older) wine versions for each prefix/each program and are not dependent on the system wide installed wine - which will always keep changing.
Seems there is an AUR package which might fix the issues on 32bit apps. However it might take 3 hours to build: AUR (en) - wine32
For what it’s worth, I’m still not experiencing any problems with 32-bit applications on WINE 10.9, on the local machine.
Also created a VM with a fresh install + WINE 10.9.
Again, no issues.