https://bugs.winehq.org/show_bug.cgi?id=40623
Bug ID: 40623 Summary: DOOM (2016) crashes on launch Product: Wine Version: 1.9.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: strider@strycore.com Distribution: ---
The game does not launch at all. From what I understand from the backtrace, it crashes in something related to xinput1_3.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #1 from Mathieu Comandon strider@strycore.com --- Created attachment 54486 --> https://bugs.winehq.org/attachment.cgi?id=54486 Backtrace on Wine 1.9.9
https://bugs.winehq.org/show_bug.cgi?id=40623
roman@hargrave.info roman@hargrave.info changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roman@hargrave.info
--- Comment #2 from roman@hargrave.info roman@hargrave.info --- Please try disabling the steam overlay.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #3 from Mathieu Comandon strider@strycore.com --- Steam overlay was disabled in the global Steam settings but I've also disabled the gameoverlayrenderer64 dll in winecfg and got the same crash.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #4 from Mathieu Comandon strider@strycore.com --- Created attachment 54487 --> https://bugs.winehq.org/attachment.cgi?id=54487 Backtrace on Wine 1.9.9 (gameoverlayrenderer64 disabled)
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #5 from roman@hargrave.info roman@hargrave.info --- Are you using native or WINE xinput?
https://bugs.winehq.org/show_bug.cgi?id=40623
Johannes Brandstätter jbrandst@2ds.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jbrandst@2ds.eu
https://bugs.winehq.org/show_bug.cgi?id=40623
Philipp Richter richterphilipp.pops@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |richterphilipp.pops@gmail.c | |om
--- Comment #6 from Philipp Richter richterphilipp.pops@gmail.com --- Created attachment 54488 --> https://bugs.winehq.org/attachment.cgi?id=54488 Backtrace Wine 1.9.9 - xinput1_3 set to builtin
I forced xinput1_3 to builtin in winecfg and it seems to fail on steamclient64 now? Vanilla Wine 1.9.9 clean 64bit prefix with both gameoverlayrenderer and gameoverlayrenderer64 disabled.
https://bugs.winehq.org/show_bug.cgi?id=40623
Matthew Krafczyk krafczyk.matthew@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |krafczyk.matthew@gmail.com
--- Comment #7 from Matthew Krafczyk krafczyk.matthew@gmail.com --- I also have this issue on wine-staging-1.9.9, however I'm not getting a backtrace when DOOM crashes, so I don't know why exactly DOOM is crashing. Setting xinput1_3 to builtin and disabling gameoverlayrenderer64 also results in a crash.
https://bugs.winehq.org/show_bug.cgi?id=40623
DX099 temptempor@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |temptempor@gmail.com
--- Comment #8 from DX099 temptempor@gmail.com --- On Wine Staging 1.9.5 here, I also have this issue although having no backtrace.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #9 from Johannes Brandstätter jbrandst@2ds.eu --- I was curious and tried to dig a little deeper. But it's not something I'm used to do, so I may be completely wrong.
As there is no obvious debug output and the backtrace isn't really meaningful, at least to me it isn't, I tried to find out what happened before the crash.
The AMD64 ABI says that %rbp+8 is the return address, in our case that would end up being 0x33fe40+8, looking at that stack location I found 0x7bc98433, which pointed me to ntdll, more specifically to RtlUnwind(). But I'm not even sure what applies here, Windows x64 ABI, or AMD64 ABI, anyway it seems to have helped. :)
Oh, so maybe it's crashing while handling an exception? So my next step was to set the wine debug output to +seh and this is what I was presented with:
0063:trace:seh:raise_exception code=80000004 flags=0 addr=0x159e2c7e0 ip=159e2c7e0 tid=0063 0063:trace:seh:raise_exception rax=000000000003f1b0 rbx=000000000006f040 rcx=fffffffffffffffe rdx=0000000000000000 0063:trace:seh:raise_exception rsi=000000015a068211 rdi=000000000006f2ee rbp=000000000033fe40 rsp=000000000032fa38 0063:trace:seh:raise_exception r8=000000000032f6e8 r9=0000000000000000 r10=0000000000000008 r11=0000000000000246 0063:trace:seh:raise_exception r12=00000001580b8151 r13=0000000000000000 r14=000000007b47b120 r15=00007fffff7e8000 0063:trace:seh:call_vectored_handlers calling handler at 0x15828be60 code=80000004 flags=0 0063:trace:seh:call_vectored_handlers handler at 0x15828be60 returned ffffffff 0063:trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=0 tid=0063 0063:trace:seh:raise_exception info[0]=0000000000000000 0063:trace:seh:raise_exception info[1]=0000000000000000 0063:trace:seh:raise_exception rax=000000000032fa58 rbx=000000000006f040 rcx=ffffffff80000001 rdx=0000000159ddce20 0063:trace:seh:raise_exception rsi=0000000000000000 rdi=0000000000000000 rbp=000000000033fe40 rsp=000000000032edb8 0063:trace:seh:raise_exception r8=0000000000000000 r9=0000000000020219 r10=00000000000402f8 r11=0000000000000246 0063:trace:seh:raise_exception r12=00000001580b8151 r13=0000000158af04c0 r14=000000007b47b120 r15=00007fffff7e8000 0063:warn:seh:call_stack_handlers exception data not found in L"DOOMx64.exe"
If I interpret this correctly, there is an exception with code 80000004 thrown at 0x159e2c7e0, which in turn is handled by 0x15828be60. The exception handler returns 0xffffffff and "immediately" after that it throws another exception, this time it's a segfault (c0000005). And I think this is the crash that we see in the backtrace, no address, and the instruction pointer also at 0.
I'm sure there are other more experienced developers around to help out, or may give a hint what could cause something like this. I also run a +relay, but as one has to run this via Steam the log is just enormous and I couldn't identify any issues, but those could be easily overlooked.
Currently I'm stuck here, any help would be appreciated.
https://bugs.winehq.org/show_bug.cgi?id=40623
tttmmc kontakt@toomuchcookies.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kontakt@toomuchcookies.net
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #10 from tttmmc kontakt@toomuchcookies.net --- This is the output i get (with +seh debug option)
[05/14/16 16:18:00] - Running wine-1.9.9-staging DOOMx64.exe (Working directory : /home/..../.PlayOnLinux/wineprefix/Steam64/drive_c/Program Files (x86)/Steam/steamapps/common/DOOM) wine: Unhandled exception 0xc0000409 in thread 8a at address 0x159a31c73 (thread 008a), starting debugger...
https://bugs.winehq.org/show_bug.cgi?id=40623
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions@gmail.com
--- Comment #11 from Berillions berillions@gmail.com --- (In reply to Mathieu Comandon from comment #1)
Created attachment 54486 [details] Backtrace on Wine 1.9.9
In your backtrace, Winecfg is set to WinXP. The game still crash if you set Winecfg to Win7/8.1/10 ?
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #12 from Mathieu Comandon strider@strycore.com --- (In reply to Berillions from comment #11)
In your backtrace, Winecfg is set to WinXP. The game still crash if you set Winecfg to Win7/8.1/10 ?
Yes, the 2nd backtrace I posted (without Steam overlay) was set to Windows 10 and it produced the same crash.
https://bugs.winehq.org/show_bug.cgi?id=40623
Matt m.mcnutt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |m.mcnutt@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40623
hw1380@my.mail.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hw1380@my.mail.de
--- Comment #13 from hw1380@my.mail.de --- Running wine-1.9.9 DOOMx64.exe, I get the following traces. I tried also wine-1.8 and 1.9.9-staging with the same result. No DLL overrides.
I'm wondering why this had worked on the alpha and beta version of Doom4.
fixme:win:EnumDisplayDevicesW ((null),0,0x33e098,0x00000000), stub! IPC client is in my process, could/should be using an in-process pipe.err:module:load_builtin_dll failed to load .so lib for builtin L"winemp3.acm": libmpg123.so.0: Cannot open shared library-object: no such file or directory fixme:advapi:EventRegister {47a9201e-73b0-42ce-9821-7e134361bc6f}, 0x4a7050, 0x544b40, 0x544b38 fixme:advapi:EventRegister {58a9201e-73b0-42ce-9821-7e134361bc70}, 0x4a7050, 0x544b78, 0x544b70 fixme:advapi:EventRegister {3fa9201e-73b0-43fe-9821-7e145359bc6f}, 0x4a7050, 0x544b08, 0x544b00 fixme:advapi:EventRegister {1432afee-73b0-42ce-9821-7e134361b433}, 0x4a7050, 0x544bb0, 0x544ba8 fixme:advapi:EventRegister {4372afee-73b0-42ce-9821-7e134361b519}, 0x4a7050, 0x544be8, 0x544be0 fixme:imm:ImmGetOpenStatus (0x7e490): semi-stub fixme:ver:GetCurrentPackageId (0x33ece0 (nil)): stub fixme:heap:RtlSetHeapInformation 0x19f0000 0 0x33fd00 4 stub err:winediag:gnutls_initialize failed to load libgnutls, no support for crypto hashes fixme:heap:RtlSetHeapInformation 0x1b00000 0 0x33fcf0 4 stub fixme:heap:RtlSetHeapInformation 0x1c10000 0 0x33fcf0 4 stub fixme:debug_buffer:RtlCreateQueryDebugBuffer (0, 0): stub fixme:debug_buffer:RtlCreateQueryDebugBuffer (168, 0): returning 0x18e20b0 fixme:debug_buffer:RtlQueryProcessDebugInformation (97, 14, 0x18e20b0): stub fixme:debug_buffer:RtlDestroyQueryDebugBuffer (0x18e20b0): stub fixme:thread:NtSetInformationThread info class 7 not supported yet fixme:thread:NtSetInformationThread info class 7 not supported yet fixme:advapi:EventRegister {47a9201e-73b0-42ce-9821-7e134361bc6f}, 0x3f006e80, 0x3f04c4a0, 0x3f04c498 fixme:advapi:EventRegister {58a9201e-73b0-42ce-9821-7e134361bc70}, 0x3f006e80, 0x3f04c4d8, 0x3f04c4d0 fixme:advapi:EventRegister {3fa9201e-73b0-43fe-9821-7e145359bc6f}, 0x3f006e80, 0x3f04c468, 0x3f04c460 fixme:advapi:EventRegister {1432afee-73b0-42ce-9821-7e134361b433}, 0x3f006e80, 0x3f04c510, 0x3f04c508 fixme:advapi:EventRegister {4372afee-73b0-42ce-9821-7e134361b519}, 0x3f006e80, 0x3f04c548, 0x3f04c540 err:winediag:schan_imp_init Failed to load libgnutls, secure connections will not be available. fixme:thread:NtSetInformationThread info class 7 not supported yet Setting breakpad minidump AppID = 379720 Steam_SetMinidumpSteamID: Caching Steam ID: 76561198302877211 [API loaded no] fixme:thread:NtSetInformationThread info class 7 not supported yet wine: Unhandled exception 0xc0000409 in thread 61 at address 0x159a31c73 (thread 0061), starting debugger... fixme:system:SystemParametersInfoW Unknown action: 116
I was a little bit surprised why DirectX and vcredist is being installed at the very first start of Doom4 in the steam client.
https://bugs.winehq.org/show_bug.cgi?id=40623
Anthony Jagers noonetinone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noonetinone@gmail.com
--- Comment #14 from Anthony Jagers noonetinone@gmail.com --- I get the same bt as Mathieu. Also my console output is similar to hw1380.
These are the last few lines of the console.
****** fixme:thread:NtSetInformationThread info class 7 not supported yet wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 00f9), starting debugger... fixme:thread:NtSetInformationThread info class 7 not supported yet
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #15 from roman@hargrave.info roman@hargrave.info --- See #40631
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #16 from Nikolay Sivov bunglehead@gmail.com --- *** Bug 40622 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=40623
Mathieu Comandon strider@strycore.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|DOOM (2016) crashes on |DOOM (2016) crashes on |launch |launch due to Denuvo copy | |protection
https://bugs.winehq.org/show_bug.cgi?id=40623
Mathieu Comandon strider@strycore.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.9.9 |1.9.10
https://bugs.winehq.org/show_bug.cgi?id=40623
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
https://bugs.winehq.org/show_bug.cgi?id=40623
Crusader kreuzader@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kreuzader@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40623
MintPaw jerusanders@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jerusanders@gmail.com
--- Comment #17 from MintPaw jerusanders@gmail.com --- It looks like this may be related to the Denuvo DRM needing hardware information. Is this the fault of NtSetInformationThread not being implemented?
https://bugs.winehq.org/show_bug.cgi?id=40623
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #18 from Michael Müller michael@fds-team.de --- Created attachment 54540 --> https://bugs.winehq.org/attachment.cgi?id=54540 Hack to prevent crash
I debugged the crash some days ago. The problem with the Denuvo protection is that it contains a lot of intentional broken code that is called as soon as the system notices that something is going wrong. It is therefore possible that the crash happens on purpose and that the currently crashing code path should not be reached at all if everything works fine. Nevertheless, I analyzed the crash and attached a hack to to work around it.
The following assembler code leads to the crash. I added some annotations to explain the behavior.
----
mov rax,qword ptr gs:[60] ; TEB->PEB mov qword ptr ss:[rsp+C80],rbx mov qword ptr ss:[rsp+C68],rbp
mov rcx,qword ptr ds:[rax+18] ; PEB->LdrData
mov qword ptr ss:[rsp+C60],rsi mov qword ptr ss:[rsp+C58],rdi mov r9,qword ptr ds:[rcx+20] ; LdrData->InMemoryOrderModuleList (list entry)
mov qword ptr ss:[rsp+C50],r12 xor edi,edi sub r9,10 ; -> LDR_MODULE
mov qword ptr ss:[rsp+C48],r14 mov qword ptr ss:[rsp+C40],r15 cmp qword ptr ds:[r9+30],rdi ; LDR_MODULE->BaseAddress ; The comparison is a bit misleading, as the BaseAddress ; can never be zero. The idea is that if we reach the end ; of the list, we get a pointer to LdrData->InMemoryOrderModuleList ; again. The offset of LDR_MODULE->BaseAddress now matches the ; PEB_LDR_DATA->EntryInProgress offset. This value should be zero ; and wine never changes it anyway. The iteration therefore stops ; when we reach this entry again.
; Reached end of list je doomx64.159E4907E ; --> Crash
; BeginHash: mov r10,qword ptr ds:[r9+60] ; LDR_MODULE->BaseDllName.Buffer mov edx,edi ; edx will contain the hash, initialize with 0 mov r8,rdi movzx ecx,word ptr ds:[r10] ; Check if BaseDllName is empty test cx,cx je doomx64.159E49075 ; --> NextEntry
; ConverToLowerCase: lea eax,dword ptr ds:[rcx-41] ; - 'A' cmp ax,19 ja doomx64.159E49055 ; --> HashChar add cx,20 ; tolower
; HashChar: inc r8 movzx eax,cx movzx ecx,word ptr ds:[r10+r8*2] ; ecx -> next char
; The actual "hashing" of the name add edx,eax ; edx += char add edx,edx ; edx *= 2
; Reached end of string? test cx,cx jne doomx64.159E49048 ; no --> ConverToLowerCase cmp edx,C8A08 ; check hash against 0xC8A08 je doomx64.159E49178 ; --> found
; NextEntry: mov r9,qword ptr ds:[r9] ; InLoadOrderModuleList.Flink cmp qword ptr ds:[r9+30],rdi ; LDR_MODULE->BaseAddress ; Reached end of list? jne doomx64.159E49036 ; no --> BeginHash
; Crash: ; This function is meant to crash. It calls rsi (=rdi), ; which is already set to zero when the whole code path is ; reached. This is most probably just broken code to confuse us. mov rsi,rdi lea rax,qword ptr ss:[rsp+C98] lea rdx,qword ptr ds:[159DDCE20] mov r9d,20219 xor r8d,r8d mov rcx,FFFFFFFF80000001 mov qword ptr ss:[rsp+20],rax call rsi ; rsi = rdi = 0 test eax,eax
----
The whole algorithm just searches for a specific dll using a hash. The enumeration matches the following C code:
----
TEB *teb = (void*) NtCurrentTeb(); PEB *peb = teb->Peb;
PEB_LDR_DATA *ldr_data = peb->LdrData; LIST_ENTRY *entry = ldr_data->InMemoryOrderModuleList.Flink; LDR_MODULE *mod = (void*) ((char*) entry - 0x10);
while (mod->BaseAddress) { /* hash mod->BaseDllName.Buffer */ mod = (void*)mod->InLoadOrderModuleList.Flink; }
----
The assembler code searches for the hash 0xC8A08 which corresponds to advapi32.dll. The dll is loaded directly by doom through the PE import section. So why does it crash? Well, if you look at the enumeration you will see that it starts the search using the InMemoryOrderModuleList list but continues using the InLoadOrderModuleList list. The search only succeeds if the first entry in InMemoryOrderModuleList (i.e. the dll loaded at the lowest address) is loaded before advapi32. Otherwise the code intentionally crashes.
I currently don't have a windows machine for testing but it would be great if someone could attach a debugger on windows and take a look at the loaded libraries and their addresses. This way we can check if the whole code is garbage to confuse people or if the necessary conditions are met on windows.
I wrote a hack to pin advapi32.dll as first entry of the InMemoryOrderModuleList. This prevents the crash and Doom uses advapi32 to read some registry keys. It also loads the dbdata license file. When this is done nothing interesting happens any more. I guess that the license check fails, but I haven't debugged it any further since I don't have enough time at the moment. It would also make sense to check the theory on windows first to prevent wasting time on some intentionally broken code.
If someone wants to debug this any further, the attached hack should help. I wrote it against Staging (to use WINEDEBUG=+DOOMx64.exe:relay for generating relay logs without debugging Steam), but it should also apply on plain wine.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #19 from roman@hargrave.info roman@hargrave.info --- (In reply to Michael Müller from comment #18)
Created attachment 54540 [details] Hack to prevent crash
I debugged the crash some days ago. The problem with the Denuvo protection is that it contains a lot of intentional broken code that is called as soon as the system notices that something is going wrong. It is therefore possible that the crash happens on purpose and that the currently crashing code path should not be reached at all if everything works fine. Nevertheless, I analyzed the crash and attached a hack to to work around it.
The following assembler code leads to the crash. I added some annotations to explain the behavior.
mov rax,qword ptr gs:[60] ; TEB->PEB mov qword ptr ss:[rsp+C80],rbx mov qword ptr ss:[rsp+C68],rbp
mov rcx,qword ptr ds:[rax+18] ; PEB->LdrData
mov qword ptr ss:[rsp+C60],rsi mov qword ptr ss:[rsp+C58],rdi mov r9,qword ptr ds:[rcx+20] ; LdrData->InMemoryOrderModuleList (list entry)
mov qword ptr ss:[rsp+C50],r12 xor edi,edi sub r9,10 ; -> LDR_MODULE
mov qword ptr ss:[rsp+C48],r14 mov qword ptr ss:[rsp+C40],r15 cmp qword ptr ds:[r9+30],rdi ; LDR_MODULE->BaseAddress ; The comparison is a bit misleading, as the BaseAddress ; can never be zero. The idea is that if we reach the end ; of the list, we get a pointer to LdrData->InMemoryOrderModuleList ; again. The offset of LDR_MODULE->BaseAddress now matches the ; PEB_LDR_DATA->EntryInProgress offset. This value should be zero ; and wine never changes it anyway. The iteration therefore stops ; when we reach this entry again.
; Reached end of list je doomx64.159E4907E ; --> Crash
; BeginHash: mov r10,qword ptr ds:[r9+60] ; LDR_MODULE->BaseDllName.Buffer mov edx,edi ; edx will contain the hash, initialize with 0 mov r8,rdi movzx ecx,word ptr ds:[r10] ; Check if BaseDllName is empty test cx,cx je doomx64.159E49075 ; --> NextEntry
; ConverToLowerCase: lea eax,dword ptr ds:[rcx-41] ; - 'A' cmp ax,19 ja doomx64.159E49055 ; --> HashChar add cx,20 ; tolower
; HashChar: inc r8 movzx eax,cx movzx ecx,word ptr ds:[r10+r8*2] ; ecx -> next char
; The actual "hashing" of the name add edx,eax ; edx += char add edx,edx ; edx *= 2
; Reached end of string? test cx,cx jne doomx64.159E49048 ; no --> ConverToLowerCase cmp edx,C8A08 ; check hash against 0xC8A08 je doomx64.159E49178 ; --> found
; NextEntry: mov r9,qword ptr ds:[r9] ; InLoadOrderModuleList.Flink cmp qword ptr ds:[r9+30],rdi ; LDR_MODULE->BaseAddress ; Reached end of list? jne doomx64.159E49036 ; no --> BeginHash
; Crash: ; This function is meant to crash. It calls rsi (=rdi), ; which is already set to zero when the whole code path is ; reached. This is most probably just broken code to confuse us. mov rsi,rdi lea rax,qword ptr ss:[rsp+C98] lea rdx,qword ptr ds:[159DDCE20] mov r9d,20219 xor r8d,r8d mov rcx,FFFFFFFF80000001 mov qword ptr ss:[rsp+20],rax call rsi ; rsi = rdi = 0 test eax,eax
The whole algorithm just searches for a specific dll using a hash. The enumeration matches the following C code:
TEB *teb = (void*) NtCurrentTeb(); PEB *peb = teb->Peb;
PEB_LDR_DATA *ldr_data = peb->LdrData; LIST_ENTRY *entry = ldr_data->InMemoryOrderModuleList.Flink; LDR_MODULE *mod = (void*) ((char*) entry - 0x10);
while (mod->BaseAddress) { /* hash mod->BaseDllName.Buffer */ mod = (void*)mod->InLoadOrderModuleList.Flink; }
The assembler code searches for the hash 0xC8A08 which corresponds to advapi32.dll. The dll is loaded directly by doom through the PE import section. So why does it crash? Well, if you look at the enumeration you will see that it starts the search using the InMemoryOrderModuleList list but continues using the InLoadOrderModuleList list. The search only succeeds if the first entry in InMemoryOrderModuleList (i.e. the dll loaded at the lowest address) is loaded before advapi32. Otherwise the code intentionally crashes.
I currently don't have a windows machine for testing but it would be great if someone could attach a debugger on windows and take a look at the loaded libraries and their addresses. This way we can check if the whole code is garbage to confuse people or if the necessary conditions are met on windows.
I wrote a hack to pin advapi32.dll as first entry of the InMemoryOrderModuleList. This prevents the crash and Doom uses advapi32 to read some registry keys. It also loads the dbdata license file. When this is done nothing interesting happens any more. I guess that the license check fails, but I haven't debugged it any further since I don't have enough time at the moment. It would also make sense to check the theory on windows first to prevent wasting time on some intentionally broken code.
If someone wants to debug this any further, the attached hack should help. I wrote it against Staging (to use WINEDEBUG=+DOOMx64.exe:relay for generating relay logs without debugging Steam), but it should also apply on plain wine.
Thanks for the input Michael. If it's truly the case that WINE is simply not similar enough to a Windows environment for Denuvo to be "OK", and not the case that WINE is not implemented behaviour required for the basic functioning of Denuvo in itself, that would mean that a simple set of patched could potentially make this work. Unfortunately I can't do the suggested testing, but I would like to note that debugging Denuvo (or running it in a VM) may lead to unexpected results.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #20 from roman@hargrave.info roman@hargrave.info --- (In reply to roman@hargrave.info from comment #19)
(In reply to Michael Müller from comment #18)
Created attachment 54540 [details] Hack to prevent crash
I debugged the crash some days ago. The problem with the Denuvo protection is that it contains a lot of intentional broken code that is called as soon as the system notices that something is going wrong. It is therefore possible that the crash happens on purpose and that the currently crashing code path should not be reached at all if everything works fine. Nevertheless, I analyzed the crash and attached a hack to to work around it.
The following assembler code leads to the crash. I added some annotations to explain the behavior.
mov rax,qword ptr gs:[60] ; TEB->PEB mov qword ptr ss:[rsp+C80],rbx mov qword ptr ss:[rsp+C68],rbp
mov rcx,qword ptr ds:[rax+18] ; PEB->LdrData
mov qword ptr ss:[rsp+C60],rsi mov qword ptr ss:[rsp+C58],rdi mov r9,qword ptr ds:[rcx+20] ; LdrData->InMemoryOrderModuleList (list entry)
mov qword ptr ss:[rsp+C50],r12 xor edi,edi sub r9,10 ; -> LDR_MODULE
mov qword ptr ss:[rsp+C48],r14 mov qword ptr ss:[rsp+C40],r15 cmp qword ptr ds:[r9+30],rdi ; LDR_MODULE->BaseAddress ; The comparison is a bit misleading, as the BaseAddress ; can never be zero. The idea is that if we reach the end ; of the list, we get a pointer to LdrData->InMemoryOrderModuleList ; again. The offset of LDR_MODULE->BaseAddress now matches the ; PEB_LDR_DATA->EntryInProgress offset. This value should be zero ; and wine never changes it anyway. The iteration therefore stops ; when we reach this entry again.
; Reached end of list je doomx64.159E4907E ; --> Crash
; BeginHash: mov r10,qword ptr ds:[r9+60] ; LDR_MODULE->BaseDllName.Buffer mov edx,edi ; edx will contain the hash, initialize with 0 mov r8,rdi movzx ecx,word ptr ds:[r10] ; Check if BaseDllName is empty test cx,cx je doomx64.159E49075 ; --> NextEntry
; ConverToLowerCase: lea eax,dword ptr ds:[rcx-41] ; - 'A' cmp ax,19 ja doomx64.159E49055 ; --> HashChar add cx,20 ; tolower
; HashChar: inc r8 movzx eax,cx movzx ecx,word ptr ds:[r10+r8*2] ; ecx -> next char
; The actual "hashing" of the name add edx,eax ; edx += char add edx,edx ; edx *= 2
; Reached end of string? test cx,cx jne doomx64.159E49048 ; no --> ConverToLowerCase cmp edx,C8A08 ; check hash against 0xC8A08 je doomx64.159E49178 ; --> found
; NextEntry: mov r9,qword ptr ds:[r9] ; InLoadOrderModuleList.Flink cmp qword ptr ds:[r9+30],rdi ; LDR_MODULE->BaseAddress ; Reached end of list? jne doomx64.159E49036 ; no --> BeginHash
; Crash: ; This function is meant to crash. It calls rsi (=rdi), ; which is already set to zero when the whole code path is ; reached. This is most probably just broken code to confuse us. mov rsi,rdi lea rax,qword ptr ss:[rsp+C98] lea rdx,qword ptr ds:[159DDCE20] mov r9d,20219 xor r8d,r8d mov rcx,FFFFFFFF80000001 mov qword ptr ss:[rsp+20],rax call rsi ; rsi = rdi = 0 test eax,eax
The whole algorithm just searches for a specific dll using a hash. The enumeration matches the following C code:
TEB *teb = (void*) NtCurrentTeb(); PEB *peb = teb->Peb;
PEB_LDR_DATA *ldr_data = peb->LdrData; LIST_ENTRY *entry = ldr_data->InMemoryOrderModuleList.Flink; LDR_MODULE *mod = (void*) ((char*) entry - 0x10);
while (mod->BaseAddress) { /* hash mod->BaseDllName.Buffer */ mod = (void*)mod->InLoadOrderModuleList.Flink; }
The assembler code searches for the hash 0xC8A08 which corresponds to advapi32.dll. The dll is loaded directly by doom through the PE import section. So why does it crash? Well, if you look at the enumeration you will see that it starts the search using the InMemoryOrderModuleList list but continues using the InLoadOrderModuleList list. The search only succeeds if the first entry in InMemoryOrderModuleList (i.e. the dll loaded at the lowest address) is loaded before advapi32. Otherwise the code intentionally crashes.
I currently don't have a windows machine for testing but it would be great if someone could attach a debugger on windows and take a look at the loaded libraries and their addresses. This way we can check if the whole code is garbage to confuse people or if the necessary conditions are met on windows.
I wrote a hack to pin advapi32.dll as first entry of the InMemoryOrderModuleList. This prevents the crash and Doom uses advapi32 to read some registry keys. It also loads the dbdata license file. When this is done nothing interesting happens any more. I guess that the license check fails, but I haven't debugged it any further since I don't have enough time at the moment. It would also make sense to check the theory on windows first to prevent wasting time on some intentionally broken code.
If someone wants to debug this any further, the attached hack should help. I wrote it against Staging (to use WINEDEBUG=+DOOMx64.exe:relay for generating relay logs without debugging Steam), but it should also apply on plain wine.
Thanks for the input Michael. If it's truly the case that WINE is simply not similar enough to a Windows environment for Denuvo to be "OK", and not the case that WINE is not implemented behaviour required for the basic functioning of Denuvo in itself, that would mean that a simple set of patched could potentially make this work. Unfortunately I can't do the suggested testing, but I would like to note that debugging Denuvo (or running it in a VM) may lead to unexpected results.
I would also like to note that I contacted Denuvo asking for a sample application with which to test WINE.
I was completely ignored.
https://bugs.winehq.org/show_bug.cgi?id=40623
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #21 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to roman@hargrave.info from comment #20)
I would also like to note that I contacted Denuvo asking for a sample application with which to test WINE.
I was completely ignored.
Do you understand that by providing a sample application for Wine they would provide a play ground for every cracker out there, essentially making their protection useless? Any sane protection developer would do exactly that: ignore such requests - in order to hide all the details how the protection works under the hood. Besides, they don't know who you are, and what actually you are planning to do with the disclosed data.
P.S. Please don't quote the text you are not going to comment on anyway, this pollutes the bug report and makes it hard to find useful information.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #22 from roman@hargrave.info roman@hargrave.info --- (In reply to Dmitry Timoshkov from comment #21)
(In reply to roman@hargrave.info from comment #20)
I would also like to note that I contacted Denuvo asking for a sample application with which to test WINE.
I was completely ignored.
Do you understand that by providing a sample application for Wine they would provide a play ground for every cracker out there, essentially making their protection useless? Any sane protection developer would do exactly that: ignore such requests - in order to hide all the details how the protection works under the hood. Besides, they don't know who you are, and what actually you are planning to do with the disclosed data.
P.S. Please don't quote the text you are not going to comment on anyway, this pollutes the bug report and makes it hard to find useful information.
My point was that rather than acknowledging the existence of a problem by responding with a "no", they binned it. I never expect a positive response when making such inquiries.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #23 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to roman@hargrave.info from comment #22)
My point was that rather than acknowledging the existence of a problem by responding with a "no", they binned it. I never expect a positive response when making such inquiries.
Then I'm not sure what you are complaining about: You've got the "No" you were expecting but just in another form :).
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #24 from Mathieu Comandon strider@strycore.com ---
I currently don't have a windows machine for testing but it would be great if someone could attach a debugger on windows and take a look at the loaded libraries and their addresses.
I have Windows 10 and Visual Studio Community 2015 installed on my machine. Give me the directions on how to obtain the information you need and I will post it back ASAP.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #25 from DX099 temptempor@gmail.com ---
I currently don't have a windows machine for testing but it would be great if someone could attach a debugger on windows and take a look at the loaded libraries and their addresses. This way we can check if the whole code is garbage to confuse people or if the necessary conditions are met on windows.
My debugging skills and knowledge are meager. I apologize in advance if this ends up being unusable data, but I ran the game through WinDBGx64 and could gather this:
http://hastebin.com/hihefoviga.tex
I was unable to proceed further or obtain more information once the game had launched with the debugger.
I however made a memory dump through Windows task manager and tried to check out the addresses. I obtained something like this:
https://gist.github.com/DistantThunder/3d0e51bb87e8847368ed6c06ffd91a68
Again, I apologize if this isn't of any use.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #26 from DX099 temptempor@gmail.com --- This is the memory dump of the running program I was talking before. It's around 680MB 7z compressed data and 2.7 GB uncompressed.
https://bugs.winehq.org/show_bug.cgi?id=40623
Mathieu Comandon strider@strycore.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.9.10 |1.9.11
https://bugs.winehq.org/show_bug.cgi?id=40623
Alex axfelix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |axfelix@gmail.com
--- Comment #27 from Alex axfelix@gmail.com --- For what it's worth I wouldn't underestimate Denuvo -- there's a reason it's only supported for C++ Windows titles; it's very low-level DRM and has proven uncrackable by pirate groups for six months now.
I appreciate your work here but just want to warn you this may be a black hole.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #28 from roman@hargrave.info roman@hargrave.info --- (In reply to Alex from comment #27)
For what it's worth I wouldn't underestimate Denuvo -- there's a reason it's only supported for C++ Windows titles; it's very low-level DRM and has proven uncrackable by pirate groups for six months now.
I appreciate your work here but just want to warn you this may be a black hole.
I think that this is only a better argument for compatibility in WINE, as it does intend to replicate a lot of the behaviour DRM like this relies on.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #29 from Alex axfelix@gmail.com --- Yes, I agree! I think Wine is a lot more sustainable in this respect than it gets credit for, compared to any officially-supported cross-platform solutions... but Denuvo is going to be very difficult to effectively emulate.
https://bugs.winehq.org/show_bug.cgi?id=40623
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #30 from DX099 temptempor@gmail.com --- (In reply to Alex from comment #29)
Yes, I agree! I think Wine is a lot more sustainable in this respect than it gets credit for, compared to any officially-supported cross-platform solutions... but Denuvo is going to be very difficult to effectively emulate.
Ah but I think the point is that WINE isn't trying to emulate Denuvo/VMProtect, but rather to emulate an environment well enough so that it does its voodoo.
That should be possible I believe without understanding the intricacies of the voodoo itself.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #31 from Mathieu Comandon strider@strycore.com --- Created attachment 54612 --> https://bugs.winehq.org/attachment.cgi?id=54612 Error dialog on Wine Staging 1.9.11
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #32 from Mathieu Comandon strider@strycore.com ---
Ah but I think the point is that WINE isn't trying to emulate Denuvo/VMProtect, but rather to emulate an environment well enough so that it does its voodoo.
Yes, that should be exactly the goal here and it should matter whether Denuvo has been cracked or not, Wine's goals is not to circumvent this protection but to be compatible with it.
Anyway, with Michael's patch added in Wine Staging 1.9.11, Doom shows an error dialog complaining about a server not being reachable (screenshot attached). If the error message is correct then it would boil down to a networking issue?
The message
fixme:thread:NtSetInformationThread info class 7 not supported yet
is repeated a large number of times in the console while this dialog appears, I don't know if this would prevent the game but maybe it could be worthwhile to take care of it first to eliminate this possibility?
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #33 from Mathieu Comandon strider@strycore.com --- btw, info class 7 refers to the following:
ThreadEnableAlignmentFaultFixup
SET mode only. Required information buffer size is 0x01 bytes. Output buffer points to BOOLEAN value.
source: http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%...
https://bugs.winehq.org/show_bug.cgi?id=40623
Mathieu Comandon strider@strycore.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.9.11 |1.9.12
https://bugs.winehq.org/show_bug.cgi?id=40623
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.9.12 |1.9.9 CC| |sebastian@fds-team.de Regression SHA1| |https://bugs.winehq.org/sho | |w_activity.cgi?id=40623
--- Comment #34 from Sebastian Lackner sebastian@fds-team.de --- Please keep the initially reported version (see bug reporting guidelines).
https://bugs.winehq.org/show_bug.cgi?id=40623
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|https://bugs.winehq.org/sho | |w_activity.cgi?id=40623 |
https://bugs.winehq.org/show_bug.cgi?id=40623
Behem0th grantipak@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grantipak@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40623
Jordyn quietraccoon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |quietraccoon@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40623
David Salvisberg dave@portablegaming.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dave@portablegaming.de
https://bugs.winehq.org/show_bug.cgi?id=40623
David Gámiz Jiménez david.gamiz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.gamiz@gmail.com
--- Comment #35 from David Gámiz Jiménez david.gamiz@gmail.com --- Are exits a Demo to test the patch:
http://store.steampowered.com/app/379720
The error in lauch looks the same.
Thanks! :D
https://bugs.winehq.org/show_bug.cgi?id=40623
thesaxophonist@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thesaxophonist@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40623
Luke Bratch luke@bratch.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luke@bratch.co.uk
https://bugs.winehq.org/show_bug.cgi?id=40623
Nguyen Thai Ngoc Duy pclouds@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pclouds@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40623
dubigrasu dubigrasu@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dubigrasu@yahoo.com
https://bugs.winehq.org/show_bug.cgi?id=40623
Anton Romanov theli.ua@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theli.ua@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #36 from Anton Romanov theli.ua@gmail.com --- Somehow with 1.9.20 and clean Win7 (tried 10 as well) win64 prefix and Doom demo I am unable to get to the error dialog, nor to the NtSetInformationThread fixme. Is anyone here still having those on recent wine?
Also, wrt NtSetInformationThread, did anyone with Windows machine ever confirmed/tried on if you even can/allowed to enable/disable alignment fixups in a thread on x86_64 Windows?
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #37 from Mathieu Comandon strider@strycore.com --- @Anton: yes, that is correct. Recent versions of Wine have a different behavior regarding this bug.
With Wine (Staging or not) 1.9.23, the error dialog will not appear but the Doom process will hang and eat 100% of one CPU core until it is manually killed.
This error might be relevant (in Wine Staging): fixme:secur32:schannel_get_mac_algid unknown algorithm 200
or in Wine Devel: fixme:win:RegisterDeviceNotificationW (hwnd=0x200ae, filter=0x33f63c,flags=0x00000000) returns a fake device notification handle!
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #38 from Anton Romanov theli.ua@gmail.com --- @Mathieu No, those fixmes do not look related at all, I tried to do some tracing on DOOM demo, it does not do a lot before getting stuck:
Creates some weird named pipe, Installs vectored exception handler Starts couple of anti-debugging threads, one of which triggers single-step exceptions, which are getting in the aforementioned handler (I guess that is exactly the point of it - to verify that it gets them). After that it verifies that steam is installed on the system by querying HKCU/Software/Valve/Steam Steampath value, after that it creates a copy of that string ... and thats the last meaningfull thing I got out of it - after that things just go haywire.
Unrotunately, I was not able to debug more than that - my attempts to use winedbg with DOOM have failed.
https://bugs.winehq.org/show_bug.cgi?id=40623
david@tpflug.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david@tpflug.com
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #39 from hw1380@my.mail.de --- (In reply to Anton Romanov from comment #38)
@Mathieu No, those fixmes do not look related at all, I tried to do some tracing on DOOM demo, it does not do a lot before getting stuck:
Creates some weird named pipe, Installs vectored exception handler Starts couple of anti-debugging threads, one of which triggers single-step exceptions, which are getting in the aforementioned handler (I guess that is exactly the point of it - to verify that it gets them). After that it verifies that steam is installed on the system by querying HKCU/Software/Valve/Steam Steampath value, after that it creates a copy of that string ... and thats the last meaningfull thing I got out of it - after that things just go haywire.
Unrotunately, I was not able to debug more than that - my attempts to use winedbg with DOOM have failed.
I guess that this was to be expected.
There is an article on a german IT news site: http://www.golem.de/news/denuvo-verdammt-gute-leute-versuchen-unseren-schutz... The CEO of Denuvo was explaining how Denuvo basically works. (2nd page)
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #40 from Mathieu Comandon strider@strycore.com --- The latest update has removed Denuvo from DOOM. Unfortunately, the other blocking bug (#40418 lack of AES encryption in bcrypt.dll) hasn't made any progress since then but I have much higher hopes of seeing that resolved in the next few weeks.
Specifically, the issue seems to be this one:
wine: Call from 0x7b450b3a to unimplemented function bcrypt.dll.BCryptDuplicateHash, aborting
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #41 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Mathieu Comandon from comment #40)
The latest update has removed Denuvo from DOOM.
Sounds like great news.
Unfortunately, the other blocking bug (#40418 lack of AES encryption in bcrypt.dll) hasn't made any progress since then but I have much higher hopes of seeing that resolved in the next few weeks.
AES is in the process of being integrated into Wine currently.
Specifically, the issue seems to be this one:
wine: Call from 0x7b450b3a to unimplemented function bcrypt.dll.BCryptDuplicateHash, aborting
Please open a new bug for that so we can keep track of one problem per bug.
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #42 from Mathieu Comandon strider@strycore.com --- (In reply to Bruno Jesus from comment #41)
AES is in the process of being integrated into Wine currently.
That's great news!
Please open a new bug for that so we can keep track of one problem per bug.
The new bug report can be found here: https://bugs.winehq.org/show_bug.cgi?id=41951
https://bugs.winehq.org/show_bug.cgi?id=40623
--- Comment #43 from Anton Romanov theli.ua@gmail.com --- This bug should be renamed to "DOOM (2016) Demo crashes due to Denuvo protection"
As as mentioned above full version does not have the protection anymore. The Demo version still does though. The remaining bcrypt issues are tracked as separate issues.
https://bugs.winehq.org/show_bug.cgi?id=40623
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|DOOM (2016) crashes on |DOOM (2016) demo crashes on |launch due to Denuvo copy |launch due to Denuvo copy |protection |protection
https://bugs.winehq.org/show_bug.cgi?id=40623
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=40623
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation CC| |focht@gmx.net Component|-unknown |ntdll Summary|DOOM (2016) demo crashes on |DOOM (2016) demo (Steam) |launch due to Denuvo copy |crashes on launch due to |protection |Denuvo copy protection URL| |http://store.steampowered.c | |om/agecheck/app/479030/
--- Comment #44 from Anastasius Focht focht@gmx.net --- Hello folks,
the initial issue, that is the crash was already fixed some time ago by commit https://source.winehq.org/git/wine.git/commit/77be592845591c05a574b720b15c49... ("ntdll: Do not sort InMemoryOrderModuleList by memory address.") -> wine 1.9.14
The current hang in Denuvo's x64 virtual machine code has nothing to do with the crash reported here.
In general DRM/Copy-protection meta bugs shall be avoided.
Bug 40631 ("Denuvo support") reminds me of the old SafeDisc/Securom meta-bugs which stayed open for many years but were essentially useless due to hundreds of comments (they had to be broken into individual tickets, targeting exact versions and APIs).
Regards
https://bugs.winehq.org/show_bug.cgi?id=40623
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #45 from winetest@luukku.com --- Could someone update this bug with a log? I think comment 31 has the latest log and it's dated back 2016-06-01 21:35:59.
A retest with more recent wine could help.
https://bugs.winehq.org/show_bug.cgi?id=40623
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |77be592845591c05a574b720b15 | |c49e7cd1720c7 Resolution|--- |FIXED
--- Comment #46 from Anastasius Focht focht@gmx.net --- Hello folks,
resolving here because the original bug was fixed with https://source.winehq.org/git/wine.git/commitdiff/77be592845591c05a574b720b1... ("ntdll: Do not sort InMemoryOrderModuleList by memory address.") -> wine 1.9.14
Follow-up is bug 44438
Regards
https://bugs.winehq.org/show_bug.cgi?id=40623
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #47 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.1.
-
wine-bugs＠winehq.org