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: wine-bugs@list.winehq.org Reporter: wine13.10.hackie@spamgourmet.com 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.