On WoA, x86 process failed to inject x64 libraries to x64 process

[patronumme]

Describe the bug
Currently Detours users should call DetourUpdateProcessWithDll + DetourProcessViaHelperDllsW to inject dlls into target processes. DetourUpdateProcessWithDll is called to injection dlls to the target process with the same arch of the current process. And I've confirmed a x64 process can call DetourUpdateProcessWithDll directly to inject dlls to a64 process, and vice versa. If DetourUpdateProcessWithDll failed, the users should call DetourProcessViaHelperDllsW to start a helper process "rundll32.exe" with the same arch of the target process, and call DetourUpdateProcessWithDll in the helper process.
On WoA, x64 / a64 process can start C:\Windows\SysWOW64\rundll32.exe to be the x86 helper process. And x86 process can start C:\Windows\System32\rundll32.exe to be a64 helper process. However x86 process failed to start a x64 helper process.

The "C:\Windows\System32\rundll32.exe" is an arm64x executable which can be start with arm64 process or x64 process. By default a x64 process starts rundll32.exe, the process will be x64 and an a64 process starts an a64 process. But a x86 process will always starts a64 process. If I need to start a x64 process I need to run "cmd.exe /C start /machine:amd64 rundll32.exe ...", but this is not what DetourProcessViaHelperDllsW does and won't fix my problem because what I started with CREATED_SUSPENDED flag is the cmd process instead of the rundll32 process.

Based on code analysis I see DetourProcessViaHelperDllsW always uses the first dll path in argument rlpDlls. I think a proper fix would be to keep rlpDlls containing x64 dll paths to be written to the payload, but set an a64 dll path to be loaded by rundll32.exe. (This is a possible fix and I have tested it worked for me)