[Bug 54317] New: Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

Bug ID: 54317
           Summary: Change to exec_wineloader made wine not start at all
           Product: Wine
           Version: 8.0-rc4
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Attempting to start wine with a pre-existing prefix results in a failure to
load ntdll / kernel32. With messages like

"wine: could not load kernel32.dll, status c0000135"

and

002c:err:module:load_wow64_ntdll failed to load
L"\??\C:\windows\system32\ntdll.dll" error 4000000e
wine: Unhandled page fault on execute access to 00000000 at address 00000000
(thread 002c), starting debugger...

being printed in the console.

Wine then attempts to start winedbg only to get stuck in a forkbomb. Where
winedbg won't start, triggering an exception, which will cause another attempt
to start winedbg. At a rate of about 4-5 attempts a second. Attempting to
ctrl-c it doesn't work, and requires manually terminating all of wine's
processes. (Of which are numerous as wine will also attempt to start
conhost.exe for each winedbg it attempts to load. None of which will terminate
on their own.)

Attempting to start wine with a fresh prefix results in an incomplete prefix
directory. (Only the dosdevices / windows directories, and registry hives are
present in the prefix. Of those windows is empty save for the syswow64 and
system32 directories of which both are completely empty.) Attempting to start
that prefix again causes the same winedbg behavior as above.

Performing a bisect revealed:

$ git bisect bad
d45de318748639cfd1e80a976b39f5e19213990f is the first bad commit
commit d45de318748639cfd1e80a976b39f5e19213990f
Author: Alexandre Julliard 
Date:   Tue Nov 22 12:08:19 2022 +0100

ntdll: Always set WINELOADER variable to the current loader name.

dlls/ntdll/unix/env.c    |  3 +++
 dlls/ntdll/unix/loader.c | 48 +++++++++++++++++++++---------------------------
 2 files changed, 24 insertions(+), 27 deletions(-)

Reverting d45de318748639cfd1e80a976b39f5e19213990f fixed the issue on my
system.

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

Patrick Hibbs  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
    Regression SHA1|                            |d45de318748639cfd1e80a976b3
                   |                            |9f5e19213990f

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

--- Comment #1 from Alexandre Julliard  ---
Is there anything peculiar about your setup? How are you building and running
Wine?

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

--- Comment #2 from Patrick Hibbs  ---
(In reply to Alexandre Julliard from comment #1)
> Is there anything peculiar about your setup? How are you building and
> running Wine?

I build wine as per the Shared WoW64 section of the wiki. I don't need to use a
chroot nor container, but I do wind up building wine three times to get a
functional build. (wine64 -> winetools -> wine32) I also have configure set to
use a custom installation prefix under /opt.

After that I use update-alternatives for wine's main binaries (wine, wine32/64,
wine-preloader/64, winecfg, explorer, msiexec, etc.) so that they can be found
on the local $PATH, and so that I can switch them out seamlessly if I need to.
(Makes testing regressions or other things easier for me.) This winds up
putting about two layers of symlinks between where ever the $PATH search found
wine and the actual installation directory, but I haven't had an issue with
wine loading before now.

Normally, If I'm testing something, I do so manually from the shell prompt.
I.e. "WINEPREFIX=/path/to/some/new/prefix winecfg" but once things are stable
and I know the prefix to be functional it gets moved to using a shell script I
wrote to manage things. (Mostly save game / user data management, but it's also
used by .desktop files and the other end users I have to manage wine for.
(Copying the prefixes to their own directories.)) That said if something breaks
I will try to test and re-create the prefix manually before coming here with
it.

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

--- Comment #3 from Alexandre Julliard  ---
The symlinks sound like a possible culprit. Does it work if you run the wine
binary directly?

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

--- Comment #4 from Patrick Hibbs  ---
Created attachment 73902
  --> https://bugs.winehq.org/attachment.cgi?id=73902
wrong bitness direct launch attempt log

Calling wine directly doesn't work if the wrong bitness version of wine (E.g.
wine32 for a 64bit winecfg) is used.

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

--- Comment #5 from Patrick Hibbs  ---
Created attachment 73903
  --> https://bugs.winehq.org/attachment.cgi?id=73903
correct bitness direct launch attempt log

(In reply to Alexandre Julliard from comment #3)
> The symlinks sound like a possible culprit. Does it work if you run the wine
> binary directly?

Using the correct bitness version of wine (E.g. wine64 with a 64bit winecfg)
gets us a little bit further. I.e. Wine doesn't cause a forkbomb, and does
create a virtual desktop window (if the prefix was configured for it) but it
still crashes being unable to load ntdll.

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

--- Comment #6 from Alexandre Julliard  ---
OK I see, the problem is that you have separate /opt/wine-git-build/wine32 and
/opt/wine-git-build/wine64 install directories. For a proper WoW64 setup you
are supposed to install both trees to the same directory.

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

Patrick Hibbs  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #7 from Patrick Hibbs  ---
(In reply to Alexandre Julliard from comment #6)
> OK I see, the problem is that you have separate /opt/wine-git-build/wine32
> and /opt/wine-git-build/wine64 install directories. For a proper WoW64 setup
> you are supposed to install both trees to the same directory.

Yeah, changing the install prefix to keep both in the same directory works
without reverting the commit.

[Bug 54317] Change to exec_wineloader made wine not start at all

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54317

Gijs Vermeulen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #8 from Gijs Vermeulen  ---
Closing WORKSFORME.