https://bugs.winehq.org/show_bug.cgi?id=50784
Bug ID: 50784 Summary: wine crashes trying to call the entrypoint of an ILONLY exe in a 64-bit process Product: Wine Version: 6.3 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: madewokherd@gmail.com Distribution: ---
Created attachment 69591 --> https://bugs.winehq.org/attachment.cgi?id=69591 test exe
When running a test exe in 64-bit mode, I get this error:
0024:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x40231e
According winedump, 0x40231e is the entry point of the image. It's a 32-bit ILONLY exe.
To reproduce, run the attached exe with wine64.
https://bugs.winehq.org/show_bug.cgi?id=50784
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com Keywords| |download, testcase
https://bugs.winehq.org/show_bug.cgi?id=50784
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |wineserver
--- Comment #1 from Esme Povirk madewokherd@gmail.com ---
From a +server log:
0024: create_file( access=80100000, sharing=00000005, create=1, options=00000060, attrs=00000000, objattr={rootdir=0000,attributes=00000040,sd={},name=L"\??\Z:\home\wine\wine-mono\tests\tests-x86_64\vararg_pinvoke.exe"}, filename="/home/wine/.wine/dosdevices/z:/home/wine/wine-mono/tests/tests-x86_64/vararg_pinvoke.exe" ) 0024: create_file() = 0 { handle=001c } ... 0024: create_mapping( access=000f000d, flags=01000000, file_access=00000001, size=00000000, file_handle=001c, objattr={} ) 0024: create_mapping() = 0 { handle=0020 } ... 0024: get_mapping_info( handle=0020, access=00000001 ) 0024: get_mapping_info() = 0 { size=00006000, flags=01800000, shared_file=0000, image={base=00400000,entry_point=0040231e,map_size=00006000,stack_size=00100000,stack_commit=00001000,zerobits=00000000,subsystem=00000003,subsystem_minor=0000,subsystem_major=0004,osversion_major=0004,osversion_minor=0000,image_charact=010e,dll_charact=0000,machine=014c,contains_code=1,image_flags=00,loader_flags=00000001,header_size=00000200,file_size=00000800,checksum=00000000,cpu=x86} }
If I understand this correctly, image_flags here should have 02 set, indicating an ILONLY image.
https://bugs.winehq.org/show_bug.cgi?id=50784
--- Comment #2 from Esme Povirk madewokherd@gmail.com --- Created attachment 69596 --> https://bugs.winehq.org/attachment.cgi?id=69596 work-around patch
This is caused by the version check in load_clr_header, the runtime version in the image is version 2.00 (based on winedump -j clr), but wineserver expects at least 2.05.
https://bugs.winehq.org/show_bug.cgi?id=50784
--- Comment #3 from Esme Povirk madewokherd@gmail.com --- ECMA-335 II.25.3.3 lists the "current" version as 2.0, so I'm not sure where the expectation of 2.05 comes from.
https://bugs.winehq.org/show_bug.cgi?id=50784
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED
--- Comment #4 from Esme Povirk madewokherd@gmail.com --- It seems I made a mistake in my testing on Windows. I had a 64-bit dll with the exe instead of a 32-bit one. Windows is loading this in a 32-bit process, the same as Wine.
Arguably, wine/wine64 should select the correct version, but that's a more general known issue. From CreateProcess Wine's behavior is correct.
https://bugs.winehq.org/show_bug.cgi?id=50784
--- Comment #5 from Esme Povirk madewokherd@gmail.com --- This means that on Windows and Wine, many of Wine Mono's test cases were only being run as 32-bit. We only noticed in this case because this one happened to load a native dll.
https://bugs.winehq.org/show_bug.cgi?id=50784
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Esme Povirk madewokherd@gmail.com --- Closing invalid.