[Bug 49436] 64-bit Diablo III hangs on startup since 5.11

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=49436

Paul Gofman <pgofman at codeweavers.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pgofman at codeweavers.com

--- Comment #9 from Paul Gofman <pgofman at codeweavers.com> ---
Created attachment 67555
  --> https://bugs.winehq.org/attachment.cgi?id=67555
PoC patch for illustration only (will allow the game to start but will break a
lot of apps)

I've tested the game.

While the game was working in Wine 5.10 and it is technically a regression, I
found nothing wrong with the blamed commit so far. It just allows some parts of
DRM to work which break on other things. As a bottom line I suppose this will
have to wait for ntdll.dll converted to PE (hopefully soon). I am not sure if
this is the last unimplemented thing it wants but this is the place where it is
stuck now.

The game's DRM hooks itself from the TLS callbacks in the main exe. In the
first TLS callback it overwrites the TLS callback table with the other
addresses of (obfuscated) callbacks. Those callbacks do nothing on the first
run, but start doing some things on the consequent runs during thread attach.
With the current Wine git it fails early (much earlier than in 5.11), for the
two reasons:
1. TLS callbacks were not called at all in 5.11 (and some versions earlier) due
to regression.
2. With the fix for TLS callbacks added recently it fails after unsuccessful
NtSetInformationThread(..., ThreadHideFromDebugger,...) called for the other
thread. The failure for any non-current thread is a recent regression and
should hopefully be fixed soon.

With the p 2. fixed the game continues, and the subsequent run of the same
callbacks on thread attach it loads ntdll.dll file to memory, guesses the
addresses of DbgBreakPoint() and DbgUserBreakPoint() from on-disk ntdll
(wrongly) and tries to hotpatch them. Then it seemingly does not like something
in the (fake) on disk ntdll regardless of those functions and close the
mapping, only to fail with access violation soon after accessing just closed
mapping. So it seems reasonable to assume that this might be fixed as soon as
we get PE ntdll.dll, or if not, it will make sense to continue from this point.

If we skip calling TLS callbacks on thread attach (as it was the case in 5.11
release and some time before), the game continues to launch, starts Battle.net
client, and after running the game by pressing 'Play' in the client it hangs
with exception stack overflow probably the same way as reported in this bug.
That's where the blamed commit from 5.11 comes into play. The game hotpatches
KiUserExceptionDispatcher() and since the blamed commit the hook starts working
on some exception handling (as it is supposed to on Windows). Before the blamed
commit this function was a stub and never called from Wine exception handling.
It is probably pointless searching what exactly is wrong with it now as we
already skipped calling its TLS callbacks earlier, this can be enough reason
for it to break in any way.

I am attaching the patch on top of current Staging which allows the game to
start the same way as it did in 5.10. I have no idea how (and if) it was
working in some earlier Wine versions when the TLS callbacks were also called
on thread attach. Not sure if investigating that makes practical sense, the way
to go seems to be to wait for PE ntdll and see if it works with it or debug
further from that point.

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