Issue with suspended process

[Jonathan Doron]

Hi all,

I have an application that is creating a process suspended and then
using detours modifies the imports of the new process prior to
resuming it (the application is called Tracker.exe and is part
of MS toolchain, it can be retrieved in MS EWDK package)

The application does not work as it should on Wine, as the DLL its
trying to inject to the new process is not getting loaded, I tracked
down the problem here are the technical details:

When a new process is created, after all the other set-ups its running
the function:
dlls/ntdll/server.c!server_init_process_done

This function sets up the handlers for the different signals
(signal_init_process) and makes a wine_server_call init_process_done.

In the wine server function server/process.c!init_process_done a check
is made to see if the
thread of the process needs to be suspended (stop_thread_if_suspended)
and indeed when
a process is created with the CREATE_SUSPENDED flag, thread->suspend
== 1,  process->suspend == 0, and the process state is done at this
point).

This makes the wine_server call to stop_thread which will send a
SIGUSR1 signal to the new process.

The new process however still have the signals in a block state, thus
not processing the signal and putting it into a pending state.

The next thing that happens is LdrInitializeThunk continues and fixing
up the EXE module imports, this is not the same behavior as Windows in
which the Ldr only starts running after the thread has
resumed.

Only later signals are being unblocked and then the thread enters a
suspended state, the function
which unblocks the signals today is attach_process_dlls

The interesting thing is that in the past Wine behavior was correct
and the change that basically broke it is commit:

commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171
Author: Alexandre Julliard 
Date:   Mon Nov 19 14:27:07 2007 +0100

ntdll: Unblock signals in process init only after the dlls have
been imported.

Unfortunately though there I could not find any reason why the change
was made or if there is any bug that it fixed back then (2007) .

I was thinking that perhaps in order to resolve the problem and be
closer in the behavior to Windows would be to unblock the signals just
before server_init_process_done returns.

Please let me know if you have any other questions, will be happy to
resolve this now that we have all the information laid out.

Thanks,
-- Jon.

[Stefan Dösinger]

Hi,

On 24/08/17 16:41, Jonathan Doron wrote:
> The next thing that happens is LdrInitializeThunk continues and fixing
> up the EXE module imports, this is not the same behavior as Windows in
> which the Ldr only starts running after the thread has
> resumed.

Depending on what you want to do in the end you may be able to work
around the issue by adding a LoadLibraryA("Whatever_injected.dll")
somewhere in the init code. That might allow you to use your tool. It
helped when I was trying to use pixwin from the DX SDK a while ago.
> commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171
> Author: Alexandre Julliard <[e-mail]
> >
> Date:   Mon Nov 19 14:27:07 2007 +0100
>
> ntdll: Unblock signals in process init only after the dlls have
> been imported.

Alexandre is on vacation at the moment as far as I know. He might reply
later if he notices the mail in his return inbox flood :-) .

bugs.winehq.org tracks which commit fixed a bug, but unfortunately that
system was not in place in 2007.

Stefan