https://bugs.winehq.org/show_bug.cgi?id=51264
Bug ID: 51264 Summary: GUI exe receives invalid StdOutput HANDLE if launched via ShellExecuteEx Product: Wine Version: 6.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: brendan@redmandi.com Distribution: ---
Created attachment 70142 --> https://bugs.winehq.org/attachment.cgi?id=70142 Source code for the primary exe to recreate the issue
It is possible for a child process to inherit an invalid hStdOutput HANDLE if the PE header has the subsystem value of IMAGE_SUBSYSTEM_WINDOWS_GUI and it is launched via ShellExecuteEx.
It also requires the primary process to be launched via: - 'wine' if it is a PE32+ executable; or - 'wine64' if it is a PE32 executable
Attached are two source files that can be used to recreate the issue: 1. main.c (the primary process); and 2. child.c (the child process)
Compile with: x86_64-w64-mingw32-gcc -o main.exe main.c x86_64-w64-mingw32-gcc -o child.exe child.c -mwindows
and run with: wine main.exe
The child.exe creates a file called 'stdout.log' that dumps the STD_OUTPUT_HANDLE value and its FileType. Under wine, this is: StdOutput: 14, Type: 1 and under Windows, it is: StdOutput: 0, Type: 0
I first ran in this this issue when running Elite Dangerous from Proton 6.3 (i.e. wine version 6.3) - but my investigations show this still occurs with git commit 6b277dc89d55.
https://bugs.winehq.org/show_bug.cgi?id=51264
--- Comment #1 from Brendan McGrath brendan@redmandi.com --- Created attachment 70143 --> https://bugs.winehq.org/attachment.cgi?id=70143 Source code for the child exe to recreate the issue
https://bugs.winehq.org/show_bug.cgi?id=51264
--- Comment #2 from Brendan McGrath brendan@redmandi.com --- Investigating this further, I found that when running this test program with 'wine', hStdOutput in 'main.exe' is assigned the value of 0x14 (see 'create_process_params').
This value is then passed to 'child.exe', but it is an invalid handle (because handles are not being inherited).
During LdrInitializeThunk of 'child.exe', handle 0x14 is then used (in a collision) for the CurrentDirectory value in RtlSetCurrentDirectory_U.
As a result, hStdOutput in 'child.exe' now points to a directory and any attempt to write to the console now causes an error (and a crash when using wine-mono).
I don't see this problem when running with 'wine64', as hStdOutput in 'main.exe' is assigned the value of 0x30 (which does not result in a collision) and msvcrt_init_io performs a clean-up (thus hStdOutput is set to 0, which is the same value seen when running this test program on Windows). But this appears to be by chance rather than design.
I also don't see this problem when the PE header in child.exe has a subsystem value of IMAGE_SUBSYSTEM_WINDOWS_CUI (as opposed to GUI) because init_console runs 'AllocConsole' under this condition (which results in a new hStdOutput value being assigned; see 'init_console_std_handles').
I can see in server/process.c (under 'new_process') that the handles will be duplicated under the following condition: if (!(req->flags & PROCESS_CREATE_FLAGS_INHERIT_HANDLES) && info->data->console != 1)
So I believe create_process_params can be modified to not pass the value of the StdHandles if 'inherit' is false and 'flags' has CREATE_NEW_CONSOLE switched on (as under this condition, the StdHandles never appear to be inherited).
https://bugs.winehq.org/show_bug.cgi?id=51264
--- Comment #3 from Brendan McGrath brendan@redmandi.com --- The following patch has been submitted: https://www.winehq.org/pipermail/wine-devel/2021-June/188791.html
https://bugs.winehq.org/show_bug.cgi?id=51264
Brendan McGrath brendan@redmandi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
https://bugs.winehq.org/show_bug.cgi?id=51264
Brendan McGrath brendan@redmandi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #70142|0 |1 is obsolete| |
--- Comment #4 from Brendan McGrath brendan@redmandi.com --- Created attachment 70186 --> https://bugs.winehq.org/attachment.cgi?id=70186 Source code for the primary exe to recreate the issue
https://bugs.winehq.org/show_bug.cgi?id=51264
Brendan McGrath brendan@redmandi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #70143|0 |1 is obsolete| |
--- Comment #5 from Brendan McGrath brendan@redmandi.com --- Created attachment 70187 --> https://bugs.winehq.org/attachment.cgi?id=70187 Source code for the child exe to recreate the issue
https://bugs.winehq.org/show_bug.cgi?id=51264
--- Comment #6 from Brendan McGrath brendan@redmandi.com --- I've created new tests that will check both GUI and CUI exes, and also check what happens when inherit is TRUE and when it is FALSE.
All tests use the CREATE_NEW_CONSOLE flag.
Compile with: x86_64-w64-mingw32-gcc -o main.exe main.c x86_64-w64-mingw32-gcc -o child.exe child.c x86_64-w64-mingw32-gcc -o child_gui.exe child.c -mwindows
Run with: wine main.exe
This will output a testx.log file for each test (where the 'x' represents the test number). The contents of each testx.log file is: 1. StdOutput = GetStdHandle(STD_OUTPUT_HANDLE); 2. params->hStdOutput = NtCurrentTeb()->ProcessEnvironmentBlock->ProcessParameters->hStdOutput 3. hStdOutput from GetStartupInfoA 4. hStdOutput from GetStartupInfoW
Running under Wine, I get the following results: *** Primary process*** StdOutput: 14, Type: 2
*** Child process *** **inherit true** *CUI* StdOutput: 50, Type: 2 params->hStdOutput: 50, Type: 2 siA.hStdOutput: 50, Type: 2 siW.hStdOutput: 14, Type: 2
*GUI* StdOutput: 14, Type: 2 params->hStdOutput: 14, Type: 2 siA.hStdOutput: 14, Type: 2 siW.hStdOutput: 14, Type: 2
**inherit false** *CUI* StdOutput: 44, Type: 2 params->hStdOutput: 44, Type: 2 siA.hStdOutput: 44, Type: 2 siW.hStdOutput: 14, Type: 1
*GUI* StdOutput: 14, Type: 1 params->hStdOutput: 14, Type: 1 siA.hStdOutput: 14, Type: 1 siW.hStdOutput: 14, Type: 1
And running under Windows I get: *** Primary process*** StdOutput: 60, Type: 2
*** Child process *** **inherit true** *CUI* StdOutput: 6c, Type: 2 params->hStdOutput: 6c, Type: 2 siA.hStdOutput: ffffffff, Type: 0 siW.hStdOutput: 0, Type: 0
*GUI* StdOutput: 0, Type: 0 params->hStdOutput: 0, Type: 0 siA.hStdOutput: ffffffff, Type: 0 siW.hStdOutput: 0, Type: 0
**inherit false** *CUI* StdOutput: 58, Type: 2 params->hStdOutput: 58, Type: 2 siA.hStdOutput: ffffffff, Type: 0 siW.hStdOutput: 0, Type: 0
*GUI* StdOutput: 0, Type: 0 params->hStdOutput: 0, Type: 0 siA.hStdOutput: ffffffff, Type: 0 siW.hStdOutput: 0, Type: 0
So it looks like the StdHandles are never inherited on Windows when the CREATE_NEW_CONSOLE flag is used.
I'll also need to check if the CREATE_UNICODE_ENVIRONMENT flag is impacting the different values between siA and siW.
https://bugs.winehq.org/show_bug.cgi?id=51264
Brendan McGrath brendan@redmandi.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |7539dd607b5a9840d13849a0668 | |d9e8982e20c8c Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #7 from Brendan McGrath brendan@redmandi.com --- This is fixed as of commit 7539dd607b5a9840d13849a0668d9e8982e20c8c (which will be in wine v6.12).
https://bugs.winehq.org/show_bug.cgi?id=51264
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.12.
https://bugs.winehq.org/show_bug.cgi?id=51264
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6.0.x
https://bugs.winehq.org/show_bug.cgi?id=51264
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|6.0.x |---
--- Comment #9 from Michael Stefaniuc mstefani@winehq.org --- Removing the 6.0.x milestone from bug fixes included in 6.0.3.