[PATCH] plugplay: Broadcast WM_DEVICECHANGE message asynchronously.

[Arkadiusz Hiler]

On Mon, Feb 15, 2021 at 08:42:00PM +0100, Rémi Bernon wrote:
> It may otherwise trigger a nasty race condition, where:
> 
> 1) For explorer.exe to register the CLSID_ShellWindows classes, it
>    needs RpcSS service to be started,
> 
> 2) services.exe may start WinePlugPlay service group first, waiting for
>    its startup to complete,
> 
> 3) during startup and early device enumeration, hidclass.sys may call
>    IoSetDeviceInterfaceState, which calls plugplay_send_event [1],
> 
> 4) plugplay_send_event tries to broadcast a WM_DEVICECHANGE message with
>    BSF_QUERY, waiting for the individual threads to reply,
> 
> 5) which times-out because window threads are waiting on explorer.exe
>    to create its desktop window and reply to the WM_NULL SendMessage.
> 
> This happens more likely as there is threads with message queues
> being started, each waiting on the desktop window to reply. Usually
> explorer.exe is able to reply to some messages with the implicit
> message processing while creating its window, but not all of them.
> 
> [1] Not completely sure how, it looks like some RPC too, but before
>     RpcSs is started?
> 
> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>

FWIW, I've checked this on Windows with a 2 copies of the same program
that returns BROADCAST_QUERY_DENY for anything WM_DEVICECHANGE.

DBT_DEVICEARRIVAL, DBT_DEVICEREMOVECOMPLETE and DBT_DEVNODES_CHANGED
generated by plugging in a USB BD Drive and inserting/ejecting a disk
reached both instances.

I guess BSF_QUERY should be used only for the wParam values that are
documented as cancellable in the "return value" section on MSDN (you
have to check the respective DBT_* docs, not the WM_DEVICECHANGE).

-- 
Cheers,
Arek