search

ptitSeb / box64

Box64 - Linux Userspace x86_64 Emulator with a twist, targeted at ARM64 Linux devices
https://box86.org
MIT License
3.84k stars 279 forks source link

winedevice.exe stuck on wine wineboot (Wine 8.21+) #1187

Closed theofficialgman closed 9 months ago

theofficialgman commented 10 months ago

tested on x86_64 with the same build and no issues.

winetricks corefonts
------------------------------------------------------
warning: You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
------------------------------------------------------
warning: You apppear to be using Wine's new wow64 mode. Note that this is EXPERIMENTAL and not yet fully supported. If reporting an issue, be sure to mention this.
------------------------------------------------------
Using winetricks 20240105-next - sha256sum: 73f475faf6c041a9b04e033d4db74b8cc5fae20ddc8229ab494f8f938f96e73f with wine-9.0-rc3 and WINEARCH=win64
Executing w_do_call corefonts
------------------------------------------------------
warning: You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
------------------------------------------------------
warning: You apppear to be using Wine's new wow64 mode. Note that this is EXPERIMENTAL and not yet fully supported. If reporting an issue, be sure to mention this.
------------------------------------------------------
Executing load_corefonts 
Executing w_do_call andale
------------------------------------------------------
warning: You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
------------------------------------------------------
warning: You apppear to be using Wine's new wow64 mode. Note that this is EXPERIMENTAL and not yet fully supported. If reporting an issue, be sure to mention this.
------------------------------------------------------
Executing load_andale 
Executing cabextract -q -d /home/gman/.wine/dosdevices/c:/windows/temp /home/gman/.cache/winetricks/corefonts/andale32.exe
------------------------------------------------------
warning: Running /usr/local/bin/wineserver -w. This will hang until all wine processes in prefix=/home/gman/.wine terminate
------------------------------------------------------
Dynarec for ARM64, with extension: ASIMD AES CRC32 PMULL SHA1 SHA2 PageSize:4096 Running on Cortex-A57 with 4 Cores
Params database has 46 entries
BOX64: Didn't detect 48bits of address space, considering it's 39bits
Counted 58 Env var
BOX64 LIB PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/
BOX64 BIN PATH: ./:bin/:/home/gman/.local/bin/:/home/gman/bin/:/usr/local/sbin/:/usr/local/bin/:/usr/sbin/:/usr/bin/:/sbin/:/bin/:/usr/games/:/usr/local/games/:/snap/bin/
Looking for /usr/local/bin/wineserver
argv[1]="-w"
Rename process to "wineserver"
Using native(wrapped) libdl.so.2
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libpthread.so.0
Using native(wrapped) libutil.so.1
Using native(wrapped) librt.so.1
Using native(wrapped) libbsd.so.0

hangs on box64 with this above output ^. fresh wine prefix used.

install instructions

version=9.0-rc3
wget https://github.com/Pi-Apps-Coders/files/releases/download/large-files/wine-${version}.tar.gz -O /tmp/wine-${version}.tar.gz
sudo tar -xvf /tmp/wine-${version}.tar.gz -C /opt
rm -f /tmp/wine-${version}.tar.gz
wget -O /tmp/winetricks "https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks"
sudo mv /tmp/winetricks /opt/wine-${version}/bin/winetricks
sudo chmod +x /opt/wine-${version}/bin/winetricks
#download Mono to universal location (to be installed automatically in all wine prefixes)
#according to https://wiki.winehq.org/Mono#Versions, use Mono 8.1.0 for Wine 8.11
#wine mono pacakge is called -x86 but contains both x86 and x86_64 binaries
sudo mkdir -p /opt/wine-${version}/share/wine/mono
wget -O "/tmp/wine-mono-8.1.0-x86.tar.xz" 'https://dl.winehq.org/wine/wine-mono/8.1.0/wine-mono-8.1.0-x86.tar.xz'
sudo tar -xvf "/tmp/wine-mono-8.1.0-x86.tar.xz" -C "/opt/wine-${version}/share/wine/mono"
rm -f "/tmp/wine-mono-8.1.0-x86.tar.xz"
#download Gecko to universal location (to be installed automatically in all wine prefixes)
#according to https://wiki.winehq.org/Gecko, use Gecko 2.47.4 for Wine 8.11
sudo mkdir -p /opt/wine-${version}/share/wine/gecko
wget -O "/tmp/wine-gecko-2.47.4-x86_64.tar.xz" 'https://dl.winehq.org/wine/wine-gecko/2.47.4/wine-gecko-2.47.4-x86_64.tar.xz'
sudo tar -xvf "/tmp/wine-gecko-2.47.4-x86_64.tar.xz"  -C "/opt/wine-${version}/share/wine/gecko"
rm -f "/tmp/wine-gecko-2.47.4-x86_64.tar.xz"

sudo ln -s /opt/wine-${version}/bin/winecfg /usr/local/bin/winecfg
sudo ln -s /opt/wine-${version}/bin/wineserver /usr/local/bin/wineserver
sudo ln -s /opt/wine-${version}/bin/wineboot /usr/local/bin/wineboot
sudo ln -s /opt/wine-${version}/bin/wine /usr/local/bin/wine
sudo ln -s /opt/wine-${version}/bin/winetricks /usr/local/bin/winetricks

#make them all executable
sudo chmod +x /usr/local/bin/winecfg /usr/local/bin/wineserver /usr/local/bin/wineboot /usr/local/bin/wine /usr/local/bin/winetricks
theofficialgman commented 10 months ago

the root of this issue is that wine wineboot leaves winedevice.exe and wineserver running when run with box64. this issue does not occur on x86_64

ptitSeb commented 10 months ago

so on the latest wow64 build of wine, winedevice.exe is stuck?

theofficialgman commented 10 months ago

so on the latest wow64 build of wine, winedevice.exe is stuck?

yes it appears so

I checked wine 8.19 and 8.20 and do not have stuck winedevice.exe

DocMAX commented 10 months ago

what are the next steps?

ptitSeb commented 10 months ago

Not sure I have the same bahviour on my side. I get 

174:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0174:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
017c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
017c:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."

On my side all the time. There are many .exe process stuck also, not only winedevice.exe after I try to run wincfg

I know that Wow64 build from kron4ek CI doesn't have the same issue. Did something changed on the the build process of wine?

ptitSeb commented 10 months ago

I feel like this part (the isolated line) is not normal:

0054:trace:win:WIN_CreateWindowEx (null) #8001 ex=00000000 style=86000000 0,0 0x0 parent=0000000000000000 menu=0000000000000000 inst=0000000000000000 params=00007FFFFE2FF0C0
0054:trace:win:dump_window_styles style: WS_POPUP WS_CLIPSIBLINGS WS_CLIPCHILDREN
0054:trace:win:dump_window_styles exstyle:
0054:trace:win:WIN_CreateWindowEx (null) L"Message" ex=00000000 style=86000000 0,0 100x100 parent=0000000000000000 menu=0000000000000000 inst=0000000000000000 params=0000000000000000
0054:trace:win:dump_window_styles style: WS_POPUP WS_CLIPSIBLINGS WS_CLIPCHILDREN
0054:trace:win:dump_window_styles exstyle:
0054:trace:win:apply_window_pos win 0x10024 surface (nil) -> 0x7fff023354a0
0054:trace:win:NtUserCreateWindowEx hwnd 0x10024 cs 0,0 100x100 (0,0)-(100,100)
0054:trace:win:apply_window_pos win 0x10024 surface 0x7fff023354a0 -> 0x7fff023354a0
0054:trace:win:NtUserCreateWindowEx created window 0x10024

0054:trace:win:set_window_long 0xc0000005 -4 4043a0 W

0054:trace:win:NtUserSetWindowPos hwnd 0xc0000005, after (nil), 0,0 (2560x1440), flags 00000040
0054:trace:win:dump_winpos_flags flags: SWP_SHOWWINDOW
0054:trace:win:NtUserRedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN
0054:trace:win:NtUserClipCursor Clipping to (null)
00ac:trace:win:alloc_winproc_ptr allocated 0xffff000e for W 0x4022a0 (15/4096 used)
0054:trace:win:alloc_winproc_ptr allocated 0xffff000f for W 0x401210 (16/4096 used)
00ac:trace:win:WIN_CreateWindowEx (null) L"__wine_clipboard_manager" ex=00000000 style=00000000 0,0 0x0 parent=FFFFFFFFFFFFFFFD menu=0000000000000000 inst=0000000000000000 params=0000000000000000

the hwnd looks like a SEGFAULT error code. But I don't see any segfault or error or anything. Just the nodriver out of nowhere for now :(

ptitSeb commented 10 months ago

This

0058:trace:win:invalidate_dce 0x30030 parent 0x10020 (0,0)-(166,52) ((0,0)-(0,0))
0058:trace:win:apply_window_pos win 0x30030 surface (nil) -> (nil)
0058:trace:win:NtUserCreateWindowEx hwnd 0x30030 cs 0,0 166x52 (0,0)-(166,52)
0058:trace:win:set_window_text L""

0058:warn:win:create_window_handle error 6 creating window

0058:trace:win:NtUserCreateWindowEx register IME window for 0x30030
0058:trace:win:invalidate_dce 0x30030 parent 0x10020 (0,0)-(166,52) ((0,0)-(166,52))
0058:trace:win:apply_window_pos win 0x30030 surface (nil) -> (nil)
0058:trace:win:NtUserCreateWindowEx created window 0x30030
0058:trace:win:show_window hwnd=0x30030, cmd=0, was_visible 0
0058:trace:win:alloc_winproc_ptr allocated 0xffff0012 for W 0x7a91b940 (19/4096 used)
0058:trace:win:WIN_CreateWindowEx (null) L"WineDdeEventClass" ex=00000000 style=80000000 0,0 0x0 parent=0000000000000000 menu=0000000000000000 inst=0000000000000000 params=0000000000000000
0058:trace:win:dump_window_styles style: WS_POPUP
0058:trace:win:dump_window_styles exstyle:

Also looks suspicious. But again, no actual error or hint about were this could go wrong.

ptitSeb commented 10 months ago

The windows creation process does

015c:trace:win:WIN_CreateWindowEx L"Wine Explorer" L"ExplorerWClass" ex=00000000 style=00cf0000 -2147483648,-2147483648 640x480 parent=0000000000000000 menu=0000000000000000 inst=0000000000400000 params=0000000000000000
015c:trace:win:dump_window_styles style: WS_CAPTION WS_SYSMENU WS_THICKFRAME WS_MINIMIZEBOX WS_MAXIMIZEBOX
015c:trace:win:dump_window_styles exstyle:
015c:trace:win:get_min_max_info 2568 1408 / -4 -4 / 2572 1452 / 119 34
015c:trace:win:create_offscreen_window_surface visible_rect (0,0)-(640,480), surface 0x7ffffe0ff8b8.
015c:trace:win:create_offscreen_window_surface created window surface 0xffffb43d3010
015c:trace:win:invalidate_dce 0x10072 parent 0x30058 (0,0)-(640,480) ((0,0)-(0,0))
015c:trace:win:invalidate_dce 0x4010044: hwnd 0x30058 dcx 00000013 Cache 
015c:trace:win:apply_window_pos win 0x10072 surface (nil) -> 0xffffb43d3010
015c:trace:win:NtUserCreateWindowEx hwnd 0x10072 cs 0,0 640x480 (0,0)-(640,480)
015c:trace:win:set_window_text L"Wine Explorer"
015c:trace:win:create_offscreen_window_surface visible_rect (0,0)-(1,1), surface 0x7ffffe0ff688.
015c:trace:win:create_offscreen_window_surface created window surface 0x4f8d2f10
015c:trace:win:invalidate_dce 0x10078 parent 0x30058 (0,0)-(1,1) ((0,0)-(0,0))
015c:trace:win:invalidate_dce 0x4010044: hwnd 0x30058 dcx 00000013 Cache 
015c:trace:win:apply_window_pos win 0x10078 surface (nil) -> 0x4f8d2f10
015c:trace:win:NtUserCreateWindowEx hwnd 0x10078 cs 0,0 1x1 (0,0)-(1,1)
015c:trace:win:set_window_text L"Default IME"
015c:trace:win:create_offscreen_window_surface visible_rect (0,0)-(1,1), surface 0x7ffffe0ff688.
015c:trace:win:invalidate_dce 0x10078 parent 0x30058 (0,0)-(1,1) ((0,0)-(1,1))
015c:trace:win:invalidate_dce 0x4010044: hwnd 0x30058 dcx 00000013 Cache 
015c:trace:win:apply_window_pos win 0x10078 surface 0x4f8d2f10 -> 0x4f8d2f10
015c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
015c:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
015c:trace:win:destroy_window 0x10078
015c:trace:win:free_window_handle

But again, no clue on to why it errors out.

pg9182 commented 9 months ago

the root of this issue is that wine wineboot leaves winedevice.exe and wineserver running when run with box64. this issue does not occur on x86_64

But again, no clue on to why it errors out.

I think this has something to do with explorer.exe, and not winedevice.exe (or there's two somewhat-related issues).

I've been working on the new cross-platform docker image for Northstar (the Titanfall 2 custom server mod) (#210), and I've actually got a fully-working prototype using Wine 9.0-rc3 and 9b23c3272bd6e0cffef50e811627301e0b64ea42 (thanks @ptitSeb; performance is actually really good). The Wine build is the official WineHQ one, but slimmed down and patched (basically all GUI-related stuff is removed, 32-bit and WoW stuff is removed, explorer.exe is patched to load nulldrv by default -- which basically just returns a dummy value for every win32u call, and wine.inf is patched to remove pretty much every service other than winedevice -- which is needed for wineboot to not complain) (I was very through and careful with the slimming -- wineboot doesn't log errors about anything other than wow64 and ole). The Box64 configuration is here. For easier debugging, the entire /opt/northstar-runtime folder can be extracted from the container and run on most recent glibc-based hosts (only tested on Debian Bookworm though).

This is relevant since I've noticed a few things while working on this:

P.S. To run northstar-runtime (as of 584141a901f2afa775a70b91d5c3e0c8d2ae4eda; it's still in development, so things could change) (if you want to play on the server, port-forward the udp port -- the external port must be identical, then configure the server name in R2Northstar/mods/Northstar.CustomServers/mod/cfg/autoexec_ns_server.cfg) (you can run the same command on arm64 and amd64) (BOX64_* and WINEDEBUG env vars are passed through by nswrap -- everything else is removed or overridden):

mkdir titanfall
cd titanfall
wget https://gist.github.com/pg9182/9a962adbfc27e93237cd14e4523c9da8/raw/c21c0894a7298dd285bcce5277407be478a9e97e/nsfetch.sh
chmod +x nsfetch.sh
./nsfetch.sh # this downloads 2.5GB of files
wget https://github.com/R2Northstar/Northstar/releases/download/v1.21.4/Northstar.release.v1.21.4.zip
unzip Northstar.release.v1.21.4.zip
docker pull ghcr.io/pg9182/northstar-runtime

# option 1: run the docker container
# note: you can pass box64 env vars with the docker -e flag
# note: you can override the box64 binary by bind-mounting it with something like -v (I have two minor [patches](https://github.com/pg9182/NorthstarDocker/blob/584141a901f2afa775a70b91d5c3e0c8d2ae4eda/runtime/Dockerfile#L306-L311) in my build, but they aren't critical)
docker run --rm -it -v $PWD:/mnt --network host ghcr.io/pg9182/northstar-runtime -dedicated +setplaylist aitdm +launchplaylist aitdm +port 37015

# option 2: get a shell in the container, then run nswrap manually (potentially installing additional tools in it)
docker run --rm -it -v $PWD:/mnt --network host --entrypoint /bin/bash ghcr.io/pg9182/northstar-runtime
/opt/northstar-runtime/bin/nswrap -dedicated +setplaylist aitdm +launchplaylist aitdm +port 37015

# option 3: extract it and run it externally
# note: to see the thing about it not exiting, press ctrl+c twice (that SIGTERMS the main wine process) (NOT 3 times -- that SIGKILLS the main wine process, which is inherently not a clean exit) at some point after the MountVPK logs, and look at the process list -- it'll timeout while waiting for wine to completely exit, and it'll leave behind wineserver, explorer.exe, services.exe, and winedevice.exe
docker run --rm -v $PWD:/mnt --network host --entrypoint /usr/bin/tar ghcr.io/pg9182/northstar-runtime cf - -C /opt northstar-runtime | tar xvf - # this might appear to hang at the end -- it's not stuck, it just takes a little bit of time
./northstar-runtime/bin/nswrap -dedicated +setplaylist aitdm +launchplaylist aitdm +port 37015

Regarding my slimmed/patched wine build for the northstar dedicated server, the only absolutely required patches are as follows. The rest of the removals are done to minimize the size of the docker image, and to reduce the number of extraneous processes for simplicity.

pg9182 commented 9 months ago

Regarding the createwindow errors, they shouldn't prevent wineboot from working correctly if that's all there is (proof: init a wineprefix on x64, but unset DISPLAY and WAYLAND_DISPLAY, then successfully run cmd or another console application to prove the prefix works correctly). If you force the use of nulldrv like I did for the Northstar dedicated server (which has to return success from CreateWindow and have a working window loop, but doesn't actually show anything we care about on the window), you can sidestep those errors entirely (albeit without a GUI).

ptitSeb commented 9 months ago

Ok, thanks I'll look into this also, to see if I can isolate what's going wrong

ptitSeb commented 9 months ago

Ok, I reproduce the explorer.exe not quitting properly (using option 3). Unfortunatly, I see no error or anything suspicious. I just doesn't work properly for no apparent reason :( So I still don't know were to look for an issue.

ptitSeb commented 9 months ago

Doing some regression testing with pi-apps wine-wow64 build, it seems the issue appeared with wine-8.21. On wine-8.20, everything seems to work fine for me. With 8.21 and later, no more explorer.exe or window openning (using a fresh prefix or not).

theofficialgman commented 9 months ago

Doing some regression testing with pi-apps wine-wow64 build, it seems the issue appeared with wine-8.21. On wine-8.20, everything seems to work fine for me. With 8.21 and later, no more explorer.exe or window openning (using a fresh prefix or not).

Yeah that was my experience as well. Sorry should have posted that I originally noticed the issue in wine-8.21 and not lower versions. As said previously, I don't see any problems when using these builds on an x86_64 PC.

Keep this thread updated if you find any new information but I understand if you don't find anything and let it sit for a while, that is ok too.

MastaG commented 9 months ago

In this fixed by https://github.com/ptitSeb/box64/commit/328d5c6275b69edf336eac595fe2e41ab8410a65 ? Because he mentioned testing wine explorer.exe

theofficialgman commented 9 months ago

In this fixed by 328d5c6 ? Because he mentioned testing wine explorer.exe

Considering that's a one line commit on the risv5 dyarec, no it's not fixed.

MastaG commented 9 months ago

https://bugs.winehq.org/show_bug.cgi?id=56130 Perhaps it's fixed now in Wine 9.0 rc5?

alexsch01 commented 9 months ago

Just tried wine-9.0 with box64....explorer failed to launch so I believe this issue is still present

DocMAX commented 9 months ago

@ptitSeb could you write down the recommended wine version to use for box64? i can only use the wow64 version so does wow64 work at all?

ptitSeb commented 9 months ago

@ptitSeb could you write down the recommended wine version to use for box64? i can only use the wow64 version so does wow64 work at all?

wine 8.20 seems to be the last working version. I'm working on this issue, but it will take time to fix as I still have no idea what is going wrong there.

DocMAX commented 9 months ago

yeah, 8.20 is also my finding.

MastaG commented 9 months ago

I hope you'll be able to sort this out because they restored compatibility with termux now in 9.0 rc3. This means that after this bug gets fixed in box64, all projects such as Box64Droid, Winlator etc, should be able to use Wine 9.0 (or the GE fork).

theofficialgman commented 9 months ago

Incase someone wants to go through the diff between wine 8.21 and wine 8.20 to see if the changes can give any suggestion for where to look for the issue https://gitlab.winehq.org/wine/wine/-/compare/wine-8.20...wine-8.21?from_project_id=5&straight=false

ptitSeb commented 9 months ago

Incase someone wants to go through the diff between wine 8.21 and wine 8.20 to see if the changes can give any suggestion for where to look for the issue https://gitlab.winehq.org/wine/wine/-/compare/wine-8.20...wine-8.21?from_project_id=5&straight=false

Good idea, but the diff is partial, not all comits get listed and I don't see where I get another page of commits.

ptitSeb commented 9 months ago

@theofficialgman I tried to build wine-8.21 to see if I can bisect the issue localy. But my local 8.21 build (with Wow64 of course) just works on my side. What configure parameter are you using for the Wow64 built?

theofficialgman commented 9 months ago

@theofficialgman I tried to build wine-8.21 to see if I can bisect the issue localy. But my local 8.21 build (with Wow64 of course) just works on my side. What configure parameter are you using for the Wow64 built?

same instructions as always. bump version variable and update url as necessary https://github.com/Pi-Apps-Coders/files/blob/main/CompileCommands/Apps/Wine%20(x64).md

ptitSeb commented 9 months ago

@theofficialgman I tried to build wine-8.21 to see if I can bisect the issue localy. But my local 8.21 build (with Wow64 of course) just works on my side. What configure parameter are you using for the Wow64 built?

same instructions as always. bump version variable and update url as necessary https://github.com/Pi-Apps-Coders/files/blob/main/CompileCommands/Apps/Wine%20(x64).md

No, I don't want to install the pi-apps package, I want to build wine the same way pi-apps does, because my local build works fine. What configure command line is used to build wine. I used CFLAGS="-march=core2 -O2" ../configure --enable-archs=i386,x86_64 (also with a custom prefix) on my side.

theofficialgman commented 9 months ago

same instructions as always. bump version variable and update url as necessary

No, I don't want to install the pi-apps package, I want to build wine the same way pi-apps does,

Yeah I know. Click the link. I sent you the buildscript. We have all our buildscripts public for binaries distributed in pi-apps.

ptitSeb commented 9 months ago

same instructions as always. bump version variable and update url as necessary

No, I don't want to install the pi-apps package, I want to build wine the same way pi-apps does,

Yeah I know. Click the link. I sent you the buildscript. We have all our buildscripts public for binaries distributed in pi-apps.

Oh, sorry, I didn't noticed it was the build script.

Looking at it, it's mostly the same command I'm using on side. I just use a specific CFLAGS. I'm build on a debian instance with gcc-13. On what it is built on pi-apps side? I don't understand why I don't have the same result. I'll build again without the CFLAGS....

theofficialgman commented 9 months ago

On what it is built on pi-apps side? I don't understand why I don't have the same result. I'll build again without the CFLAGS....

same repo, root folder has the ubuntu bionic chroot instructions https://github.com/Pi-Apps-Coders/files/blob/main/CompileCommands/README.md

in this case it is an amd64 ubuntu bionic chroot.

ptitSeb commented 9 months ago

Ok, Without the CFLAGS, I reproduced the issue with my 8.21 build! Now, I'll build 8.20 and see if it works. Then I can start the bisect :)

ptitSeb commented 9 months ago

So, bisect done. The commit is df181df8ee5930f19327324593ecd54b3cc7fc26, which is "ntdll: Add a syscall_cfa member to the x86_64 syscall frame." So prbably box64 stack setup during signal is not 100% correct.

ptitSeb commented 9 months ago

Ok, I think I found root cause of the issue. The stack pointer was mis-aligned in a pthread_once callback and some value got overwriten (mix with RSP/RBP relative access and eroneous rounded RSP becauseof the misalignement).

It should work now with latest box64.

theofficialgman commented 9 months ago

currently on wine 9.0, winedevice.exe is stuck when running winetricks vcrun2008

wine cache was cleared at the start. the following get run in a loop and I am stuck when I get to vcrun2008

for i in mfc42 vcrun6 vcrun2003 fontfix corefonts gdiplus msxml3 vcrun2005sp1 vcrun2008 ;do
  echo
  status "Installing \$i with winetricks..."
  winetricks \$i
done
theofficialgman commented 9 months ago

tried again, cleared cache, exact same script and it did not hang this time.... so I guess just unstable as usual