Serious wineboot.exe bug on Wine 1.7.19

[lunavorax]

Hello,

I'm running Wine 1.7.19 on ArchLinux x86_64.

I'm also a super maintainer for the video game Mob Rule.

While this game is supposed to be Platinum, I was surprised to see it retrograde to Garbage because the installer doens't work any longer.

Normally, when launching the installer, wine will output the following.

Code: Select all

modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
err:module:attach_process_dlls "krnl386.exe16" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\system32\\winevdm.exe" failed, status c0000005

But after several retry and changing to Windows 98/95 mode, wine outputs only the five firt lines and waits.
htop shows that C:\windows\system32\wineboot.exe --init is asking 100% CPU.
After 2minutes, wine outputs err:process:__wine_kernel_init boot event wait timed out and lauch a second C:\windows\system32\wineboot.exe --init aside from the first one that doesn't behave differently.

My command then stops at some point and gives me back the prompt, but the wine processes are still active and running 100%. They don't disapear unless I do a wineserver -k.

[dimesio]

Try a clean wineprefix first, but if that doesn't fix it, run a regression test and file a bug. http://wiki.winehq.org/RegressionTesting

[lunavorax]

I did this under a clean prefix. I'll have a look at the regression test.

[panik105]

Hi,

did you recently update your kernl to 3.14 ?

I have same problem with different programs (i.e. Irfanview, PhotoMapper) and different Wine-Version (1.4.1 being on debian wheezy) since i updated to linux3.14.
Going back to 3.13 and everythinf works again. The problem seems to be discussed already on lkml (https://lkml.org/lkml/2014/4/11/542).
In that thread it is said, that only 16Bit-Programs are affected, but for me no program works anymore (only tested a few)

Bye..
Michael

[lunavorax]

Indeed, there was a bug in the Wine package for ArchLinux but it got corrected.
Now, the only problem I have is that no win16 executable will run.

Someone already told me that it had something to do with the kernel, and you proved it right.
Now I have absolutely no idea what the future of win16 binaries will be on Wine + GNU/Linux x86_64…

[doragasu]

I'm also having this problem, also on an up to date (as of today) x86_64 Arch Linux.

I could run in previous wine versions Orcad 10.5 suite, the only thing I had to do is install it to a Win32 prefix and configure layout.exe to be launched as a Windows 98 program. The other tools ran perfect as Windows XP, and with this configuration, layout.exe ran also perfect as Windows 98.

Last update it started showing this problem: getting locked with 100% CPU usage on wineboot and showing "modify_ldt: Invalid argument" messages.

I reinstalled Orcad to a clean win32 prefix and each time I configure anything (I don't thing they are all 16 bit applications) to run as Windows 98 using winecfg, again it freezes and shows these errors, so I'm unable to run layout.exe (I can run the other tools as long as they are configured as Windows XP).

Even though this looks like a kernel problem, could this be worked around in wine? Will we be able to run binaries as Windows 95/98?

[dimesio]

Even though this looks like a kernel problem, could this be worked around in wine? Will we be able to run binaries as Windows 95/98?

http://forum.winehq.org/viewtopic.php?f=8&t=22568

[doragasu]

Thanks dimesio.

But is this problem related only to 16 bit binaries? For me it happens with EVERY BINARY if I set the Windows version to Windows 98. E.g. if I create a clean winebottle:

$ WINEARCH=win32 WINEPREFIX=/home/doragasu/wine/test wineboot

And then run built-in commands that I suppose are 32-bit (is there a way I can know for sure?):

$ WINEPREFIX=/home/doragasu/wine/test winecfg
$ WINEPREFIX=/home/doragasu/wine/test wineconsole

They run perfect. If know using winecfg I change Windows Version to Windows 98 and try running again the same commands (winecfg and wineconsole), I get only the modify_ldt error messages, and the command does never start. And I suppose winecfg and wineconsole are 32-bit.

[panik105]

Hi,
thanks for the hint with the clean wine-environment.
Seems like i switch to "Windows ME" in winecfg a long time ago and forgot about it.
As you cant run Winecfg in that case anymore either, its some kind of chicken and egg problem.
Since i could not figure how to change it back manually in one of the *.reg-files,
i rebooted Linux 3.13, started winecfg, switched to "Windows XP", rebooted Linux 3.14 again
and now everything works again (because all my apps are 32Bit).

Because of this i think the change in linux3.14 has the potential to affect more than just
the "few people, that still use 16-Bit-Programs".

Thanks anyway and bye..
Michael

[shmerl]

I have exactly the same problem when trying to run Neverhood (Wine 1.7.20, Linux 3.14.4). I'm using Windows 95 mode for it and it hangs with high CPU load producing that message:

Code: Select all

modify_ldt: Invalid argument

Neverhood is a 32 bit application. For the reference, here is the bug which tracks this issue: http://bugs.winehq.org/show_bug.cgi?id=36664

[lunavorax]

This means the Neverhood uses 16bit code at some point, could be a DLL.
To allow execution of 16bit code on the GNU/Linux kernel, you have to execute the following command as root:

Code: Select all

echo 1 > /proc/sys/abi/ldt16

I don't recall in which version of the kernel this fix has been introduced, but it works at least on GNU/Linux 3.14.6.

[doragasu]

This means the Neverhood uses 16bit code at some point, could be a DLL.

Not necessarily. As I made clear in bug report 36664, setting Windows 9x/Me mode triggers this problem even for pure 32-bit applications. It looks like it's wine itself who uses 16-bit code during its initialization, when using Windows 9x/Me mode.

[oiaohm]

http://wiki.winehq.org/FAQ#head-bf26e32 ... a60a433f88

lunavorax I listed all the versions to contain /proc/sys/abi/ldt16 in the FAQ. 3.14.6 is the first one in the 3.14.x line to contain it. Yes there is still a security issue with this flag enabled.

The bug also contains by tracking of what versions have the patch. 16-bit under 64 bit Linux kernels will remain a switch. So really wine does have to fix it self if possible to run with 16-bit off for anything that does not need 16 bit code but we have time. Even possibly consider emulation options for 16-bit mode.

Its all about kernel attack surface area. Wine is about the only thing that still uses 16 bit segments on a 64 bit system. 32-bit kernel will keep 16-bit mode.

lunavorax the short story is secuirty bug appears with 16 bit code in Linux kernel. Kernel disables because they cannot work how to fix it on 64 bit kernel they did work out how on 32 bit kernel. This breaks wine goes opps and gives as the reverse. Now that we have a on off switch for 16 bit code we now see in wine that for some reasons in win9x modes and before its doing 16 bit code.

So overall we have had a learning experience all round.