http://bugs.winehq.org/show_bug.cgi?id=56761 --- Comment #14 from mikey9220@gmail.com --- Tested. Summary: the staging patchset fixes it, but only the i386 kernelbase matters, and it's the two kernelbase patches, not ntdll. What's in wine-staging today under patches/ntdll-WRITECOPY is just 0010 and 0011 (kernelbase: VirtualProtect reports PAGE_READWRITE when the old protection was PAGE_WRITECOPY, plus the NULL old_prot guard). The ntdll half was dropped in Sept 2024 (commit 16dce521, "wine-staging will currently allow Chrome based application to run"). Applied those two to the same wine 11.0 tree (CrossOver 26.3 GPL sources, macOS 26.5, Apple Silicon), rebuilt kernelbase.dll only, WINE_SIMULATE_WRITECOPY unset, WINEDEBUG=+seh, 90 s per run, same bottle: i386 kernelbase unpatched: EXCEPTION_BREAKPOINT x1 at libcef+0x16D00E1, renderer dies and gets respawned i386 kernelbase patched: 0 breakpoints, both renderers alive from their first spawn, login page renders Battle.net is a 32-bit process, so patching only x86_64 kernelbase changes nothing (I tried that first: 4 renderer deaths in 90 s). Worth keeping in mind if someone tests this on a 64-bit only build. So for bug 29384's CEF face the staging kernelbase patch is enough. It's a workaround though: the page is still mapped RW from the start and nothing tracks the first write, VirtualProtect just lies about the previous protection. CrossOver's variant does it one layer down (ntdll NtProtectVirtualMemory flips the vprot to "copied" on the first protect call), which is closer to what Windows reports but also not a real implementation. -- 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.