Newly created suspended process's EIP is failing only on Windows XP - EIP under kernel32.dll image?

Question

My program works flawlessly on Windows Vista Ultimate and Windows 7, however it fails on Windows XP.

First, my application creates a process of a system file, it calls

Answer 1

CreateProcess(CREATE_SUSPENDED) only do partial initialization. You may try to VirtualAllocEx() the EIP region and explicitly COMMIT it, and then VirtualProtectEx, of course this is a quick hack, you can have a test, I'm not sure whether this can fix the problem. BTW, what's your real purpose to do so? If you intend to hook at early stage of process execution, patch the entry point of PE header is better, since when instruction control flow reach the entry point, the process must have completed its initialization, however this also has its downside, e.g. TLS callback is invoked before the entry point get executed.

Answer 2

Creating a process with CREATE_SUSPENDED means the main process won't finish it's initialization before you run your code. the way the loader is implemented causes the different effects between XP and Vista/7, and since the CREATE_SUSPENDED documentation doesn't grantee any process initialization you can't really count on that method. the CREATE_SUSPENDED flag only states the process is created with the main thread suspended.
It's not exactly clear what the OP desires to accomplish, but a few methods to achive similar goals come to mind:

1. Write a debugger instead of remotely manipulating another process. a simple tutorial and code examples can be found Here. the debugger gets an event for every spawned thread, you could probably use that.

2. Modify the PE to execute your code before any other by either creating a new section for your code and placing a TLS entry in the PE to execute code inside the process's memory space. you're code will then run before the process's EntryPoint but after it was initialized.

3. Modify the PE and replace the EntryPoint in the PE header with your own code, just make sure you execute the original entry point yourself. some initalization will be missing but all the PE code sections will be loaded.

4. Inject a DLL into the process's memory address by either creating it suspended and loading a DLL from a different thread, or any other method. This article lists a few and you can Google for more. i'm not sure that'll work in all cases if you want to get the process initialized because of similar issues, but I do think that calling LoadLibrary will get you the desired efect. That is also a clean way to get code into another process and manipulate it while being more stealth than using a debugger.

5. You can also try scanning the entire memory for the code chunks you want to manipulate while the process is suspended, that might also work on XP.

6. You could try creating the process unsuspended and let it run for a short period of time before suspending the threads. after timing and a few tests you'll get a resonable feelling about how much time it takes to initialize. That's a bit risky but might work.

creating a debugger will be the easiest and most robust/generic method but will have the disadvtange of being easily detected (although you could use anti-anti-debugging tricks). loading a DLL will be the best way if you want to remain undetectable by the manipulated process (if it has any anti-debugging tricks) if you want more suggestions or recomendations for your specific needs please edit and describe in detail what exactly you want to accomplish as it is not clear from your question. a little more details about the program (is it native, or .net for example) would also be helpful.

EDIT: another speculation suggested by friend was that the kernel did not finish the process initialization by the time the syscall returns and you call VirtualQueryEx. he said calling WaitForSingleObject on the process's handle will return once the process is fully initialized and you could access all the information and resume the execution afterwards.