Actually getting code to run in a foreign process of different architecture is difficult. For an x86 process interacting with an x64 process, CreateRemoteThread always fails, even if the given start address points to x64 code and the given parameter can be safely zero extended (by which I mean that the top bit isn't set - if it was then you'd have to choose between zero extension and sign extension). Getting around this is an interesting problem. One way would be to use the aforementioned Heaven's Gate to jump from x86 code to x64 code, then create the thread, then jump back to x86 code, but there is a major problem with this approach: an x86 process doesn't have a 64-bit version of kernel32.dll loaded, and hence doesn't have a 64-bit version of CreateRemoteThread available to be called - the only available 64-bit functions are the undocumented ones of ntdll.dll (NtCreateThread)