Hanging DLL

[randy-girard]

Hello, I have a dll file that seems to hang when trying to load a game with this, crossover, and playonmac that are supposed to support catalina. I think its probably an issue with the dll, but is there anyway to tell what the dll is doing so i might be able to better figure out if i can configure something or if possible to make a source code change to support it? Thanks

[Gcenx]

You’ll need to provide more information like the games name and the possible issue as your being very vague.

If the game your attempting to run is 16Bit your SOL as wine32on64 doesn’t support 16Bit.

If you want to attempt source modifications check https://github.com/Gcenx/WineCX that’s a mirror of crossover-wine sources, for the other components you’ll need to download directly from CodeWeavers (the links on the mirror)

[randy-girard]

The game is Everquest, the titanium client. Its for the Project1999 server. The thing that is interesting is that out of the box, this game works fine, however Project1999 provides a custom DSETUP.dll file. Wine appears to hang when it gets to loading this data and crashes. It throws raise exception issues in the debugging.

0009:trace:module:GetModuleFileNameW L"C:\\EverQuest\\DSETUP.dll"
0009:trace:seh:__regs_NtGetContextThread 0xfffffffe: dr0=00000000 dr1=00000000 dr2=00000000 dr3=00000000 dr6=00000000 dr7=00000000
0009:trace:seh:raise_exception code=c000008e flags=0 addr=0x7bc72002 ip=7bc72002 tid=0009
0009:trace:seh:raise_exception  eax=0033e760 ebx=0033e760 ecx=7bca9050 edx=0033e750 esi=0033e750 edi=100b7000
0009:trace:seh:raise_exception  ebp=0033e790 esp=0033e754 cs=331007 ds=ffff100f es=7bca100f fs=1017 gs=7bca0000 flags=00000216
0009:trace:seh:call_vectored_handlers calling handler at 0x101308b3 code=c000008e flags=0
0009:trace:seh:call_vectored_handlers handler at 0x101308b3 returned ffffffff
0009:trace:seh:NtContinue (0x33e47c, 0) stub!
0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x1032a9bb ip=1032a9bb tid=0009
0009:trace:seh:raise_exception  info[0]=00000001
0009:trace:seh:raise_exception  info[1]=fffffffc
0009:trace:seh:raise_exception  eax=1020583e ebx=1020586d ecx=fffffffc edx=10205861 esi=390a003a edi=00000000
0009:trace:seh:raise_exception  ebp=1020583e esp=0033e858 cs=1007 ds=100f es=100f fs=1017 gs=0000 flags=00010202
0009:trace:seh:call_stack_handlers calling handler at 0x100b7ee8 code=c0000005 flags=0
0009:trace:seh:call_stack_handlers handler at 0x100b7ee8 returned 0
0009:trace:seh:NtContinue (0x33e4b0, 0) stub!
0026:trace:msg:peek_message got type 6 msg 113 (WM_TIMER) hwnd 0x10028 wp 10000000001 lp 6000000000
0026:trace:msg:peek_message got type 6 msg 113 (WM_TIMER) hwnd 0x10028 wp 10000000001 lp 6000000000
0013:trace:module:LdrShutdownThread ()

I was hoping there might be a way to figure out why this DLL is hanging or not being allowed to run. I have tried doing various things like disabling SIP, setting the sudo nvram boot-args="no32exec=0" and a bunch of different settings in this wineskin. I know the ultimate solution is probably to get the Project1999 team to fix the dll, but this dll works fine on pre-catalina wineskins. I should also note that I use to use a WS9Wine2.22 version I beleive it was. Is it possible to compile one of those with wine32on64? I'm not entirely sure what that entails or means really.

[Gcenx]

Dsetup.dll is not something provided by wine so....

So this last worked with Wine-2.22, has this worked with anything more recent at all?

And finally no Wine-2.22 can’t be compiled with wine32on64 that’s something exclusive to very recent CrossOver sources starting with 19.0.0 that’s based on wine-4.12.1, 20.0.0 is based on Wine-5.0

[randy-girard]

I had not tried it with anything more recent. I was hoping there would be some say to dig deeper into the debugging output to get a better sense of what is throwing the exception. I had noticed there was another error in the output of 005f:trace:seh:IsBadReadPtr 0x7ffbe000 caused page fault during read

I assume there is something in catalina preventing the DLL from loading, but I cannot seem to discover what that is. Here is more info I have been collecting if its of use https://www.project1999.com/forums/showthread.php?t=371291

[Gcenx]

What engine are you using Specifically and where is the dsetup.dll being placed?

[randy-girard]

For this wineskin setup, I am using WS11WineCX19.0.1-1. The dsetup.dll file gets put in the root of the Everquest install directory, along with a bunch of other files. If I revert only that file back to the one with the installer, the client will start up, however you cannot play on their server because they provide some code in their dsetup.dll that modified the client some to provide a more classic experience.

[Gcenx]

I’m going to make an assumption here that could be wrong.

The provided dsetup.dll requires its loaded into a specific location in memory and its crashing due to it not being loaded into this location. The dll could be recompiled to allow it to be loaded anywhere in memory should get it working.

[randy-girard]

Yea, unfortunately I don't have control over this file and not sure I can nudge them to do this. This is why I was trying to find an alternative solution. Wine has been the only method that gives me a good experience with both the game and the mouse. I'm currently trying to use Parallels, but the mouse support with the game isn't ideal. I appreciate the help.

[Gcenx]

You might as well request they rebuild the dll so it can be loaded into any location in memory.

I’d recently helped someone or a similar situation where the server required using a provided dll but that ended up working just one once wine known to use the provided dll over its own, this worked on macOS Catalina I thought issue then (wine doesn’t provide dsetup.dll so this won’t apply)

Yeah a VM doesn’t always work as nice for older games

[randy-girard]

Is the wine32on64 source just the Wine source, compile specially? I would be interested in possible trying to add some more debugging to it to see if i can get a better idea of exactly what is failing, since its kind of hard to really determine from the logs I have.

[Gcenx]

It’s not standard upstream wine source but crossover based sources starting from crossover-wine-19 you can grab just the wine portion from my mirror https://github.com/Gcenx/winecx

To compile wine32on64 you’ll first need to compile the custom llvm/clang-8 you can get that source from the CodeWeavers source location (linked on my mirror)

You’ll also need to apply a required patch or it won’t compile, this patch is needed for any crossover-wine source.

If you want to skip dealing with setting up the environment plus the options you could use https://github.com/PhoenicisOrg/phoenicis-winebuild as it does support compiling external sources, you’ll just need to package the 10.13.SDK from XCode9 using https://github.com/tpoechtrager/osxcross#packaging-the-sdk

[randy-girard]

I just noticed something that reported out in my debugging. I am not sure if this is intended, or an accident, but it looks to be reporting your local environment (notice the first assertion failed line):

Assertion failed: (FALSE), function HEAP_GetPtr, file /Users/gcenx/Documents/GitHub/winecx/dlls/ntdll/heap.c, line 465.
11311.726:000c:003c:trace:seh:raise_exception code=80000101 flags=1 addr=0x7bca8ca5 ip=7bca8ca5 tid=003c
11311.726:000c:003c:trace:seh:raise_exception  eax=00000000 ebx=037d1000 ecx=020ee7a8 edx=00000000 esi=00000006 edi=020edf30
11311.726:000c:003c:trace:seh:raise_exception  ebp=020ee7d0 esp=020edf20 cs=1007 ds=100f es=100f fs=107f gs=0000 flags=00000246
11311.726:000c:003c:trace:seh:raise_exception  underlying 64-bit state:
11311.726:000c:003c:trace:seh:raise_exception    rip=00007fff6946f33a
11311.726:000c:003c:trace:seh:raise_exception    rax=0000000000000000 rbx=00007000037d1000 rcx=00000000020ee7a8 rdx=0000000000000000
11311.726:000c:003c:trace:seh:raise_exception    rsi=0000000000000006 rdi=0000000000004503 rbp=00000000020ee7d0 rsp=00000000020ee7a8
11311.726:000c:003c:trace:seh:raise_exception    r8=00000000000001d1  r9=cccccccccccccccd r10=00007000037d1000 r11=0000000000000246
11311.726:000c:003c:trace:seh:raise_exception    r12=0000000000004503 r13=00000000682040d0 r14=0000000000000006 r15=0000000000000016
11311.726:000c:003c:trace:seh:call_stack_handlers calling handler at 0x7bcae9d0 code=80000101 flags=1
11311.726:000c:003c:trace:seh:call_stack_handlers handler at 0x7bcae9d0 returned 2
11311.726:000c:003c:trace:seh:call_stack_handlers calling handler at 0x7bcd3ff0 code=80000101 flags=11
11311.726:000c:003c:trace:seh:call_stack_handlers handler at 0x7bcd3ff0 returned 1
11311.726:000c:003c:err:seh:raise_exception Unhandled exception code 80000101 flags 1 addr 0x7bca8ca5

[randy-girard]

Actually the more im looking into this, it sounds like maybe its a ELF to PE issue that isn't complete yet maybe?

[Gcenx]

Wine always does this it’s nothing to worry about, if something crashes it provides the file and line that related to said crash.

I can’t say for sure what the actual issue is without trying to run Project1999 myself on Mojave and Catalina to see if it’s an overall wine problem or just a wine32on64 issue

[randy-girard]

Ah ok. The last thing I noticed was that with the default DSETUP.dll, wine loads the game up and outputs some opengl/d3d lines to the debug. But with the P99 provided one, its just hangs, never outputing that. Its possible its something related to graphics maybe.

[Gcenx]

Ok the issue is due to the following

DSETUP.DLL is packed with anti-hax0r software called Themida

I can get the game to launch on Mojave without issue so it seems Themida doesn’t like how wine32on64 functions.

[randy-girard]

Yea, mojave is no issue from what i recall, but with my mac being catalina to begin with, apparently you can't downgrade. I have tried multiple ways and it just doesn't let you. I guess that is a step in a good direction to see if there is something further to do there perhaps.

[randy-girard]

Apparently Themida unpacks the app into memory and if that fails, the program wont work. Maybe its failing to do that for some reason.

[Gcenx]

If your system shipped with Catalina there is no downgrading unfortunately.

I did create a support ticket with CodeWeavers since about this discrepancy between wine > wine32on64 but I wouldn't expect anything too quickly.

Apparently Themida unpacks the app into memory and if that fails, the program wont work. Maybe its failing to do that for some reason.

If Themida expects a specific memory location it might be getting confused with wine32on64 layout as it runs everything within 64Bit memory mapping not 32Bit

[Gcenx]

It would have been more ideal if Project1999 provided a premodified exe that would avoid these issues

[randy-girard]

Yea, but I think there whole point is to protect the anti-cheating code.

[randy-girard]

I have opened a petition with them as well as a technical discussion to see if there is something they can do on their end as well.

[Gcenx]

I'd think they could provide a pre-modified game executable thats protected over modifying the game in memory

[randy-girard]

The problem is they didn't write the game, so I dont think they can do that. They rewrote a small dll that hooks itself in.

[Gcenx]

I’ve played on enough unofficial servers and the majority provide a pre-modified client exe to resolve the official version no dll injection, none of these games ever had there sources released.

Reading the linked thread I don’t see the server devs changing there stance, also considering how complex an issue this is as it runs fine in wine but not wine32on64 I can’t say how long it will take to receive a response from CodeWeavers let alone some manner to resolve this

[randy-girard]

Yea, I will probably have to let it go for now ,but I appreciate you taking the journey with me.

[Gcenx]

CodeWeavers Ticket #1276919

[randy-girard]

This issue appears to be gone on the newest Crossover 22 version that just came out. Any chance to update this to reflect that? Thanks

[Gcenx]

This issue appears to be gone on the newest Crossover 22 version that just came out.

That’s interesting

Any chance to update this to reflect that? Thanks

Eventually as this just landed along with sources (literally while I was heading to work)

There was a regression in the Apple Silicon resolution hack to allow lower screen resolutions to function in CX22 that won’t be resolved until CX22.0.1.

Ignoring the above rather major regression I’d need time to work on the required reverts and cherry picked fixes/hacks.

[randy-girard]

I was looking at the wine 7.7 updates and there was a bunch more PE updates, so perhaps that hit the code that the DSETUP.dll was using. I don't mind doing the build myself, but I assume its not super straightforward. I think I tried in the past and was not able to get it to work.

[Gcenx]

Perhaps or the related functions got working thunks.

Building from source isn’t too difficult now that there’s many guides based on my instructions, the best one to reference would be https://github.com/GabLeRoux/macos-crossover-wine-cloud-builder

Currently trying to test the CX22 based build via actions build but it’s hard to work on yml files from a mobile browser, hopefully there’s no issues with build_local.sh run I just stared.

[randy-girard]

I tried to run build_local.sh and ran into

undefined reference to `vkd3d_set_log_callback'

make: *** [dlls/wined3d/wined3d.dll] Error 2

[randy-girard]

I ended up doing --without-vulkan and it seems to get further

[Gcenx]

Yeah I’d seen that before heading to work, that will get resolved later

[Gcenx]

I ended up doing --without-vulkan and it seems to get further

That’s more a workaround than a real solution.

[randy-girard]

Yea, It didn't work anyway lol

[Gcenx]

Yea, It didn't work anyway lol

Makes sense, I’ll see what’s the cleaned way to handle this.