[Bug 60324] New: 64-bit MSVC/UCRT application crashes with unhandled page fault

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60324

            Bug ID: 60324
           Summary: 64-bit MSVC/UCRT application crashes with unhandled
                    page fault
           Product: Wine
           Version: 11.0
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ntdll
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ---

Summary: 64-bit MSVC/UCRT application crashes with unhandled page fault during
CRT
startup while manually walking ntdll's export table looking for
RtlGetCurrentProcessorNumber — reproducible across Wine 8.0, 11.0 stable, and
11.0 staging

Wine version(s) tested: 8.0 (Debian bookworm distro package), 11.0
(winehq-stable), 11.0 (winehq-staging) — all three exhibit the identical crash

Host: Debian bookworm-slim container (Docker), x86_64, Mesa/llvmpipe software
rendering, no /dev/dri

Application: A commercial 64-bit Windows desktop app (Flutter/Dart-for-Windows
UI, bundled MSVC++ 2019 runtime — vcruntime140.dll/msvcp140.dll/ucrtbase.dll
shipped alongside it, native/Microsoft-built). Proprietary, so the binary
can't be attached, but the crash signature and mechanism below should be
reproducible with any similarly-built 64-bit MSVC/UCRT app that hits this CRT
startup code path.

Symptom:

    wine: Unhandled page fault on read access to 0000700000020042 at address
00007FFFFEC41B18 (thread 00dc), starting debugger...

Register state at fault (wine-11.0 stable):

    rip=00007ffffec41b18 rsp=00007ffffe1ff390 rbp=00007ffffe1ff630
eflags=00010206
    rax=00006fffffc93972 rbx=0000000000000001 rcx=0000700000020042
rdx=0000700000040044
    r8=00006fffffbf0000 r14=00007ffffec10000
    si_code=SEGV_MAPERR (address genuinely unmapped, not a permissions fault)

Root cause (established via strace -f across the full forked process tree,
WINEDEBUG=+relay,+seh, and timed /proc/<pid>/maps snapshots):

Immediately before the fault, the crashing thread performs ~1,482 successive
calls of the form

    ucrtbase._stricmp("RtlGetCurrentProcessorNumber", <candidate>)

where <candidate> is read from consecutive addresses advancing by an exact,
constant stride of 0x20002 bytes each call. The first ~20 candidates are
genuine, alphabetically-sorted ntdll export names (wcstok, wcstok_s, wcstol,
wcstombs, wcstoul, wine_get_build_id, wine_get_host_version, wine_get_version,
wine_server_call, wine_server_fd_to_handle, wine_server_handle_to_fd, …) —
i.e. it is genuinely scanning ntdll's export-name table — but then continues
straight past the end of that table into unmapped memory. Extrapolating the
fixed 0x20002 stride from the last valid probe lands exactly (integer
multiple, no remainder) on the fault address 0x700000020042, confirming this
is the same walk running away.

This is not Wine's own find_named_export() (checked against
dlls/ntdll/loader.c on master): that function does a proper binary search
over a 4-byte-stride DWORD RVA array plus an import-hint fast path — it
cannot produce a linear, constant-0x20002-byte-stride scan. So this looks
like CRT-startup code (in ucrtbase.dll/vcruntime140.dll, doing its own
manual/legacy walk of ntdll's export directory to probe for
RtlGetCurrentProcessorNumber as an optional API, bypassing GetProcAddress)
deriving a stride from some field of the export directory that is correct
against a genuine Microsoft ntdll.dll but wrong against Wine's synthesized
one.

What was ruled out, to narrow this down:
- Not the CRT implementation: identical crash with Wine's builtin
  ucrtbase.dll/vcruntime140.dll and with the genuine Microsoft ones
  (installed via winetricks vcrun2019 + ucrtbase2019), same address both
  times.
- Not the Wine branch/version: identical crash on 11.0-stable, 11.0-staging,
  and 8.0 (Debian distro package) — only literal addresses differ
  (address-space layout differs per version), the mechanism and stride are
  the same class of bug.
- Not the reported Windows version string: identical crash whether
  HKCU\Software\Wine\Version is left at default, explicitly win10, or
  explicitly win11.
- Not CPU feature masking (AVX-512 disable via GLIBC_TUNABLES) or missing
  Vulkan — both were tried in earlier troubleshooting rounds, neither changes
  this crash.

Reproduction note: this specific app performs its own internal Windows-
version gate (shows a "you need at least Windows 10" MessageBox and exits
cleanly, exit code 74, no crash trace) if Wine reports itself as older than
Windows 10 — e.g. Wine 8.0's default. To reach the actual crash, first run:

    wine reg add "HKCU\Software\Wine" /v Version /t REG_SZ /d win10 /f

Note: The application is a Banking App. I already went away from my plans of
using it inside of wine, but I think solving the specific problem would likely
also help other applications to run more stable in wine

-- 
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.

[Bug 60324] 64-bit MSVC/UCRT application crashes with unhandled page fault

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60324

--- Comment #1 from Ken Sharp <[e-mail]> ---
What is the application?

-- 
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.