This will help separate debug info files lookup from their actual
loading once found and correctly matched.
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
- SymLoadModules flags (SLMFLAG_VIRTUAL and SLMFLAG_NO_SYMBOLS),
- handling of load details (SymType, ImageName vs LoadedImageName,
various instances of module name).
Signed-off-by: Eric Pouech <epouech@codeweavers.com>
Dragon Naturally Speaking 12.5 manually validates that the custom action server
is elevated.
One might imagine that the right approach here is to add a manifest to msiexec;
however, msiexec does not always trigger a UAC prompt on Windows.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51143
Like all other verbs, the actual command line template is specified in the
registry. The elevation seems to be hardcoded into shell32 for this specific
verb.
The Foobar2000 installer requires administrator privileges, and elevates itself
in this way.
Based on a patch by Michael Müller.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50727
Consider a thread A running waiting_item_cancelable_callback() and a thread B running queue_cancel_item(),
which is the scenario from canceling a work item right after it gets submitted by RtwqPutWaitingWorkItem().
When the invoke_async_callback() call in queue_cancel_item() for item key with WAIT_ITEM_KEY_MASK in
thread B runs before the queue_release_pending_item() in waiting_item_cancelable_callback() in thread
A, the async callback is called the first time in queue_cancel_item() with RTWQ_E_OPERATION_CANCELLED,
then a second time in waiting_item_cancelable_callback(). We should check in queue_release_pending_item()
whether an item is already removed by queue_cancel_item() before calling async callbacks.
A different scenario could happen for scheduled_item_cancelable_callback() with the function ends
up calling its async callback even after it has been canceled by queue_cancel_item().
Consider a thread A running scheduled_item_cancelable_callback() and a thread B running queue_cancel_item(),
which is the scenario from canceling a work item right after it gets submitted by RtwqScheduleWorkItem().
When the CloseThreadpoolTimer() call in queue_cancel_item() in thread B runs before the queue_release_pending_item()
in scheduled_item_cancelable_callback() in thread A, scheduled_item_cancelable_callback() ends up
calling work_item_Release() and CloseThreadpoolTimer() is called again for the same timer object. So
the thread pool timer object end up getting released while the scheduled_item_cancelable_callback()
is running, triggering the '!object->num_running_callbacks' assertion in tp_object_release(). This
is actually a double free but the assertion happens before the second free could happen. The same
thing could happen for thread pool wait objects as well.
Fix mf and mfmediaengine tests sometimes trigger the '!object->num_running_callbacks' assertion.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55724
An extension of 3985b7c5. Opening the device for the Touch Bar on
older MacBooks also triggers a permission prompt, so for now it makes
sense to restrict the devices we open.
