https://bugs.winehq.org/show_bug.cgi?id=48231
--- Comment #10 from Paul Gofman gofmanp@gmail.com --- (In reply to Paul Gofman from comment #9)
Or maybe better instead could you please run "objdump -d <wine installation path>/lib/wine/ntdll.so >dump.txt" for both working release and non working one and compress / attach the resulting files here?
Never mind, I've got the linked demo and reproduced the problem on Winehq build. As expected, the problem is due to -fcf-protection build flag. This happened to be a 64 bit app, so byte sequence is a bit different, but it does not matter.
Good build: 000000007bca8bf0 <LdrFindResource_U>: 7bca8bf0: 48 8d a4 24 00 00 00 lea 0x0(%rsp),%rsp 7bca8bf7: 00 7bca8bf8: 55 push %rbp ...
-fcf-protection build: 7bca9f80: 48 8d a4 24 00 00 00 lea 0x0(%rsp),%rsp 7bca9f87: 00 7bca9f88: f3 0f 1e fa endbr64 7bca9f8c: 55 push %rbp ...
The function has DECLSPEC_HOTPATCH (ms_hook_prologue) attribute set. The second snippet can give an idea how useful enforcing -fcf-protection with Wine currently is from the point of view of CET readiness.
The only fix I can imagine is not building Wine with -fcf-protection. This serves no technical purpose anyway, Wine is not going to work in CET enabled environment even if built with -fcf-protection flag. Many applications are currently broken with this distribution build flag while work fine without.
The only workaround for now is to find some build of Wine which does not use -fcf-protection flags, or build Wine from source.
This bug is a duplicate of Bug #48161.