https://bugs.winehq.org/show_bug.cgi?id=33127
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #4 from Michael Müller michael@fds-team.de --- The installer tries to execute the installed Thunder.exe at 93% and freezes because the started program enters an endless loop.
The root issue is caused by some custom packer in Thunder.exe. The packer tries to find some suitable address by iterating over the free / allocated memory blocks using VirtualQuery(). If VirtualQuery returns a free memory block which is large enough, the code tries to allocate the memory using VirtualAlloc.
The problem is that Wine pretends in NtQueryVirtualMemory that all memory, which is not part of Wine's memory management system, is allocated:
-------- /* not in a reserved area at all, pretend it's allocated */ #ifdef __i386__ if (base >= (char *)address_space_start) { info->State = MEM_RESERVE; info->Protect = PAGE_NOACCESS; info->AllocationProtect = PAGE_NOACCESS; info->Type = MEM_PRIVATE; } else #endif --------
Since the application just started and only searches for addresses >= the module base address, it can't find any free memory. The code to pretend that all memory is reserved, was added for 32 bit applications to fix bug 4078. Removing this code fixes the reported issue, but reintroduces the problem that Wine doesn't know if the memory block is really unused or if it is allocated by some system library.
The endless loop is caused by a programming mistake in the packer code. The code tries to iterate over all memory blocks by computing the next address using the returned BaseAddress and RegionSize. The problem is that they try to round the addresses to the next page boundary but swapped an addition with a subtraction. This breaks the iteration and in fact the code only tries two different addresses in an endless loop.