http://bugs.winehq.org/show_bug.cgi?id=56761 mikey9220@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikey9220@gmail.com --- Comment #12 from mikey9220@gmail.com --- Ran into this same int3 while getting Battle.net running on macOS (Apple Silicon, Wine 11 built from CrossOver's GPL sources), and got far enough to say what the check actually is. Same crash as the backtrace in attachment 76555: libcef at +0x16D00E1, in the --type=renderer child, right after DLL load. The code around it, from disassembling libcef.dll (RVA 0x16D00A0): ret = VirtualProtect(addr, size, PAGE_READONLY, &old); if (!ret) int3; // 0x16D00DE if (old != PAGE_READWRITE) int3; // 0x16D00E1 <- this one addr is a page in libcef's own .data section, i.e. an image mapping that's writable copy-on-write. On Windows the page has already been written to by then, so the previous protection comes back as PAGE_READWRITE. Wine maps writable image pages RW from the start and never tracks the first write, so old stays PAGE_WRITECOPY and Chromium's sanity check trips. Renderer dies, the browser process keeps respawning it, and you get the unusable window from comment 0. So this is bug 29384 (WRITECOPY emulation), just with a CEF face on it. Worth noting because every CEF-based launcher hits it the same way (Battle.net, and I'd expect the others in that bug's list). Two data points that back this up: 1. CrossOver's sources carry a hack for exactly this (simulate_writecopy in dlls/ntdll/unix/virtual.c, flips the vprot to "copied" on the first NtProtectVirtualMemory), gated in the GPL drop behind WINE_SIMULATE_WRITECOPY. Running the same self-built engine with that variable set: 0 EXCEPTION_BREAKPOINT in 90 s, both renderer processes alive, login works. Without it: 2 breakpoints, renderer dead, every time. Nothing else changed. 2. Swapping only ntdll.so from the shipped CrossOver binary into the self-built engine gives the same result as the env var, so it's confined to ntdll's virtual memory code. Full traces (+seh,+virtual,+process,+loaddll) and the engine recipe are at https://github.com/BCD1210/soju/blob/main/docs/DIAGNOSIS.md if anyone wants to reproduce. Happy to test the staging ntdll_WRITECOPY patchset against Battle.net on macOS if that's useful; I haven't yet because the CrossOver-style hack was enough to unblock me. -- 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.