https://bugs.winehq.org/show_bug.cgi?id=52676
Bug ID: 52676 Summary: enigma protected software fails to work properly Product: Wine Version: 7.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl CC: dark.shadow4@web.de Distribution: ---
Created attachment 72003 --> https://bugs.winehq.org/attachment.cgi?id=72003 backtrace of the crash (note the garbage)
As I've said in bug 49052, the trial that's supposed to work just crashes without displaying anything.
Attaching console output.
I've got one other trial that's also enigma protected - that one starts, but enters an infinite loop without displaying anything. That one is using an engine that's known to work here, so I suspect enigma being the reason of the failure.
https://bugs.winehq.org/show_bug.cgi?id=52676
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://sample9.dmm.co.jp/mo | |no/pcgame/1790hw0021/1790hw | |0021t.zip
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- Added a download link. Do you have the exact same version of the trial?
Did you test in a clean WINEPREFIX? You also need to set the locale, e.g. LC_ALL=ja_JP.UTF-8
The garbage seems normal on a crash. Possibly Japanese symbols wine can't handle.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl ---
LANG=ja_JP.utf8
That's like 101 of running Japanese software (actually, any non-Latin1) in wine.
I initially got it from either fanza or dmm link from the game site (one of them failed to fetch), then retested it with the link from the bug - as expected, while I haven't checked the checksums, that's supposed to be the same executable.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- What about the clean WINEPREFIX?
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Fabian Maurer from comment #3)
What about the clean WINEPREFIX?
Makes no difference either.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #5 from Fabian Maurer dark.shadow4@web.de ---
What about the clean WINEPREFIX?
Makes no difference either.
Giving the same exact log? Not even a message about d3dcompiler/shader?
0330:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0x1. 0330:err:winediag:wined3d_dll_init Using the OpenGL renderer.
You seem to have some external settings. Is there more of them?
Does using older wine, e.g. 7.3 help?
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Fabian Maurer from comment #5)
Giving the same exact log? Not even a message about d3dcompiler/shader?
well, WINEDLLOVERRIDES for that was implied.. (unless it's forced by things like the load from registry forcing putting the lib in the system dir, I tend to keep any required override libs in the apps folder)
0330:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0x1. 0330:err:winediag:wined3d_dll_init Using the OpenGL renderer.
You seem to have some external settings. Is there more of them?
That's actually set back to the default value (literally csmt enabled). The prompt is simply cause the key exists.
Does using older wine, e.g. 7.3 help?
No, first tests were with 7.2.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #7 from Zebediah Figura z.figura12@gmail.com --- (In reply to Rafał Mużyło from comment #6)
(In reply to Fabian Maurer from comment #5)
Giving the same exact log? Not even a message about d3dcompiler/shader?
well, WINEDLLOVERRIDES for that was implied..
No, it wasn't. "Clean WINEPREFIX" means no native DLLs installed, no overrides specified, no modifications made, and if you do any of these things you should explicitly mention it when reporting and when replying to bugs.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl --- Given that as clear 'not implemented' messages as the one that comes here without native d3dcompiler_47 are often the very reason for crashes (especially within the d3dx9/d3dcompiler set), 'strongly implied' would be putting it lightly, especially if you already suggested that in the original bug.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Zebediah Figura from comment #7)
...correction, I've missed the author, it's Fabian that I was referring to, not you. As he didn't write this comment, my reply is a bit of target.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- (In reply to Rafał Mużyło from comment #8)
Given that as clear 'not implemented' messages as the one that comes here without native d3dcompiler_47 are often the very reason for crashes (especially within the d3dx9/d3dcompiler set), 'strongly implied' would be putting it lightly, especially if you already suggested that in the original bug.
No. Forcing developers to discover by themselves that workarounds are required, or have been used, only wastes their time. If a clean prefix is explicitly requested, a clean prefix should be used. You should not assume that we will download the program, run it, realize that it needs a certain workaround, and assume that you used that workaround despite being asked not to.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #11 from Fabian Maurer dark.shadow4@web.de --- (In reply to Rafał Mużyło from comment #8)
Given that as clear 'not implemented' messages as the one that comes here without native d3dcompiler_47 are often the very reason for crashes (especially within the d3dx9/d3dcompiler set), 'strongly implied' would be putting it lightly, especially if you already suggested that in the original bug.
No, when I'm saying "clean WINEPREFIX" I mean no override, no settings no nothing. A completely fresh WINEPREFIX and running the program in it.
I'm very well aware that it will soon crash due to missing shader compiler, but at least you get a few messageboxes and a window showing the logo.
That's actually set back to the default value (literally csmt enabled). The prompt is simply cause the key exists.
Well, it doesn't happen for me, so that's a bit worrying to me. Why did you set this?
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #12 from Rafał Mużyło galtgendo@o2.pl ---
I'm very well aware that it will soon crash due to missing shader compiler, but at least you get a few messageboxes and a window showing the logo.
...ah, no it crashes the exact same way regardless of overrides; I mean addresses aren't the same, but given enigma, that doesn't necessarily mean a thing, the crash is still placed between same debug log lines though and doesn't display a damn thing...
...and if you don't recognize it, it's the Software/Wine/Direct3D/csmt key, so if set back to default it's not meaningless, then wine has a bigger problem...
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #13 from Rafał Mużyło galtgendo@o2.pl --- Given the exchange that took place on #winehackers yesterday, I've rechecked everything and still don't see anything that would matter in this context, especially that the crash seems to happen within the executable, not one of the wine libs. Enigma denying access for gdb doesn't help (winedbg just prints more of the above on the second thread, the third one just looks like it's gathering crash data (calls within CreateToolhelp32Snapshot)).
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #14 from Fabian Maurer dark.shadow4@web.de --- You're on gentoo, so Wine is compiled yourself, correct? Can you give me the exact compile parameters and flags? Probably also the compiler version.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #15 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Fabian Maurer from comment #14)
You're on gentoo, so Wine is compiled yourself, correct? Can you give me the exact compile parameters and flags? Probably also the compiler version.
OK.
CFLAGS="-O2 -g -march=znver1 -pipe" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,relro"
binutils-2.37_p1 mingw64-runtime-9.0.0 gcc-11.2.0
(gcc and binutils same for mingw64)
https://bugs.winehq.org/show_bug.cgi?id=52676
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #16 from Fabian Maurer dark.shadow4@web.de --- Now I can reproduce it as well. The problem seems to be the combination of "-O2 -march=znver1". Can you try without "march" please?
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #17 from Rafał Mużyło galtgendo@o2.pl --- Well, removing '-march=znver1' "works", for a quite broken definition of "works", though the trial crashes relatively early with "GL_INVALID_OPERATION in glFlushMappedBufferRange(buffer is not mapped)", though that might be a mesa bug.
However it does work for awhile.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #18 from Rafał Mużyło galtgendo@o2.pl --- ...minor correction: while those mesa debug lines happen, the crash was my mistake - I've put the wrong d3dcompiler in the overrides; seems to work correctly (mesa lines and unimplemented stuff aside) with the correct version.
https://bugs.winehq.org/show_bug.cgi?id=52676
Chiitoo escomk3@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |escomk3@hotmail.com
--- Comment #19 from Chiitoo escomk3@hotmail.com --- Does it not crash for you still after a few bits of dialogue during the white screen?
Also, I did "some" build testing, looking at what 'znver1' brings in, and it looks like it's the 'bmi2' option that makes it very unhappy.
That is, something like '-march=znver1 -mno-bmi2' will work as well.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #20 from Rafał Mużyło galtgendo@o2.pl ---
Does it not crash for you still after a few bits of dialogue during the white screen?
Well, that's roughly what happens when you don't have that d3dcompiler override set. Otherwise, you should be fine.
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #21 from Fabian Maurer dark.shadow4@web.de --- Created attachment 72054 --> https://bugs.winehq.org/attachment.cgi?id=72054 Disasm of one affected function
So, I managed to find one affected function: gdi32/text.c:EnumFontFamiliesExW Attaching disassembly of EnumFontFamiliesExW.
Lines of note:
b8 02 00 00 00 mov eax,0x2 c4 e2 7b f7 95 64 c7 shrx edx,DWORD PTR [ebp-0x389c],eax ff ff
I also edited the crash handler to output the data of the illegal instruction, it changes randomly, here's 3 samples:
c4 e2 0f 8b bd 44 c4 e2 0f 8b cf 44 c4 e2 0f 8b e1 44
Seems like enigma screws up that shrx instruction.
https://bugs.winehq.org/show_bug.cgi?id=52676
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #22 from Fabian Maurer dark.shadow4@web.de --- Created attachment 72055 --> https://bugs.winehq.org/attachment.cgi?id=72055 Disassembly winmm/time.c
FWIW, also affects mulx. See attachment
https://bugs.winehq.org/show_bug.cgi?id=52676
--- Comment #23 from Rafał Mużyło galtgendo@o2.pl --- Above sucks a bit.
Anyway, about that other trial...
After recent patches that one works till it runs out of open file handles. As it's a WolfRPG game packed into a brick with enigma, there's a couple more filesystem redirections here.
The leak seems to happen during attempt to read a file from Data.wolf archive that's in the brick. More exactly, the read succeeds both by API and actual result, but the file handle the data was read from doesn't get closed.
Aside from that, I see something wacky: when the game looks for Data.wolf, instead of looking for it (via FindFirstFileEx/FindNextFile) from game dir down, it instead looks from the top of the absolute path down...I wonder if it works the same on Windows...
https://bugs.winehq.org/show_bug.cgi?id=52676
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #24 from Stefan Dösinger stefan@codeweavers.com --- Re your question on 55470, I don't think this bug is related. What seems to be going on here is that this DRM tool hooks Win32 API functions. With -march=znver1, gcc generates opcodes that Enigma doesn't understand and fails to hotpatch and/or relocate to the destination of the hook jump.
I think the short answer is "don't do that". Either don't make gcc generate opcodes that Windows doesn't use or don't run code that insists on modifying the machine code of the Windows API implementation.
The long answer is that DECLSPEC_HOTPATCH might help. It'll make 32 bit functions start with 8b ff 55 8b ec, which are easy to replace with a 5 byte jump (And windows uses that sequence a lot). Then gcc can put whatever it wants in the follow-up bytes. On 64 bit it is a bit more complicated. Win64 doesn't have a fixed prologue, it just promises that a few bytes ahead of the function are unused and the first instruction is a 2 byte instruction that can be atomically replaced. GCC will generate a 9 byte NOP at the start instead, which Enigma may or may not understand.
-
WineHQ Bugzilla