[BUG]: Wand version >12.0.1 hangs on start, while Wemod <= 11.6.0 works in same wine prefix

[pickworthi]

Describe the problem

I am logging this issue here, but it is not really a wemod-launcher issue.
I thought that logging the issue here will at least provide a place where people who might be able to fix the issue can communicate. (Wemod forum deletes all posts on Linux, and Reddit is really hit or miss).

If you guys don't think this is appropriate I understand.

The issue is as in the title. Details below.
I am more than happy to provide more information or try out any suggestions - I'm retired so time is not an issue for me (assuming I stay alive of course :-) )

Steps to reproduce

1. Create a new wineprefix using Steam client (any installed game will do). Select a recent compatibility tool (e.g. Proton-9)
2. In the created wineprefix, apply the winetricks commands dotnet48 and dxvk2071 (latter not really needed, but provides some extra tracing)
3. Assuming you have access to a version 11.6.0 Wemod installer, run the installer exe in the prefix. This should work (in that a login screen is displayed)
4. Run the Wand installer exe in the prefix. This hangs displaying a black frame.

Expected behavior

In a perfect world, Wand should work as Wemod pre 12.0.1 does, and display the login screen.

Logs or Terminal Output

This is the error message Wand displays if run from the command line:

Error sending from webFrameMain: Error: Render frame was disposed before WebFrameMain could be accessed at s.send (node:electron/js2c/browser_init:2:92689) at _.send (node:electron/js2c/browser_init:2:76113) at C:\users\ipic\AppData\Local\Wand\app-12.0.3\resources\app.asar\index.js:1:46968 at setState (C:\users\ipic\AppData\Local\Wand\app-12.0.3\resources\app.asar\index.js:1:33473) at C:\users\ipic\AppData\Local\Wand\app-12.0.3\resources\app.asar\index.js:1:34171 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async WebContents.<anonymous> (node:electron/js2c/browser_init:2:87023)

Screenshots

No response

System Information

My system is:

• Gentoo
• Kernel 6.17.8
• AMD Radeon RX 7800 XT
• Mesa 25.2.7

Additional context

I have time to try things out if people suggest things that might solve the issue.
I can test in any Wine prefix (native, Proton or GE-Proton) - if someone wants a specific one tested just let me know.

[pickworthi]

Two things:

1. My step 2 above should have included instruction to de-reference (as in remove symlinks) the prefix.
2. I have hosted a copy of the 11.6.0 installer here: https://www.pickworth.me.uk/WeMod-11.6.0.exe

No further progress yet :-(

[pickworthi]

Using WINEDEBUG=+loaddll for tracing, I have found what looks like a significant difference between Wemod 11.6.0 and wand 12.2.0.

Directly before the error message above is produced, Wand makes this call:

022c:fixme:crypt:CertAddCertificateLinkToStore` (00000000198B1D20, 00000000198A6EE8, 00000004, 0000000000000000): semi-stub

Directly after this call, Wand load diasymreader.dll, which is a .NET debugging symbol reader (according to info I found), which I think points to a failure being recognised. Also, the next trace entries are .NET modules being unloaded, followed by the error message.

Wemod v 11.6.0 does not at any point call CertAddCertificateLinkToStore in a loaddll trace of it running, which leads me to think that this is the culprit.

Given the name of the call, it looks like the adding of a certificate to the cert store is being attempted. If that store is /etc/ssl/certs/ca-certificates.crt it is bound to fail - the file belongs to root, and is only writable by root.

However, this is an area I am not familiar with. Hopefully someone else is.

I have hosted the two trace logs here:
https://www.pickworth.me.uk/wemod-loaddll-trace.txt
https://www.pickworth.me.uk/wand-loaddll-trace.txt

[pickworthi]

Following some Google search type research, I found that CertAddCertificateLinkToStore is part of the crypt32 package.

winetricks offers a crypt32.dll so I installed that.

This resulted in Wand producing another error message:

Error occurred in handler for 'ACTION_CHECK_FOR_UPDATE': Error: Command failed: 4294967295 System.AggregateException: One or more errors occurred. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

I think that I have now established that the substantial change between version 11.6.0 and 12.0.1 is the introduction of an automatic update process. It seems that Wand is failing under wine due to this process failing to do what it is expected to do.

The update process appears to be the squirrel.exe program, which is new.
[EDIT] This is not correct - squirrel.exe was in previous versions. However, as the traces show, it did not use cryptography calls - so I still hold that this is the significant change.

[pickworthi]

A bit more digging - and I don't think squirrel.exe is the root issue, based on this part of the 'ACTION_CHECK_FOR_UPDATE' error message:
at Squirrel.Update.Program.<CheckForUpdate>d__8.MoveNext() <--- at ChildProcess.<anonymous> (C:\users\ipic\AppData\Local\Wand\app-12.2.1\resources\app.asar\index.js:1:35421)
It looks to me like squirrel.exe fails because it is asked to validate a SSL/TLS and that validation fails producing the error message above.

I think this establishes that Version 12 introduced a cryptographic check on the executable being used. A trace of pre-version 12 shows no such checking. Looks to me like revenue protection measures - since github has plenty of 'get wemod pro for free' type repositories. Fair enough - just need to figure out how to make this work as intended using wine.

[pickworthi]

A bit more digging, and the surrounding messages when the SSL/TLS lookup fails look like this:

03d4:fixme:secur32:get_cipher_algid unknown algorithm 23
03d4:fixme:secur32:get_mac_algid unknown algorithm 200, cipher 23

Some searching leads to this post: https://forum.winehq.org/viewtopic.php?t=35667

Outlook is not good, if that represents the current state of play.