http://bugs.winehq.org/show_bug.cgi?id=60114 --- Comment #1 from Seth2313@gmail.com <Seth2313@gmail.com> --- Clarification on the scope of the evidence, so that nobody over-reads the original description. The failure was observed and analysed on a single occasion (2026-06-03), and that is where the quoted WINEDEBUG line comes from. Since then the patched wineserver with the larger initial mapping has been in place for practically all use of this setup, so the failure has had little opportunity to recur. "Makes the failure disappear permanently" in the original description should therefore be read as "has not been seen again while the larger initial mapping was in place". It is not the result of a controlled A/B comparison, and I want that stated plainly rather than implied. What this does not change is the log evidence itself: NtUserRegisterClassExWOW had already completed the create_class server call successfully and received a valid locator, and only the client-side find_shared_session_object() lookup failed. That is a direct observation from the log, not an inference from the workaround. If a reproduction with a stock wineserver plus WINEDEBUG=warn+win32u,+class would help triage, I am happy to produce one. It should show whether find_shared_session_block() fails to map the block covering the offset, or whether the id check in find_shared_session_object() mismatches. -- 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.