[Bug 60389] New: 16-bit installer subsystem crashes (fixed-offset null-pointer-style read) under new WoW64, works fine under classic WoW64
http://bugs.winehq.org/show_bug.cgi?id=60389 Bug ID: 60389 Summary: 16-bit installer subsystem crashes (fixed-offset null-pointer-style read) under new WoW64, works fine under classic WoW64 Product: Wine Version: 11.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: fjavier1954@gmail.com Target Milestone: --- Distribution: --- Created attachment 82182 --> http://bugs.winehq.org/attachment.cgi?id=82182 Crash log, Wine 11.17, Windows XP Summary 16-bit installer subsystem (krnl386.exe16) crashes with a null-pointer-style read access violation when running under the new WoW64 architecture (no multilib / no 32-bit host process). The same installer works correctly under classic WoW64 (wine32 + wine64, e.g. Wine 11.0 on Linux Mint 21.3 with multilib/i386 enabled). Environment - Wine build: wine-11.17 and wine-11.18 (Arch/CachyOS official packages, pure WoW64, no multilib dependency) — same crash class reproduced on both versions, see "Second reproduction" below. - Host: CachyOS Linux, kernel 7.2.5-1-cachyos, x86_64. - Working reference environment: Wine 11.0, Linux Mint 21.3, classic WoW64 (wine32 + wine64, multilib/i386 enabled) — same installer runs and completes correctly there, aside from an unrelated 3D-rendering bug. - WINEPREFIX: fresh 64-bit WoW64 prefix (default), no WINEARCH override. WINEARCH=win32 is rejected in this build with: "WINEARCH is set to 'win32' but this is not supported in wow64 mode." - Windows version emulated: reproduced under both "Windows XP" and "Windows 2000" settings in winecfg — same crash signature in both cases (attachments here are the Windows XP runs only). What I'm trying to run A commercial legacy Windows application from around 1999-2000 (proprietary software, name withheld, happy to give more detail if it helps triage). The main installer is MAINSETUP.EXE, a PE32 executable for MS Windows 4.00 (GUI), Intel i386, 4 sections, built with linker version 6.0. I confirmed with the `file` command that this is a genuine 32-bit PE executable, not a 16-bit NE executable, and not an archive-wrapped installer (verified by extracting it with 7-Zip: it only contains the executable's own PE sections — .text/.data/.rdata/.rsrc — no embedded installer payload). The final installed application binaries are also all PE32 32-bit. So the crashing code appears to be a 16-bit component invoked internally by this otherwise-32-bit installer (likely a legacy install/license-check routine from that era), rather than the application itself being 16-bit. Steps to reproduce 1. On a system with Wine built against the new (pure) WoW64 architecture (no multilib), create a fresh WINEPREFIX. 2. Set the Windows version to XP (or 2000) in winecfg. 3. Run wine MAINSETUP.EXE. 4. Proceed through the installer UI to the license-code entry screen. 5. Enter a valid license code and click "Install". Expected result The installer proceeds with the installation, as it does under classic WoW64 (Wine 11.0, Mint 21.3, wine32+wine64). Actual result (Wine 11.17) The installer window stops responding. Terminal output shows the 16-bit subsystem (krnl386.exe16, user.exe16, gdi.exe16, etc. — all loaded successfully) is invoked, but it crashes shortly after with an unhandled exception: a page fault on read access to address 0x00000030, happening in wow64 32-bit code, with the backtrace going through ntdll, kernelbase, kernel32, and krnl386.exe16 (see attached crash-11.17-winxp.txt for the full backtrace and register dump). Reproduced twice, with two different Windows-version settings (XP and Windows 2000), both times crashing with a read access violation at the same fixed offset (0x00000030) from what looks like a null pointer, always originating from krnl386.exe16 calling into kernelbase/kernel32. Second reproduction on Wine 11.18 Re-tested on wine-11.18 (same host, same installer, same steps, Windows XP setting). The crash is the same class of bug — a read fault at the same fixed offset 0x00000030, still triggered from 16-bit code — but the exact call site has moved: this time the backtrace goes through win32u, user32, user.exe16 and krnl386.exe16 (see attached crash-11.18-winxp.txt). On 11.17 the crash happened one layer lower, directly in krnl386.exe16 -> kernelbase/kernel32. On 11.18 it happens one layer higher, in a 16-bit USER call (user.exe16, e.g. window/dialog creation) thunking up through user32 into win32u — but it's still the same fixed offset (0x30) being read, which looks like the same underlying null or uninitialized pointer issue surfacing at a different point in the 16-to-32-bit call chain, rather than two unrelated bugs. This looks consistent with the large TEB/main-image rework that landed around 11.18 having shifted where the bad pointer gets dereferenced, without fixing the root cause. Additional notes - This is not the well-known "WINEARCH=win32 not supported in wow64 mode" limitation — the 16-bit subsystem does initialize and load all its modules correctly under both 11.17 and 11.18 (unlike an earlier test on a CachyOS-patched Wine 10.x testing build, where krnl386.exe16 failed to initialize entirely). The crash here happens deeper, once 16-bit code is actually executing and calling back into 32-bit routines — it looks like a bug in the 16-to-32-bit thunking/ translation path of the new WoW64 implementation itself, rather than a missing-support issue. - This may be related to bug 54670 ("16-bit applications fail in wow64 mode"), which was closed fixed in 10.16 and addressed an earlier failure where krnl386.exe16 would fail to initialize entirely ("failed to initialize, aborting"). That specific failure is no longer present here — krnl386.exe16 and its dependent 16-bit modules all initialize and run correctly under 11.17/11.18. This report is about a separate crash that occurs further down the call chain, once 16-bit code is already running, which may be a follow-on issue left after that earlier fix rather than the same bug. - Switching the emulated Windows version between XP and 2000 does not change the outcome (only the exact call depth reached before the crash). - The fact that the same fixed-offset (0x30) read fault reproduces across two consecutive dev releases (11.17 and 11.18), at two different points in the 16-to-32-bit call chain, suggests a structural issue in the new WoW64's 16-bit thunking rather than a one-off regression in either release. - Happy to test further Wine versions or provide WINEDEBUG logs if that would help triage. I'd rather not share the installer itself, as it's proprietary commercial software. --- -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60389 --- Comment #1 from Javier <fjavier1954@gmail.com> --- Created attachment 82183 --> http://bugs.winehq.org/attachment.cgi?id=82183 Crash log, Wine 11.18, Windows XP -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60389 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Installer, win16, wow64 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla