[Win32 C++] VirtualFreeEx() error after WriteProcessMemory() success. But not always.
-
First time on this forum. Hello :) I wish my first post was shorter. And forgive the obscure title. It's hard to nail it short - I don't even know what the actual problem is. Here's a quick description of what happens: 1) My_exe launches a 3rd_party_exe via
CreateProcess(). The main process thread is in a suspended state. 2) IWriteProcessMemory()in the 3rd_party_exe process, and copy in it an absolute path, pointing to a dll I wrote. 3) ICreateRemoteThread()to have the dll loaded. It's the trite and dull LoadLibraryA() method everybody knows. This secondary thread is created not suspended. 4) I do stuff... My_exe opens a named and synchronous pipe. My dll inside 3rd_party_exe will connect to it. My_exe writes down the pipe a path pointing to a text file. My dll inside 3rd_party_exe retrieves such path, then closes the pipe. Control is back to My_exe, which disconnects the pipe and closes the handle. No errors. Never an error. 5) My_exe nowWaitForSingleObject()that the (remote) thread from point 3 gracefully comes to an end. And it always does. When that thread is done, my DllMain() has returned. I do not unload my dll from the 3rd_party_exe process. I need it to stay loaded. 6) Time to cleanup. With the remote thread closed, the memory I wrote in the process is no longer needed. So I callVirtualfreeEx()to deallocate it. 7) Only now I let the main process thread run (remember? it was kept 'suspended' sinceCreateProcess()). 8) I do not need to wait for 3rd_party_exe to terminate. My_exe can close. ICloseHandle()the main thread handle and the process handle (fromCreateProcess()), in that order. 9) End. What I described works -- *almost* always. I check for errors after every API call. When there's a problem it'sVirtualFreeEx()(from point 6) reporting Access Violation (0xc0000005). The puzzling thing is thatWriteProcessMemory()is always successful. You see, I wouldn't advance all the way toVirtualFreeEx()otherwise :confused: Any idea what might be causing this? I can repeat this procedure on a number of 3rd_party_exe programs. None crashes, except the one that does (lol, sorry). I thought that perhaps this crashy program is doing something special as it starts... something that prevents me from accessing my own memory (the one from -
First time on this forum. Hello :) I wish my first post was shorter. And forgive the obscure title. It's hard to nail it short - I don't even know what the actual problem is. Here's a quick description of what happens: 1) My_exe launches a 3rd_party_exe via
CreateProcess(). The main process thread is in a suspended state. 2) IWriteProcessMemory()in the 3rd_party_exe process, and copy in it an absolute path, pointing to a dll I wrote. 3) ICreateRemoteThread()to have the dll loaded. It's the trite and dull LoadLibraryA() method everybody knows. This secondary thread is created not suspended. 4) I do stuff... My_exe opens a named and synchronous pipe. My dll inside 3rd_party_exe will connect to it. My_exe writes down the pipe a path pointing to a text file. My dll inside 3rd_party_exe retrieves such path, then closes the pipe. Control is back to My_exe, which disconnects the pipe and closes the handle. No errors. Never an error. 5) My_exe nowWaitForSingleObject()that the (remote) thread from point 3 gracefully comes to an end. And it always does. When that thread is done, my DllMain() has returned. I do not unload my dll from the 3rd_party_exe process. I need it to stay loaded. 6) Time to cleanup. With the remote thread closed, the memory I wrote in the process is no longer needed. So I callVirtualfreeEx()to deallocate it. 7) Only now I let the main process thread run (remember? it was kept 'suspended' sinceCreateProcess()). 8) I do not need to wait for 3rd_party_exe to terminate. My_exe can close. ICloseHandle()the main thread handle and the process handle (fromCreateProcess()), in that order. 9) End. What I described works -- *almost* always. I check for errors after every API call. When there's a problem it'sVirtualFreeEx()(from point 6) reporting Access Violation (0xc0000005). The puzzling thing is thatWriteProcessMemory()is always successful. You see, I wouldn't advance all the way toVirtualFreeEx()otherwise :confused: Any idea what might be causing this? I can repeat this procedure on a number of 3rd_party_exe programs. None crashes, except the one that does (lol, sorry). I thought that perhaps this crashy program is doing something special as it starts... something that prevents me from accessing my own memory (the one fromAccording to #5, you are doing all of this piping and text file retrieving inside the DllMain function? That's a recipe for errors right there. You are never supposed to do anything but the most rudimentary initialization inside DllMain.
The difficult we do right away... ...the impossible takes slightly longer.
-
According to #5, you are doing all of this piping and text file retrieving inside the DllMain function? That's a recipe for errors right there. You are never supposed to do anything but the most rudimentary initialization inside DllMain.
The difficult we do right away... ...the impossible takes slightly longer.
Thanks. I'm unaware of specific limitations to observe or -in general- 'good conducts' to keep while inside DllMain(). I'll trust your input, and seek documentation about it later. As for the immediate... ... since the main process' thread is kept suspended and I alone decide when to let it run... ... would it be safe to
CreateThread()from inside DllMain() and move all my code in there? Or isCreateThread()another bad practice when in the context of DllMain()? If you know better alternatives I'll listen. Thank you again for the help. -
Thanks. I'm unaware of specific limitations to observe or -in general- 'good conducts' to keep while inside DllMain(). I'll trust your input, and seek documentation about it later. As for the immediate... ... since the main process' thread is kept suspended and I alone decide when to let it run... ... would it be safe to
CreateThread()from inside DllMain() and move all my code in there? Or isCreateThread()another bad practice when in the context of DllMain()? If you know better alternatives I'll listen. Thank you again for the help.You MIGHT be able to get away with CreateThread(). I'm not sure myself. Here's a very good post about the subject: http://www.voyce.com/index.php/2009/12/03/dont-do-anything-in-dllmain-please/[^] It also contains a link to an MSDN article that explains it all.
The difficult we do right away... ...the impossible takes slightly longer.
-
You MIGHT be able to get away with CreateThread(). I'm not sure myself. Here's a very good post about the subject: http://www.voyce.com/index.php/2009/12/03/dont-do-anything-in-dllmain-please/[^] It also contains a link to an MSDN article that explains it all.
The difficult we do right away... ...the impossible takes slightly longer.
*reading* Hmm. Looks like that, to program today, one has to have the knack of the lawyer as well. Can't do this, Don't do that, But this is okay if, Unless, Just watch for, ... :) Jokes aside, now. It would appear that pretty much anything coming not from kernel32 is not to be invoked from anywhere/anystage_of DllMain(). And even so, some kernel functions directly/indirectly cause the loading of more libraries... which is another taboo. Fine. I'm developing for WinXP 32bit. That's the oldest platform I target. In my case my best option is to resort to the APC mechanism. For example the
SetWaitableTimer()(exported by kernel32.dll) can be safely called from DllMain(), and *it* can invoke an APC function on completion (completion which can occur 1) immediately, and 2) autonomously - no need for external inputs). It's perfect. Once inside the APC function -> I can do anything I want. I should be on the right track this time ;) But I'll try this out tomorrow. Must sleep now. Thank you very much for the informative links :thumbsup: (vote: 4) Feel free to add anything else you think might help. A good night to you. -
*reading* Hmm. Looks like that, to program today, one has to have the knack of the lawyer as well. Can't do this, Don't do that, But this is okay if, Unless, Just watch for, ... :) Jokes aside, now. It would appear that pretty much anything coming not from kernel32 is not to be invoked from anywhere/anystage_of DllMain(). And even so, some kernel functions directly/indirectly cause the loading of more libraries... which is another taboo. Fine. I'm developing for WinXP 32bit. That's the oldest platform I target. In my case my best option is to resort to the APC mechanism. For example the
SetWaitableTimer()(exported by kernel32.dll) can be safely called from DllMain(), and *it* can invoke an APC function on completion (completion which can occur 1) immediately, and 2) autonomously - no need for external inputs). It's perfect. Once inside the APC function -> I can do anything I want. I should be on the right track this time ;) But I'll try this out tomorrow. Must sleep now. Thank you very much for the informative links :thumbsup: (vote: 4) Feel free to add anything else you think might help. A good night to you.I'm glad you found it useful. Good luck with your implementation.
The difficult we do right away... ...the impossible takes slightly longer.
