box86: .NET 3.5sp1 crashes on install

box86 2375d707, wine-devel=5.18~buster, latest winetricks (patched for box86) All components install correctly on x86 Linux (Debian 10, VMWare) with same version of wine.

Overview

I’d like to get dotnet35sp1 to install so that Winlink will run more stably (RMS Express opens with mono, but doesn’t function correctly since it doesn’t allow us to open modems through the RMS Express program).

I get a crash here in XPSEPSC’s update.exe (contained within dotnet30’s installer) that I think is the main problem – see below for more info:

0818:fixme:setupapi:pSetupGetGlobalFlags stub
13196|SIGSEGV @0x7c8a8d00 (???) (x86pc=0x1004cf0/???:"???"), for accessing (nil) (code=1), db=0x46f16a0(0x1004cf0/???)
13196|SIGSEGV @0x7c467c00 (???) (x86pc=0x1005313/???:"???"), for accessing (nil) (code=1), db=0x46249d8(0x1005313/???)
0818:fixme:wintrust:WinVerifyTrust unimplemented for 4
0818:fixme:wintrust:SOFTPUB_VerifyImageHash Cannot verify hash for pszObjId=(null)
13196|Double SIGSEGV!

.NET 3.5 SP1 depends on .NET 3.0 (which crashes)

dotnet35sp1 installer contains all previous dotnet installers and runs them before installing itself. Therefore, we can either ask winetricks to install dotnet35sp1, or we can also just install all previous dotnets individually (to make debugging easier).

So far, I’ve been able to get dotnet20 and dotnet20sp2 to install with box86 2375d707 with dynarec turned off. However, dotnet30 installer seems to crash.

I piped the output of BOX86_DYNAREC=0 winetricks dotnet30 >> log.file 2>&1 to a logfile and pasted the whole log of the box86 dotnet30 install and crash here if you want to see it - though this log doesn’t show the reason for the crash - just shows wine errors and an eventual SIGSEGV. Here is a log of the same install on x86 Linux, which completes successfully. On both Pi and on x86 Linux, I installed a fresh wineprefix without mono, then ran winetricks dotnet20 before I ran winetricks dotnet30.

.Net 3.0’s crash is probably caused by XPSEPSC update.exe crashing

I think the entire crash might be traced back to a problem with XPSEPSC’s update.exe (“XML Paper Specification Shared Components Pack 1.0 Installation Wizard” to update Windows XP components). This exe is nested inside several installers, but gets run during dotnet30 install (and dotnet30 install gets run during dotnet35sp1 install): [dotnetfx3.exe > dotnetfx3_extracted/wcu/XPS/XPSEPSC-x86-en-US.exe > XPSEPSC-x86-en-US_extracted/update/update.exe] If you want to get to that update.exe to play with it, you can extract these exe files using 7zip: 7z x ___.exe -o"extracted_dir"

First I had to run winetricks winxp (I learned from x86 Linux that update.exe needs Windows to be “winxp,”).

Running this update.exe with box86 (with or without dynarec) crashes with:

0818:fixme:setupapi:pSetupGetGlobalFlags stub
13196|SIGSEGV @0x7c8a8d00 (???) (x86pc=0x1004cf0/???:"???"), for accessing (nil) (code=1), db=0x46f16a0(0x1004cf0/???)
13196|SIGSEGV @0x7c467c00 (???) (x86pc=0x1005313/???:"???"), for accessing (nil) (code=1), db=0x46249d8(0x1005313/???)
0818:fixme:wintrust:WinVerifyTrust unimplemented for 4
0818:fixme:wintrust:SOFTPUB_VerifyImageHash Cannot verify hash for pszObjId=(null)
13196|Double SIGSEGV!

(Installer window pops up, but then crashes on this SIGSEGV - this crash also happens when I try to run this installer with the Windows /q quiet install flag).

On x86 Linux (if we do a fresh wineprefix, run winetricks dotnet20, then run wine update.exe on its own):

pi@debian:~/.cache/winetricks/dotnet30/extracted/wcu/XPS/out/update$ wine update.exe
0050:err:ole:start_rpcss Failed to start RpcSs service
00c4:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
0024:fixme:setupapi:pSetupGetGlobalFlags stub
0024:fixme:wintrust:WinVerifyTrust unimplemented for 4
0024:fixme:wintrust:SOFTPUB_VerifyImageHash Cannot verify hash for pszObjId=(null)
0024:err:ole:com_get_class_object class {acadf079-cbcd-4032-83f2-fa47c4db096f} not registered
0024:err:ole:com_get_class_object no class object {acadf079-cbcd-4032-83f2-fa47c4db096f} could be created for context 0x1

(Installer window pops up, waits for me to press “Next”, then goes on to install stuff)

It’s kind of funny, ExaGear had the same problem with this exact same update.exe , which I believe was the reason I couldn’t install dotnet35sp1 on ExaGear either.

Why I think update.exe is the problem

If we go to ~/.cache/winetricks/dotnet30/ and run wine dotnetfx3.exe (dotnet30 installer) we see DecryptFileA ("c:\\6504e39d706cc26fa29f1f78b383\\", where dotnetfx3.exe successfully extracts its contents to the temporary directory ~/.wine/drive_c/6504e39d706cc26fa29f1f78b383/

Then we see this and the dotnet30 Windows installer GUI says installation failed:

0168:fixme:advapi:DecryptFileA ("y:\\c82308bf6d53948e57\\", 00000000): stub
Box86 with Dynarec v0.1.3 2375d707 built on Oct 11 2020 13:13:32
0174:fixme:setupapi:pSetupGetGlobalFlags stub
7681|SIGSEGV @0x2856134 (???) (x86pc=(nil)/???:"???"), for accessing (nil) (code=1), db=(nil)((nil)/???)
7681|Double SIGSEGV!

The DecryptFileA ("y:\\c82308bf6d53948e57\\", 00000000): stub I’m pretty sure is where an .msi or .exe (contained within ~/.wine/drive_c/6504e39d706cc26fa29f1f78b383/) attempts to extract its contents into a temporary directory within our wineprefix.

After this failure, the installer’s own Windows crash log reports:

[10/11/20,20:19:33] setup.exe: [2] ISetupComponent::Pre/Post/Install() failed in ISetupManager::InternalInstallManager() with HRESULT -2147023293.
[10/12/20,06:33:03] setup.exe: [2] ISetupComponent::Pre/Post/Install() failed in ISetupManager::InternalInstallManager() with HRESULT -2147023293.
[10/12/20,06:34:12] WapUI: [2] DepCheck indicates XPSEPSC x86 Installer is not installed.
[10/12/20,06:39:52] setup.exe: [2] ISetupComponent::Pre/Post/Install() failed in ISetupManager::InternalInstallManager() with HRESULT -2147023293.
[10/12/20,06:40:53] WapUI: [2] DepCheck indicates XPSEPSC x86 Installer is not installed.

We can extract dotnetfx3.exe’s contents with pi@raspberrypi:~/.cache/winetricks/dotnet30 $ 7z x dotnetfx3.exe -o"unzipped" && cd unzipped And run the XPSEPSC install ourselves: cd ~/.cache/winetricks/dotnet30/unzipped/wcu/XPS && wine XPSEPSC-x86-en-US.exe to find that the XPSEPSC installer crashes here with Box86 (with or without dynarec, also trying a /q windos flag to run the installer quietly doesn’t help):

pi@raspberrypi:~/.cache/winetricks/dotnet30/unzipped/wcu/XPS $ wine XPSEPSC-x86-en-US.exe 
Box86 with Dynarec v0.1.3 2375d707 built on Oct 11 2020 13:13:32
Box86 with Dynarec v0.1.3 2375d707 built on Oct 11 2020 13:13:32
Box86 with Dynarec v0.1.3 2375d707 built on Oct 11 2020 13:13:32
0778:fixme:clusapi:GetNodeClusterState ((null),1020ECC4) stub!
0778:fixme:advapi:DecryptFileA ("c:\\1a42330abefda3ee2c54ec\\", 00000000): stub
078c:fixme:setupapi:pSetupGetGlobalFlags stub
078c:fixme:wintrust:WinVerifyTrust unimplemented for 4
078c:fixme:wintrust:SOFTPUB_VerifyImageHash Cannot verify hash for pszObjId=(null)

If I CTRL-C in the terminal right after fixme:advapi:DecryptFileA runs, then I can navigate to the ~/.wine/drive_c/1a42330abefda3ee2c54ec temporary folder where the contents are extracted and play with those files. It’s here where I track the error to

pi@raspberrypi:~/.wine/drive_c/1a42330abefda3ee2c54ec/update $ wine update.exe 
Box86 with Dynarec v0.1.3 2375d707 built on Oct 11 2020 13:13:32
Box86 with Dynarec v0.1.3 2375d707 built on Oct 11 2020 13:13:32
Box86 with Dynarec v0.1.3 2375d707 built on Oct 11 2020 13:13:32
0818:fixme:setupapi:pSetupGetGlobalFlags stub
13196|SIGSEGV @0x7c8a8d00 (???) (x86pc=0x1004cf0/???:"???"), for accessing (nil) (code=1), db=0x46f16a0(0x1004cf0/???)
13196|SIGSEGV @0x7c467c00 (???) (x86pc=0x1005313/???:"???"), for accessing (nil) (code=1), db=0x46249d8(0x1005313/???)
0818:fixme:wintrust:WinVerifyTrust unimplemented for 4
0818:fixme:wintrust:SOFTPUB_VerifyImageHash Cannot verify hash for pszObjId=(null)
13196|Double SIGSEGV!
Segmentation fault

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 74 (72 by maintainers)

Commits related to this issue

Most upvoted comments

I have improve the signal handler again. Analysing that “update.exe”, I realised SEGFAULT are a normal process on windows app: that’s how Exception are generated and trapped. So I modified Signal Handler to allow a same signal multiple time from the same address if there is a signal handler. It seems to go farther, but there are some other (not so normal I think) exception later… To be continued…

The add of syscall 318? That’s really odd! I’ll check that later.