Largely based on a patch by Nikolay Sivov for NtGetNextProcess().
Signed-off-by: Paul Gofman <pgofman@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of requiring the SD owner to match the token user.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44691
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As some thread may use a different desktop from their process.
This fixes the user32 win tests, which leaks a desktop that never gets
closed. The test_shell_window test creates a new desktop, which spawns
explorer.exe process, incrementing the desktop user count to 1, then
associates the desktop to a thread, which closes it on exit.
Never the user count is incremented to 2, and closing the thread desktop
doesn't either check whether the desktop process should be terminated.
Reversely, it is possible to create a desktop, associate it with a
thread /and/ a process, and this time the desktop process would be
terminated when the process exits, although the thread may still be
using it.
Tracking the users per thread is more robust and fixes the problem as
set_thread_desktop increments the desktop user count, and thread exit
decrements it.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
test_exit_process_async() essentially validates this. The only reason it
currently succeeds (instead of incorrectly returning ERROR_BROKEN_PIPE) is that
due to the use of DuplicateHandle() the source handle is never actually closed.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We never pass a handle to this object to the client anyway.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
WoW64 process has two separate contexts:
- x86 context used most of the time (e.g. by application code)
- x86_64 context used by system when it quits x86 emulation and jumps to
the kernel code
A notable exception are debug registers - their state is shared. Some
debuggers make use of that fact and sets/gets debug registers of x86
processes using x86_64 thread context.
Add support for setting and getting debug registers using x86_64
thread context. Getting other registers is allowed too and will return
values from x86 thread context.
Fixes hardware breakpoints in IDA 7.0 disassembler (x86_64 app) when
debugging x86 (32 bit) applications.
Signed-off-by: Rafał Harabień <rafalh92@outlook.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
I've left another case of returning STATUS_PROCESS_IS_TERMINATING since
that's not covered by the tests.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50704
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This can happen if the async is terminated while there is no thread to queue
the APC to (as in the relevant test), or if the client dies before getting the
APC, or before transferring the APC results back to the server.
This also fixes a leak of async objects present since 61abc500f5. If a process
dies while accept asyncs are pending, the asyncs will be terminated but will
not find a valid thread to queue the APC to, and thus async_set_result() and
the completion callback are never called.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, RegUnLoadKey(HKEY_USERS, "S-1-5-21-0-0-0-1000") erases all
HKCU registry. The call is actually done by a certain installer.
Signed-off-by: Akihiro Sagawa <sagawa.aki@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard