CrossOver not working

[PSzczepanski1996]

CPU: r5 3600
macOS version: 10.15.4
15h/16h or 17h: 17h
I am using and can reproduce on the latest patches: yes, using newest kexts from Acidanthera and OpenCore

Describe the bug
CrossOver is not working on Catalina, but I don't quite understand why, since OPEMU is deprecated in Catalina. From far what I know CrossOver is using com.apple.security.ldt-in-64bit-process function to work properly, according to this:
https://twitter.com/comex/status/1204919560010223618

Not sure if that's an bug, support request, and where bugfix should be implemented.

Screenshots

[PSzczepanski1996]

I tried to run Wine taskmgr, and it starts, but it's crashing after 2-3 seconds:

Maybe this is fixable and not releated to OPEMU and so on? Anybody want to help?

[dhinakg]

From that link:

Impressive achievement. They have a special entitlement com.apple.security.ldt-in-64bit-process letting them run 32-bit code

I am not a developer, so I'm not 100% sure on this, but 0 32-bit code works on AMD because of (missing) OPEMU, so this is why CrossOver does not work.

[PSzczepanski1996]

So I tried to run NosTale (old game which I was playing in the 2015) or use built-in wine that is located under CrossOver, with results like this:

Seems that wine64 and wineboot can't run. For interesing reason, when I use computer whole day the address in NosTale stack overflow error should change, and it's not, so I am interested in this value:
0x1007:0x7bcb125f

From that link:

Impressive achievement. They have a special entitlement com.apple.security.ldt-in-64bit-process letting them run 32-bit code

I am not a developer, so I'm not 100% sure on this, but 0 32-bit code works on AMD because of (missing) OPEMU, so this is why CrossOver does not work.

Yeah, but is com.apple.security.ldt-in-64bit-process releated to OPEMU, or it's something outside it? I could go deep into XNU kernel sources, but I'm somehow tired today. That's all info I collected.

EDIT: Disabling SIP does not help either.

[IOIIIO]

Impressive achievement. They have a special entitlement http://com.apple.security.ldt-in-64bit-process letting them run 32-bit code, but they still need to rely on 64-bit system libs.

You cannot run 32-bit code on AMD systems. It indeed has to do with OPEMU or rather the lack thereof.

[stefand]

Wine/CodeWeavers dev here. A guy on our IRC channel brought my attention to this bug. I am currently waiting for a compile to finish so I am dropping a few quick notes. I'm afraid I can't spend a lot of time though because we don't support hackintoshes.

For some technical detail see https://www.winehq.org/pipermail/wine-devel/2019-December/156602.html . The 32 bit execution magic works by creating 32 bit LDT entries via i386_set_ldt. That's what the special permission is needed for, although it seems 10.15.4 removed that requirement. The other way around the permission is to disable system integrity protection.

LDT entries aren't CPU specific (unlike HW Hypervisors, and the Apple hypervisor API that is very intel specific), so in theory this should work. If I understand the screenshots right and taskmgr is at least starting up, and if that cmd is running in 32 bit code, the important thing is working.

What is probably a problem is system calls and signal delivery to a process/thread that currently has %cs pointing to a 32 bit code segment. If you have some custom kernel modifications or modules that's the first place to look.

Try to build yourself a C program that builds as a 64 bit C program but calls 32 bit bytecode via a 32 bit code segment entry and see if you can get this working on AMD. It's somewhat tricky - beware address space, stack and data segments, return addresses, so first make sure your test program works on a proper mac.

[stefand]

Ah yes, the CrossOver 19 source code, or at least the Wine parts, are available at https://www.codeweavers.com/products/more-information/source. I believe the modifications we made to Clang to handle 32 bit pointer sizes in 64 bit environments are also in there. At very least I don't think we're deliberately keeping them secret, it's just a really messy piece of code. Upstream Wine doesn't want it as is, the plan there is to eventually work without a magic compiler.

[KenThomases]

Another Wine/CodeWeavers dev here. :)

CrossOver is still running 32-bit code directly on the CPU. It is not emulating or translating that code to 64-bit. If I understand the purpose of OPEMU correctly, it's for emulating certain Intel-only instructions that AMD CPUs don't support natively in 32-bit mode. So, IOIIIO is correct, the lack of OPEMU will prevent CrossOver from running 32-bit Windows programs. The fact that it ran some to a certain extent might simply be because they didn't attempt to execute one of the instructions that require emulation until relatively late in the run.

I would expect that the same would be true on Mojave and earlier using this project. So, it's not directly related to our 32-on-64-bit support.

The reason why OPEMU is deprecated with Catalina is because one is not expected to run any 32-bit code on Catalina, so it shouldn't be necessary. Well, surprise! It is necessary for CrossOver's 32-on-64-bit support because we are running 32-bit code.

[JoelNichols]

To add on to this, whilst OPEMU is deprecated with Catalina for the purpose of hackintoshing, it still genuinely may be useful for some 64-bit apps that require Intel-specific instructions to be present, i.e. Adobe, REAPER, etc.

[palxex]

Doubt that what crossover19 needs is OPEMU.

0. background information: https://wiki.osdev.org/SYSENTER
1. AMD CPU does not totally unable to run ANY 32bit code in previous kernel-patched macOS. Then why when opening wine/32bit app on kernels that without OPEMU, we got illegal instrument error? That's because AMD lacks sysenter/sysexit in 64-bit compatible mode, only the two instrument which commonly used for implementing syscall in 32bit OS, any other i386 instrument working natively, at least on zen2. To verify it, just install 10.13.6 with IOIIIO's guide, then compile Shaneee's High Sierra Kernel with this minimal OPEMU patch which I've commented all other instruments emulation besides sysenter/sysexit, you'll still get wine/32bit macOS app running, but if you comment opemu_sysenter call which emulates sysenter/sysexit , you'll get illegal instruments.
2. All OPEMU implementations( that I've seen 😄 ) modifies kernel_trap and user_trap, wait CPU throw invalid opcode exception and then handling it. Though no patched Catalina kernel found, but there is another way: dynamic hooking. There was a OpcodeEmulator, which is a Lilu plugin( so can be loaded on both 10.13 and 10.15), source code was found at available on GitHub. I've verified that it could work on High Sierra, make wine/32bit macOS app work with kernel opemu turnes off; BUT, it does not work on Catalina. After some modification, I successful making it works on Catalina (by modify max version), then I adds some logging, after that ( AND turn to FakeSMC since this plugin hooks kernel_trap which conflicts VirtualSMC ), the reason was finally found: when running wine32on64, no ANY invalid opcode exception even CATCHED ( but page fault exception often be watched, which tells that hooks working ) . That should means: 1. in Catalina, since no 32bit syscall exist, sysenter/sysexit was totally replaced by syscall/sysret, which already handles well on AMD CPU; 2. wine32on64 does not uses any other instrument that AMD not supported, or at least invalid opcode exception should be watched.

I think a conclusion can be deduced from all above: what blocks crossover19 from running on Catalina is NOT simply lacking of OPEMU. Though I also don't know what it actually IS, yet : )

[PSzczepanski1996]

Doubt that what crossover19 needs is OPEMU.

1. background information: https://wiki.osdev.org/SYSENTER
2. AMD CPU does not totally unable to run ANY 32bit code in previous kernel-patched macOS. Then why when opening wine/32bit app on kernels that without OPEMU, we got illegal instrument error? That's because AMD lacks sysenter/sysexit in 64-bit compatible mode, only the two instrument which commonly used for implementing syscall in 32bit OS, any other i386 instrument working natively, at least on zen2. To verify it, just install 10.13.6 with IOIIIO's guide, then compile Shaneee's High Sierra Kernel with this minimal OPEMU patch which I've commented all other instruments emulation besides sysenter/sysexit, you'll still get wine/32bit macOS app running, but if you comment opemu_sysenter call which emulates sysenter/sysexit , you'll get illegal instruments.
3. All OPEMU implementations( that I've seen smile ) modifies kernel_trap and user_trap, wait CPU throw invalid opcode exception and then handling it. Though no patched Catalina kernel found, but there is another way: dynamic hooking. There was a OpcodeEmulator, which is a Lilu plugin( so can be loaded on both 10.13 and 10.15), source code was found at available on GitHub. I've verified that it could work on High Sierra, make wine/32bit macOS app work with kernel opemu turnes off; BUT, it does not work on Catalina. After some modification, I successful making it works on Catalina (by modify max version), then I adds some logging, after that ( AND turn to FakeSMC since this plugin hooks kernel_trap which conflicts VirtualSMC ), the reason was finally found: when running wine32on64, no ANY invalid opcode exception even CATCHED ( but page fault exception often be watched, which tells that hooks working ) . That should means: 1. in Catalina, since no 32bit syscall exist, sysenter/sysexit was totally replaced by syscall/sysret, which already handles well on AMD CPU; 2. wine32on64 does not uses any other instrument that AMD not supported, or at least invalid opcode exception should be watched.

I think a conclusion can be deduced from all above: what blocks crossover19 from running on Catalina is NOT simply lacking of OPEMU. Though I also don't know what it actually IS, yet : )

Can you test CrossOver 20 beta? I'm in work now, I want to see what happens when you run it on Ryzentosh.

[PSzczepanski1996]

I can confirm CrossOver 20 beta1 doesn't work on Ryzentosh, either using Windows 10, 7 or XP 32-bit bootle.
Windows 10 x64 bootle though works normally.

[palxex]

Can you test CrossOver 20 beta? I'm in work now, I want to see what happens when you run it on Ryzentosh.

Sorry for the late reply, but I cannot. Not owe a copy :( Using build here, so need waiting new open source releases.

Try to build yourself a C program that builds as a 64 bit C program but calls 32 bit bytecode via a 32 bit code segment entry and see if you can get this working on AMD. It's somewhat tricky - beware address space, stack and data segments, return addresses, so first make sure your test program works on a proper mac.

@stefand Could you please give a simple code example? That will helps greatly! Thanks in advance.

[PSzczepanski1996]

Can you test CrossOver 20 beta? I'm in work now, I want to see what happens when you run it on Ryzentosh.

Sorry for the late reply, but I cannot. Not owe a copy :( Using build here, so need waiting new open source releases.

Try to build yourself a C program that builds as a 64 bit C program but calls 32 bit bytecode via a 32 bit code segment entry and see if you can get this working on AMD. It's somewhat tricky - beware address space, stack and data segments, return addresses, so first make sure your test program works on a proper mac.

Could you please give a simple code example? That will helps greatly! Thanks in advance.

You can test Crossover 20 by downloading it from beta section on CodeWeavers site (there was no official release so far).
https://www.codeweavers.com/compatibility/beta

[stefand]

@palxex Ken once built such a thing, I'll ask him if he still has it. A few Linux-specific examples are floating around on stackoverflow, e.g. https://stackoverflow.com/questions/18272384/far-call-into-user32-cs-from-64-bit-code-on-linux . The unfortunate thing about Linux is that it allocates a lot of memory in the low 4GB even in a 64 bit process, so patched together examples are much more likely to work by luck than on Mac.

[PSzczepanski1996]

I tested beta 2 on my rig, and I don't now get debug prompt messages in the Window/GUI, but the debug logs when running app via terminal are the same as previously now:

./CrossOver
libcxsetup-v3.py:warning: Visual C++ 2015-2019 (32 bit) has a bronze or higher medal so it should specify the bottle template(s) to use
libcxsetup-v3.py:warning: Visual C++ 2015-2019 (64bit) has a bronze or higher medal so it should specify the bottle template(s) to use
libcxsetup-v3.py:warning: Visual C++ 2015-2019 (32 bit) has a bronze or higher medal so it should specify the bottle template(s) to use
libcxsetup-v3.py:warning: Visual C++ 2015-2019 (64bit) has a bronze or higher medal so it should specify the bottle template(s) to use
wine: Unhandled stack overflow at address 7BCAF7C5 (thread 0016), starting debugger...
wine: Unhandled stack overflow at address 7BCBD37F (thread 0023), starting debugger...
wine: Unhandled stack overflow at address 7BCBD37F (thread 0034), starting debugger...
2020-09-24 09:44:46.802 wine32on64-preloader[1245:12724] *** WARNING: Method convertPointToBase: in class NSView is deprecated on 10.7 and later. It should not be used in new applications. 
2020-09-24 09:44:46.802 wine32on64-preloader[1245:12724] *** WARNING: Method convertPointFromBase: in class NSView is deprecated on 10.7 and later. It should not be used in new applications. 

When running taskmgr/winecfg. The address seems to be similar (7BCAF7C5 or 7BCBD37F), it is some specific constant due to XNU allocation methods or why beginning of it looks always the same 7BC?

[stefand]

@HoshiYamazaki I saw your request on IRC. Unfortunately I don't have any 32<->64 bit call code on my computers and Ken is away for a while. I am afraid I can't provide you with example code in the near future :-( .

[PSzczepanski1996]

Crossover 20 beta 3 works neither, same stack overflow at the same address...

[PSzczepanski1996]

CrossOver 20 final release too doesn't work (at least when running 32bit code, for example FF XIV works fine), also with newest patch from @Shaneee that fixes MTRR/PAT functionality (mapping) it still raises stack overflow error with the same address.

Not sure at all what is the problem now.

@palxex From your response I see:
if you comment opemu_sysenter call which emulates sysenter/sysexit

Why it even uses opemu_systenter call if that is not used? I don't quite get that but I'm not familiar with XNU kernel at all.

[PSzczepanski1996]

For some reason Crossover started to report correctly processes and memory usage now on my rig until it crashes.

Also, it crashes too when using win 98/xp/7 x32 bit bottle. Here is my log:

libcxsetup-v3.py:warning: AttributeError(u'C4InstallerProfile.selfextract_options is set but no threshold has been specified for application Adobe Digital Editions',)
libcxsetup-v3.py:warning: the com.codeweavers.c4.5004 profile contains errors, ignoring it
libcxsetup-v3.py:warning: Visual C++ 2015-2019 (32 bit) has a bronze or higher medal so it should specify the bottle template(s) to use
libcxsetup-v3.py:warning: Visual C++ 2015-2019 (64bit) has a bronze or higher medal so it should specify the bottle template(s) to use
libcxsetup-v3.py:warning: Ronyasoft Poster Printer has a bronze or higher medal so it should specify the bottle template(s) to use
libcxsetup-v3.py:warning: Visual C++ 2015-2019 (32 bit) has a bronze or higher medal so it should specify the bottle template(s) to use
libcxsetup-v3.py:warning: Visual C++ 2015-2019 (64bit) has a bronze or higher medal so it should specify the bottle template(s) to use
libcxsetup-v3.py:warning: Ronyasoft Poster Printer has a bronze or higher medal so it should specify the bottle template(s) to use
wine: Unhandled stack overflow at address 7BCAF7C5 (thread 001c), starting debugger...
wine: Unhandled stack overflow at address 7BCBD37F (thread 001a), starting debugger...
wine: Unhandled stack overflow at address 7BCBD37F (thread 0024), starting debugger...
wine: Unhandled stack overflow at address 7BCBD37F (thread 001f), starting debugger...
wine: Unhandled stack overflow at address 7BCBD37F (thread 0028), starting debugger...
wine: Unhandled stack overflow at address 7BCBD37F (thread 002a), starting debugger...
wine: Unhandled stack overflow at address 7BCBD37F (thread 0039), starting debugger...
2020-10-20 20:53:17.772 wine32on64-preloader[6681:144170] *** WARNING: Method convertPointToBase: in class NSView is deprecated on 10.7 and later. It should not be used in new applications. 
2020-10-20 20:53:17.772 wine32on64-preloader[6681:144170] *** WARNING: Method convertPointFromBase: in class NSView is deprecated on 10.7 and later. It should not be used in new applications. 
wine: Unhandled stack overflow at address 7BCBD37F (thread 0034), starting debugger...

From what I understand, the error is not fixable by CodeWeavers team (@stefand) but the problem is in (probably) Fix PAT patch which is still broken and is not allocating memory regions correctly in MTRR/PAT values.

Confirmed also by @Pavo-IM it does work without Fix PAT patch which is not needed on threadrippers.

@Shaneee can you revisite the issue in free time?

[Pavo-IM]

Putty 32-bit app running on Crossover 20 on BigSur beta 10 on Threadripper system.

[mjgha]

Putty 32-bit app running on Crossover 20 on BigSur beta 10 on Threadripper system.

Have you had to do anything special to get it to work?

[PSzczepanski1996]

Any updates on this? I’m also trying to run 32-bit Windows applications using CrossOver on a Ryzen system and getting the same stack overflow exception.

Nope, you can configure macOS VM under Proxmox with GPU Passthrough and CrossOver will run and that's the only solution.
I slowly move into Arch because of that at my home machine and at work I just use proper Mac.

[tomnic79]

Crossover 21 final seems to works fine with Ryzen and 32 bit apps, Monterey Final 12.0.1

[tomnic79]

Steam installs correctly, downloads its updates fine but hangs updating. Need to find out why!

[PSzczepanski1996]

Crossover 21 final seems to works fine with Ryzen and 32 bit apps, Monterey Final 12.0.1

It does not on Ryzen r5 3600, so far it's not crashing after few seconds but now, after about half of minute, so it's more stable, but still buggy and unusable.

[PSzczepanski1996]

Can confirm that CrossOver update to 21.1 version does not resolve the issue.

[PSzczepanski1996]

Version 21.2 does not work either.

--- UPDATE ---

Version 22.0.0 beta 2 does not work either, but gives new errors when creating Windows 10 32-bit based bottle. I also tried to create Windows 7 32-bit bottle, and then install steam in it. It gives similar errors:

What surprises me the most that using winecfg does not crash at all and it's so far stable.
I will see how Ventura will behave on my build and how final release will work after all.

[PSzczepanski1996]

Okey, so CrossOver 22.0.1 and 22.1-b1 are not working either - anyway I managed to get again different errors when I started to debug the issue on my Ryzen rig (on Ventura 13.1 stable):

2023-01-21 17:35:59.793 CrossOver[5208:75625] +[CATransaction synchronize] called within transaction
2023-01-21 17:36:07.164 CrossOver[5208:75625] +[CATransaction synchronize] called within transaction
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
libcxsetup-v3.py:error: uncompress did not set self.error
libcxsetup-v3.py:error: uncompress did not set self.error
libcxsetup-v3.py:error: <cxaiecore.AIECore object at 0x12462fc10>: AIECore should have been set
2023-01-21 17:37:45.503 CrossOver[5208:75625] +[CATransaction synchronize] called within transaction
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
libcxsetup-v3.py:error: uncompress did not set self.error
libcxsetup-v3.py:error: <cxaiecore.AIECore object at 0x126a72820>: AIECore should have been set

I'm getting these errors during Steam installation, and they seem to be releated to memory allocation - I'm still unsure what we can do about this, and I'm still curious why CrossOver is working without hassle on Ryzens from 5xxx/7xxx series (according to AMD OSX discord).
I also prepared Win7 64-bit and Win10 64-bit logs from CrossOver 22.1-b1, here we go:
crossover-beta-wine-amd.txt
crossover-beta-wine10-amd.txt

I maybe will try to look into the issue but I don't give any hope because maybe soon I will be not able todo it since I'm planning to switch to Intel/ARM based Mac.
Maybe these logs will help somebody... I wish.

[nitantsoni]

Have this same issue. Wine programs in general seem to be very unstable on my Ryzen 2xxx. They work great comparatively on an Intel MacBook. Is this not an issue on the Ryzen 5xxx/7xxx?

[piRsquaredH256]

Have the same issue on Ventura 13.4.1 Ryzen 5 3600

Okey, so CrossOver 22.0.1 and 22.1-b1 are not working either - anyway I managed to get again different errors when I started to debug the issue on my Ryzen rig (on Ventura 13.1 stable):

2023-01-21 17:35:59.793 CrossOver[5208:75625] +[CATransaction synchronize] called within transaction
2023-01-21 17:36:07.164 CrossOver[5208:75625] +[CATransaction synchronize] called within transaction
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
libcxsetup-v3.py:error: uncompress did not set self.error
libcxsetup-v3.py:error: uncompress did not set self.error
libcxsetup-v3.py:error: <cxaiecore.AIECore object at 0x12462fc10>: AIECore should have been set
2023-01-21 17:37:45.503 CrossOver[5208:75625] +[CATransaction synchronize] called within transaction
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
preloader: Warning: failed to reserve range 0000000000010000-0000000000110000
libcxsetup-v3.py:error: uncompress did not set self.error
libcxsetup-v3.py:error: <cxaiecore.AIECore object at 0x126a72820>: AIECore should have been set

I'm getting these errors during Steam installation, and they seem to be releated to memory allocation - I'm still unsure what we can do about this, and I'm still curious why CrossOver is working without hassle on Ryzens from 5xxx/7xxx series (according to AMD OSX discord). I also prepared Win7 64-bit and Win10 64-bit logs from CrossOver 22.1-b1, here we go: crossover-beta-wine-amd.txt crossover-beta-wine10-amd.txt

I maybe will try to look into the issue but I don't give any hope because maybe soon I will be not able todo it since I'm planning to switch to Intel/ARM based Mac. Maybe these logs will help somebody... I wish.

[PSzczepanski1996]

Hey, can anybody from people posting here try to test CrossOver 23 beta version? I don't have anymore access to my old AMD build, but I will really appreciate if somebody will do it. You don't need to install Sonoma, just try to download the beta version from website and install it on for e.g. Ventura.

Thanks in advance!

[nitantsoni]

Moved to Intel, though could maybe test on the old AMD machine, but not a part of their beta tester program

[Its-Kenta]

Can confirm Crossover 23 works perfectly fine on my AMD 5600x.
Install steam, games and it just works.

[nitantsoni]

Good to know that the Ryzen 5xxx's work

[nanohelperDev]

Its still not working on amd rayzen 5 5625u,

[PSzczepanski1996]

Please re-test it on CrossOver 24, the new release probably has different WoW64 mechanism that can fix 32-bit issue.

[tomnic79]

Both 3DMark 2001 and 3DMark 2005 run perfectly with Crossover 24, AMD 7950x based Hackintosh

[PSzczepanski1996]

Can anybody test in any laptop with Vega 8 / 10 that uses NootedRed?
I'm really interested in the results 🍎

[nisel11]

Can anybody test in any laptop with Vega 8 / 10 that uses NootedRed? I'm really interested in the results 🍎

I have a Ryzen 5 3550H and Vega 8.
Steam starts up, but after a couple minutes it shuts down and doesn't start up again. At the same time I played Hearts of Iron 4 without Steam and the game ran fine. But the installer was not working properly, after a couple of seconds the wine debugger would appear and the installation would shut down, only copying the game files from Windows helped.
I just tried running Putty 32 and 64 bit in win 10 64 and 32 bit and everything worked fine

[PSzczepanski1996]

Can anybody test in any laptop with Vega 8 / 10 that uses NootedRed? I'm really interested in the results 🍎

I have a Ryzen 5 3550H and Vega 8. Steam starts up, but after a couple minutes it shuts down and doesn't start up again. At the same time I played Hearts of Iron 4 without Steam and the game ran fine. But the installer was not working properly, after a couple of seconds the wine debugger would appear and the installation would shut down, only copying the game files from Windows helped. I just tried running Putty 32 and 64 bit in win 10 64 and 32 bit and everything worked fine

Thanks, I very much appreciate your post! Anyone else has also tried to run OSX on AMD + NootedRed and tested CrossOver 24?

[AGXCLIENTS]

Maybe not with nootedred, but actually my Ryzen 3 4100 + rx 580 8GB set works really good on Crossover 24. There have been huge problems in the past, e.g. 32-bit osu! was crashing a lot before, now it's much better.