When building for x86, I have to link with madCHook32mt.lib and madCHook32.lib for CopyFunction. For other functions I only need to link with madCHook32mt.lib. Not sure if it's related.
I've tested here on Win 7 x64 SP1 with both target builds of the same .exe (32-bit and 64-bit) and then tried both instances (32-bit and 64-bit) of Notepad to see if it was something related to WOW64 <-> Native execution but it doesn't appear to be. In any case it all worked perfectly fine for me here on my end. I used VS 2015 Community Edition to test and the latest MCH version. What version of MCH are you using?
The exact code I used (your code minus a small mod or two) is below:
I've rerun the demo on Windows 10 x64 20H2 and tested a 64-bit .exe compiled with madCHook64mt.lib - it continues to work as expected without issue here. I tested 3x with both the WOW64 version of Notepad as well as the Native 64-bit version of Notepad. Did you want me to upload my pre-built binary (.exe) for you in case you'd like to test on your end? I've allowed you to input the process id in the current test demo through the console window.
CopyFunction still fails for me on 64bit. WOW64 seems to be ok.
Here is my VS2019 test project (*** Edited out ***)
Thanks
***Edit*** I've downloaded your project but have also erased the link of your archive file on this forum, I have a copy locally but need to censor it due to it containing .lib files which anyone can use. Please delete your original link files at your earliest convenience. I'm sure this was done by accident but please refrain from this in the future. Thank you.
I've uploaded the pre-built 64-bit binary here https://easyupload.io/mo975t
You may need to disable Windows Defender and/or other security apps in order to download it, it's being detected as a virus likely because MCH was compiled into it and it's using APIs like WriteProcessMemory and CreateRemoteThread etc. It's unsigned so this is also likely part of the issue with AV I imagine. Run in a VM always, not that you can't trust me, but it's common practice when you're downloading any foreign executable. It's a shame that heuristics are lost when digital signatures aren't present but trusted when they are... Let me know if it works for you, I still can't reproduce your issue however which is unfortunate. Anyhow, I'm sure you know this of course.
I'll build your project and see if it's giving me the same issue on x64 and report back. Thanks for uploading it!
P:S: The archive is password protected and the pass = madshi.net
Thanks for deleting your project online containing the .lib files. Much appreciated. Accidents happen and whether you were in a rush or perhaps forgot that this can be viewed publicly... things happen, but thanks for your quick deletion of such sensitive files.
So... according to your last post, my demo worked for you. Have you tried my code posted a few days ago in your VS IDE? Switched .lib versions etc.? Basically, am I still needing to test your specific project or was it an issue on your end that you believe? I've also noticed some differences in your forum posted code and the one you've uploaded (i.e> auto remote_proc = reinterpret_cast<LPTHREAD_START_ROUTINE>) on the CopyFunction() API. Have you tried the code without such c++ "magic"? If you have and it's an issue then that's likely either a compiler difference (possibly) or an MCH .lib issue. Hard to say. I primarily compile with VS 2015 Community Edition but do have other versions, around 4 actually.
I'm just not sure why the same code you originally shared works fine in my binary build but not yours. Also, I'm not aware of any recent .lib files having an issue with CopyFunction() but perhaps I need to check it out with an older version. I simply don't see why you're experiencing different results than me using _your_ posted code. If you want I can securely send you the project that seems to have worked for you, let me know please. Thanks!