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.

[im-not-a-dev]

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.

[H20Vie]

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

I know this is a bit ancient but, have you ever found a way to make it work? I've tried countless times to install Steam wether through PlayOnMac or the superior CrossOver. I've seen some people in the AMD Hackintosh server talk about how you could run steam and stop it from crashing through an implementation in WoW64, but I don't think that makes sense because Steam never had a 64-Bit release on Windows unlike on mac. Have you found a way to get it working? I'm having the same issue as you did on Crossover 24.0.4 on macOS 14.6.1.

Thanks!

[PSzczepanski1996]

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

I know this is a bit ancient but, have you ever found a way to make it work? I've tried countless times to install Steam wether through PlayOnMac or the superior CrossOver. I've seen some people in the AMD Hackintosh server talk about how you could run steam and stop it from crashing through an implementation in WoW64, but I don't think that makes sense because Steam never had a 64-Bit release on Windows unlike on mac. Have you found a way to get it working? I'm having the same issue as you did on Crossover 24.0.4 on macOS 14.6.1.

Thanks!

It has sense because WoW64 implementation allows to run 32-bit processes in 64-bit environment. That this is what WoW64 truly is.

For example, Box64-based solutions for running games on Android (mostly Snapdragon phones) also uses WoW64 mechanism: https://www.youtube.com/watch?v=9_ie9E__vAU https://www.youtube.com/watch?v=e-y4FCV_hwg

So, if you run Steam as 32-bit process (and the Windows version is a 32-bit release), WoW64 is trying to translate it into 64-bit userspace. I'm still unsure if Wine in CrossOver uses WoW64 since it's considered experimental and maybe uses old LDT syscall solution, this could explain why it's still not working.

@stefand can you respond to that? Does CrossOver 24 rely on WoW64 nowadays or it still uses syscalls?

[stefand]

CrossOver uses the new Wine WoW64 architecture, with some parts that are in the process of being upstreamed to Wine and some parts that are Mac-specific hacks (e.g. using some mach kernel calls to duplicate a GL/Vulkan buffer map to an address below 4GB).

A possible misunderstanding is that Wine/CrossOver now does those far calls at something similar to the Windows syscall interface - we have something that looks very similar to the original ntdll syscall thunk but has a carefully crafted relative jump instead of an int 0x2e, followed by a far call. Chromium's sandbox and DRM systems can successfully patch this syscall thunk because it is very close to the original one, but it never performs an actual syscall or int.

Wine creates LDT entries for 32 bit code, stack and data segments and uses far calls to jump between them. The far calls are handled inside Wine, but we need kernel support for correct task switching and signal delivery when executing 32 bit code - this is the reason why you can't run 16 bit code. On a x86 CPU MacOS allows us to create 16 bit segments and jump to them, but as soon as a signal arrives the signal handler gets broken information from the kernel. On Rosetta, attempting to create 16 bit LDT entries runs into an assert() that says this is unimplemented.

CrossOver never used syscalls for the 32/64 boundary. Hangover did, but those "syscalls" were just the easiest way to jump out of qemu's emulation. We experimented with HW virtualization for running 32 bit code in CrossOver before Apple gave us support for 32 bit code segments. Those used vmcalls to jump out of the emulation and the performance was unusable.

Even CrossOver 20 didn't use syscalls (fake or real), it was always far calls/rets. The difference between earlier CrossOver versions and newer ones is that previously we used a special compiler to generate far call thunks at the Win32 API level. The new wow64.dll, win32u.dll etc layer doesn't need a magic compiler and makes Chromium's sandbox happy.

[PSzczepanski1996]

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

I know this is a bit ancient but, have you ever found a way to make it work? I've tried countless times to install Steam wether through PlayOnMac or the superior CrossOver. I've seen some people in the AMD Hackintosh server talk about how you could run steam and stop it from crashing through an implementation in WoW64, but I don't think that makes sense because Steam never had a 64-Bit release on Windows unlike on mac. Have you found a way to get it working? I'm having the same issue as you did on Crossover 24.0.4 on macOS 14.6.1.

Thanks!

Ok, I can confirm it crashes on my Thinkpad T14 G1 with AMD R5 4650U CPU. Gonna post my NeoFetch here:

And now this is log I created using "launch with options" feature:

amd_4650.cxlog.zip

Gonna see what I can do with it (or maybe I will help again somebody to debug this issue).

And now, this is fairly interesting exception:

038c:0390:trace:module:load_dll Found L"C:\\windows\\system32\\ucrtbase.dll" for L"ucrtbase.dll" at 7B840000, count=-1
038c:0390:trace:module:build_module loaded L"\\??\\C:\\windows\\system32\\rsaenh.dll" 000164F8 7A380000
038c:0390:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\rsaenh.dll" at 7A380000: builtin
038c:0390:trace:module:load_dll Loaded module L"\\??\\C:\\windows\\system32\\rsaenh.dll" at 7A380000
038c:0390:trace:module:process_attach (L"rsaenh.dll",00000000) - START
038c:0390:trace:module:MODULE_InitDLL (7A380000 L"rsaenh.dll",PROCESS_ATTACH,00000000) - CALL
038c:0390:trace:module:LdrGetDllHandleEx flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012D77C, base 0012D778.
038c:0390:trace:module:LdrGetDllHandleEx L"ntdll.dll" -> 7BF50000 (load path (null))
038c:0390:trace:module:MODULE_InitDLL (7A380000,PROCESS_ATTACH,00000000) - RETURN 1
038c:0390:trace:module:process_attach (L"rsaenh.dll",00000000) - END
038c:0390:trace:module:LdrGetDllHandleEx flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012D960, base 0012D95C.
038c:0390:trace:module:LdrGetDllHandleEx L"ntdll.dll" -> 7BF50000 (load path (null))
038c:0390:trace:module:LdrResolveDelayLoadedAPI (6CEC0000, 6CED3364, 00000000, 7BECB374, 6CEDB200, 0x00000000)
038c:0390:trace:module:LdrResolveDelayLoadedAPI (6CEC0000, 6CED3364, 00000000, 7BECB374, 6CEDB204, 0x00000000)
038c:0390:trace:module:LdrResolveDelayLoadedAPI (7A4A0000, 7A4E52D0, 00000000, 7BECB374, 7A4F7480, 0x00000000)
038c:0390:trace:module:load_dll looking for L"crypt32.dll" in (null)
038c:0390:trace:module:load_dll Found L"C:\\windows\\system32\\crypt32.dll" for L"crypt32.dll" at 7A7B0000, count=3
038c:0390:trace:module:LdrGetDllHandleEx flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012DD4C, base 0012DD48.
038c:0390:trace:module:LdrGetDllHandleEx L"ntdll.dll" -> 7BF50000 (load path (null))
038c:0390:trace:process:ExpandEnvironmentStringsW (L"C:\\windows\\system32\\rsaenh.dll" 00000000 0)
038c:0390:trace:process:ExpandEnvironmentStringsW (L"C:\\windows\\system32\\rsaenh.dll" 009862D8 31)
038c:0390:trace:module:load_dll looking for L"C:\\windows\\system32\\rsaenh.dll" in L"C:\\Program Files (x86)\\Steam;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\Program Files (x86)\\Steam;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\windows\\system32\\WindowsPowershell\\v1.0"
038c:0390:trace:module:load_dll Found L"C:\\windows\\system32\\rsaenh.dll" for L"C:\\windows\\system32\\rsaenh.dll" at 7A380000, count=2
038c:0390:trace:module:LdrUnloadDll (7A380000)
038c:0390:trace:module:LdrUnloadDll (L"rsaenh.dll") - START
038c:0390:trace:module:MODULE_DecRefCount (L"rsaenh.dll") ldr.LoadCount: 1
038c:0390:trace:module:LdrUnloadDll END
038c:0390:trace:module:LdrGetDllHandleEx flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012E080, base 0012E07C.
038c:0390:trace:module:LdrGetDllHandleEx L"ntdll.dll" -> 7BF50000 (load path (null))
038c:0390:trace:module:LdrResolveDelayLoadedAPI (7A4A0000, 7A4E52D0, 00000000, 7BECB374, 7A4F7488, 0x00000000)
038c:0390:trace:module:LdrResolveDelayLoadedAPI (7A4A0000, 7A4E52D0, 00000000, 7BECB374, 7A4F747C, 0x00000000)
038c:0390:trace:module:LdrResolveDelayLoadedAPI (7A4A0000, 7A4E52AC, 00000000, 7BECB374, 7A4F7614, 0x00000000)
015c:01b0:fixme:wow:wow64_NtPowerInformation unsupported level 12
038c:0390:trace:module:LdrResolveDelayLoadedAPI (7A4A0000, 7A4E52AC, 00000000, 7BECB374, 7A4F760C, 0x00000000)
038c:0390:trace:module:LdrAddRefDll (L"WININET.dll") ldr.LoadCount: -1
038c:039c:trace:module:alloc_thread_tls slot 0: 8/0 bytes at 009D69C0
038c:039c:trace:module:alloc_thread_tls slot 1: 1036/0 bytes at 009D6DA0
038c:039c:trace:module:alloc_thread_tls slot 2: 8/0 bytes at 009D69E0
038c:039c:trace:module:MODULE_InitDLL (7B960000 L"msvcrt.dll",THREAD_ATTACH,00000000) - CALL
038c:039c:trace:module:MODULE_InitDLL (7B960000,THREAD_ATTACH,00000000) - RETURN 1
038c:0390:warn:seh:OutputDebugStringW L"Uploaded dump (out-of-process): C:\\Program Files (x86)\\Steam\\dumps\\assert_steam.exe_20240829090317_1.dmp - Discarded=1\n\n"
038c:039c:trace:module:MODULE_InitDLL (7B840000 L"ucrtbase.dll",THREAD_ATTACH,00000000) - CALL
038c:039c:trace:module:MODULE_InitDLL (7B840000,THREAD_ATTACH,00000000) - RETURN 1
038c:0390:trace:seh:dispatch_exception code=4001000a flags=0 addr=000000007BC344A5 ip=6ffffe66fa04
038c:0390:trace:seh:dispatch_exception  info[0]=0000000000000079
038c:0390:trace:seh:dispatch_exception  info[1]=000000000012fa8c
038c:0390:trace:seh:dispatch_exception  info[2]=0000000000000079
038c:039c:trace:module:MODULE_InitDLL (7BA60000 L"USER32.dll",THREAD_ATTACH,00000000) - CALL
038c:0390:trace:seh:dispatch_exception  info[3]=00000000009bfed8
038c:039c:trace:module:MODULE_InitDLL (7BA60000,THREAD_ATTACH,00000000) - RETURN 1
038c:0390:warn:seh:dispatch_exception L"Uploaded dump (out-of-process): C:\\Program Files (x86)\\Steam\\dumps\\assert_steam.exe_20240829090317_1.dmp - Discarded=1\n\n"
038c:039c:trace:module:MODULE_InitDLL (7A8D0000 L"imm32.dll",THREAD_ATTACH,00000000) - CALL
038c:0390:trace:seh:call_stack_handlers found wine frame 00000001001FECD0 rsp 00000001001FF2E0 handler 00006FFFFE6744E0
038c:039c:trace:module:MODULE_InitDLL (7A8D0000,THREAD_ATTACH,00000000) - RETURN 1
038c:0390:trace:seh:call_teb_handler calling TEB handler 00006FFFFE6744E0 (rec=00000001001FEA70, frame=00000001001FECD0 context=00000001001FDFE0, dispatch=00000001001FDEB0)
038c:039c:trace:module:MODULE_InitDLL (79300000 L"tier0_s.dll",THREAD_ATTACH,00000000) - CALL
038c:039c:trace:module:MODULE_InitDLL (79300000,THREAD_ATTACH,00000000) - RETURN 1
038c:0390:trace:seh:RtlRestoreContext returning to 00006FFFFE67438A stack 00000001001FEC90
038c:039c:trace:module:MODULE_InitDLL (78050000 L"vstdlib_s.dll",THREAD_ATTACH,00000000) - CALL
038c:039c:trace:module:MODULE_InitDLL (78050000,THREAD_ATTACH,00000000) - RETURN 1
038c:039c:trace:module:MODULE_InitDLL (7A740000 L"ws2_32.dll",THREAD_ATTACH,00000000) - CALL
038c:039c:trace:module:MODULE_InitDLL (7A740000,THREAD_ATTACH,00000000) - RETURN 1
038c:039c:trace:module:MODULE_InitDLL (7A4A0000 L"WININET.dll",THREAD_ATTACH,00000000) - CALL
038c:039c:trace:module:MODULE_InitDLL (7A4A0000,THREAD_ATTACH,00000000) - RETURN 1
038c:039c:trace:module:MODULE_InitDLL (7ABB0000 L"rpcrt4.dll",THREAD_ATTACH,00000000) - CALL
038c:039c:trace:module:MODULE_InitDLL (7ABB0000,THREAD_ATTACH,00000000) - RETURN 1
038c:0390:trace:seh:RtlInitializeExtendedContext2 context 000000000012F528, context_flags 0x1003f, context_ex 00000001001FE978, compaction_mask ffffffffffffffff.
038c:0390:trace:seh:dispatch_exception code=4001000a flags=0 addr=7BC344A5 ip=7bc344a5
038c:0390:trace:seh:dispatch_exception  info[0]=00000079
038c:0390:trace:seh:dispatch_exception  info[1]=0012fa8c
038c:0390:trace:seh:dispatch_exception  info[2]=00000079
038c:0390:trace:seh:dispatch_exception  info[3]=009bfed8
038c:0390:warn:seh:dispatch_exception L"Uploaded dump (out-of-process): C:\\Program Files (x86)\\Steam\\dumps\\assert_steam.exe_20240829090317_1.dmp - Discarded=1\n\n"
038c:0390:trace:seh:call_stack_handlers calling handler at 7BCA38D0 code=4001000a flags=0
038c:0390:trace:seh:__regs_RtlUnwind code=4001000a flags=2
038c:0390:trace:seh:__regs_RtlUnwind eax=00000000 ebx=00000000 ecx=4001000a edx=0012fa08 esi=0012f4d8 edi=0012fa08
038c:0390:trace:seh:__regs_RtlUnwind ebp=0012f3d8 esp=0012f3d0 eip=7bca3866 cs=0107 ds=0023 fs=010f gs=0000 flags=00000202
038c:0390:trace:seh:__regs_RtlUnwind calling handler at 7BFA4DD0 code=4001000a flags=2
038c:0390:trace:seh:__regs_RtlUnwind handler at 7BFA4DD0 returned 1
038c:0390:warn:seh:OutputDebugStringA "Uploaded dump (out-of-process): C:\\Program Files (x86)\\Steam\\dumps\\assert_steam.exe_20240829090317_1.dmp - Discarded=1\n\n"
038c:0390:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007BC34290 ip=6ffffe66fa04
038c:0390:trace:seh:dispatch_exception  info[0]=0000000000000079
038c:0390:trace:seh:dispatch_exception  info[1]=00000000009bfed8
038c:0390:warn:seh:dispatch_exception "Uploaded dump (out-of-process): C:\\Program Files (x86)\\Steam\\dumps\\assert_steam.exe_20240829090317_1.dmp - Discarded=1\n\n"
038c:0390:trace:seh:call_stack_handlers found wine frame 00000001001FECD0 rsp 00000001001FF2E0 handler 00006FFFFE6744E0
038c:0390:trace:seh:call_teb_handler calling TEB handler 00006FFFFE6744E0 (rec=00000001001FEA70, frame=00000001001FECD0 context=00000001001FDFE0, dispatch=00000001001FDEB0)
038c:0390:trace:seh:RtlRestoreContext returning to 00006FFFFE67438A stack 00000001001FEC90
038c:0390:trace:seh:RtlInitializeExtendedContext2 context 000000000012F430, context_flags 0x1003f, context_ex 00000001001FE978, compaction_mask ffffffffffffffff.
038c:0390:trace:seh:dispatch_exception code=40010006 flags=0 addr=7BC34290 ip=7bc34290
038c:0390:trace:seh:dispatch_exception  info[0]=00000079
038c:0390:trace:seh:dispatch_exception  info[1]=009bfed8
038c:0390:warn:seh:dispatch_exception "Uploaded dump (out-of-process): C:\\Program Files (x86)\\Steam\\dumps\\assert_steam.exe_20240829090317_1.dmp - Discarded=1\n\n"
038c:0390:trace:seh:call_stack_handlers calling handler at 7BCA38D0 code=40010006 flags=0
038c:0390:trace:seh:__regs_RtlUnwind code=40010006 flags=2
038c:0390:trace:seh:__regs_RtlUnwind eax=00000000 ebx=00000000 ecx=40010006 edx=0012f918 esi=0012f3e0 edi=0012f918
038c:0390:trace:seh:__regs_RtlUnwind ebp=0012f2e0 esp=0012f2d8 eip=7bca3866 cs=0107 ds=0023 fs=010f gs=0000 flags=00000216
038c:0390:trace:seh:__regs_RtlUnwind calling handler at 7BFA4DD0 code=40010006 flags=2
038c:0390:trace:seh:__regs_RtlUnwind handler at 7BFA4DD0 returned 1
038c:039c:warn:threadname:NtSetInformationThread Thread renamed to L"wine_wininet_collect_connections"
015c:0160:trace:module:FindResourceExW 7BA60000 #0004 L"SYSMENU" 0000
015c:0160:trace:module:LoadResource 7BA60000 7BB1DAF8
015c:0160:trace:module:load_dll looking for L"dwmapi.dll" in L"C:\\Program Files (x86)\\Steam\\bin\\cef\\cef.win7;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\windows\\system32\\WindowsPowershell\\v1.0"
015c:0160:trace:module:load_dll Found L"C:\\windows\\system32\\dwmapi.dll" for L"dwmapi.dll" at 77A20000, count=-1
015c:0160:trace:module:LdrGetDllHandleEx flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012E078, base 0012E074.
015c:0160:trace:module:LdrGetDllHandleEx L"ntdll.dll" -> 7BF50000 (load path (null))
015c:0160:fixme:dwmapi:DwmSetWindowAttribute flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012DC58, base 0012DC54.
015c:0160:trace:module:LdrGetDllHandleEx L"ntdll.dll" -> 7BF50000 (load path (null))
(00050106, 14, 0012E168, 4) stub
015c:0160:trace:module:LdrUnloadDll (77A20000)
015c:0160:trace:module:LdrUnloadDll (L"dwmapi.dll") - START
015c:0160:trace:module:LdrUnloadDll END
015c:0160:fixme:win:RegisterTouchWindow hwnd 00050106, flags 0x3 stub!
015c:0160:fixme:wgl:macdrv_wglChoosePixelFormatARB unused pfAttribFList
015c:0160:trace:module:LdrGetDllHandleEx flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012E27C, base 0012E278.
015c:0160:trace:module:LdrGetDllHandleEx L"Shell32.dll" -> 7AE50000 (load path (null))
015c:0160:fixme:shell:SHGetPropertyStoreForWindow flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012DDF8, base 0012DDF4.
015c:0160:trace:module:LdrGetDllHandleEx L"ntdll.dll" -> 7BF50000 (load path (null))
(00050106 00802CA0 0012E2F8) stub!
015c:0160:trace:module:LdrGetDllHandleEx flags 0x1, load_path 00000000, dll_characteristics 00000000, name 0012E118, base 0012E114.
015c:0160:trace:module:LdrGetDllHandleEx L"ntdll.dll" -> 7BF50000 (load path (null))
015c:0160:fixme:shell:window_prop_store_SetValue 03AFAF80, {{9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3},5}, 0012E298
015c:0160:fixme:shell:window_prop_store_SetValue 03AFAF80, {{9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3},2}, 0012E298
015c:0160:fixme:shell:window_prop_store_SetValue 03AFAF80, {{9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3},4}, 0012E298
015c:0160:fixme:shell:window_prop_store_Commit 03AFAF80
015c:0160:trace:module:load_dll looking for L"dwmapi.dll" in L"C:\\Program Files (x86)\\Steam\\bin\\cef\\cef.win7;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\windows\\system32\\WindowsPowershell\\v1.0"
015c:0160:trace:module:load_dll Found L"C:\\windows\\system32\\dwmapi.dll" for L"dwmapi.dll" at 77A20000, count=-1
015c:0160:fixme:dwmapi:DwmExtendFrameIntoClientArea (00050106, 0012E314) stub
015c:0160:trace:module:LdrUnloadDll (77A20000)
015c:0160:trace:module:LdrUnloadDll (L"dwmapi.dll") - START
015c:0160:trace:module:LdrUnloadDll END
015c:0160:trace:module:FindResourceExW 7BA60000 #000c #7f00 0000
015c:0160:trace:module:LoadResource 7BA60000 7BB1E978
015c:0160:trace:module:FindResourceExW 7BA60000 #0001 #0003 0000
015c:0160:trace:module:LdrGetDllFullName module 7BA60000, name 0012E820.
015c:0160:fixme:uxtheme:AllowDarkModeForWindow 0002010A 1: stub
015c:0160:fixme:dwmapi:DwmExtendFrameIntoClientArea (0002010A, 0012DDD0) stub
015c:01cc:fixme:wtsapi:WTSRegisterSessionNotification Stub 000100EA 0x00000000
015c:0160:trace:module:FindResourceExW 7BA60000 #000c #7f00 0000
015c:0160:trace:module:LoadResource 7BA60000 7BB1E978
015c:0160:trace:module:FindResourceExW 7BA60000 #0001 #0003 0000
015c:0160:trace:module:LdrGetDllFullName module 7BA60000, name 0012DFD8.
015c:0160:trace:module:load_dll looking for L"C:\\windows\\system32\\ole32.dll" in L"C:\\windows\\system32;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\windows\\system32\\WindowsPowershell\\v1.0"
015c:0160:trace:module:load_dll Found L"C:\\windows\\system32\\ole32.dll" for L"C:\\windows\\system32\\ole32.dll" at 7ACA0000, count=-1
015c:0160:warn:module:LdrGetProcedureAddress "DllCanUnloadNow" (ordinal 0) not found in L"C:\\windows\\system32\\ole32.dll"
015c:03a0:trace:module:alloc_thread_tls slot 0: 1157/0 bytes at 01016210
015c:03a0:trace:module:alloc_thread_tls slot 1: 396/0 bytes at 00F4FA98
015c:03a0:trace:module:alloc_thread_tls slot 2: 4/0 bytes at 01010F90
015c:03a0:trace:module:alloc_thread_tls slot 3: 4/0 bytes at 01010FB0
015c:03a0:trace:module:alloc_thread_tls slot 4: 148/0 bytes at 00DDF1E8
015c:03a0:trace:module:alloc_thread_tls slot 5: 8/0 bytes at 01010FD0
015c:03a0:trace:module:alloc_thread_tls slot 6: 8/0 bytes at 01010FF0
015c:03a0:trace:module:alloc_thread_tls slot 7: 161/0 bytes at 00F25900
015c:03a0:trace:module:alloc_thread_tls slot 8: 144/0 bytes at 00DDF288
015c:03a0:trace:module:alloc_thread_tls slot 9: 8/0 bytes at 01011010

I don't see anything more interesting in the logs anyway, bad the exception appear to happen multiple times during the CrossOver launch time.

[PSzczepanski1996]

@stefand any ideas about this CrossOver log I posted and how CodeWeavers could implement fix for that?

[stefand]

Not much I can see in there. Exception codes 4001000a and 40010006 are DBG_PRINTEXCEPTION_WIDE_C and DBG_PRINTEXCEPTION_C, i.e. produced by OutputDebugString() and caught by the same functions immediately. You can ignore them, they are a way for debuggers to be notified about calls to OutputDebugString. If those exceptions cause problems then exception handling as a whole is broken and you are in deep trouble.

[H20Vie]

Here on my Ryzen 5 3600 build with macOS 14.6.1, I get a similar result as what @PSzczepanski1996 has gotten in their steam install, in my case specifically it would crash after the update window would initially close to bring the steam menu, Sometimes i was able to get into my library and things but it would've been very slow and it would crash every time after a while. Here's my neofetch and logfile i got after i ran Steam.

Steam 2.cxlog.zip

I've also seen some people say that steam/crossover works fine on their ryzentoshes on anything lower than macOS Sonoma (i,e macOS Ventura and such). As far as i could tell there shouldn't be a reason for it to not work because of macOS 14 but who knows.

Thanks again for taking an interest at this peculiar thing again

[Shaneee]

Got it working with a few fixes,

https://www.applegamingwiki.com/wiki/CrossOver#Upgrading_DXVK_and_MoltenVK

I applied the update for MoltenVK and DXVK. Unsure if it was necessary and I applied the fix here, https://github.com/Gcenx/CrossOver-fixes

Now steam loads up. Logged in scanning QR code from Steam Mobile. Latest Crossover version on Sequoia beta 8 :)

[H20Vie]

Hey @Shaneee, I've tried the tweaks that managed to get your machine working with steam but mine ends up the same way, crashing after this specific window.

I presume i installed the tweaks correctly? Did you have anything else tweaked in crossover? Thanks