CreateProcessExW issue

[iconic]

Hello Mathias,

Figured I'd mention that if you supply a literal string as the lpCommandLine argument within CreateProcessExW you will receive an access violation guaranteed. To fix this inherent Windows issue with CreateProcessW problem you can just copy the lpCommandLine argument to the stack before calling the underlying Windows API CreateProcessW in your CreateProcessExW wrapper. If you don't feel that it's necessary since this is documented behavior of CreateProcessW you may want to let your users know that you are calling this API and that literal strings are not to be used.

MSDN says this about CreateProcessW()

CreateProcessW can modify the contents of this string. Therefore, this parameter cannot be a pointer to read-only memory (such as a const variable or a literal string). If this parameter is a constant string, the function may cause an access violation.

This Crashes:

Code: Select all

var
 si: STARTUPINFO;
 pi: PROCESS_INFORMATION;
begin
GetStartupInfoW(si);
CreateProcessExW(nil, 'calc.exe', nil, nil, False, 0, nil, nil, si, pi, 'Dummy.dll');
end;

This FIXES it:

Code: Select all

var
 lpBufW: Array [0..MAX_PATH] of WCHAR;
 si: STARTUPINFO;
 pi: PROCESS_INFORMATION;
begin
 ZeroMemory(@lpBufW, sizeof(lpBufW));
 lstrcpyW(@lpBufW, 'calc.exe');
 GetStartupInfoW(si);
 CreateProcessExW(nil, @lpBufW, nil, nil, False, 0, nil, nil, si, pi, 'Dummy.dll');
end;

--Iconic

[madshi]

You're right about this specific problem. But the madCodeHook documentation already says:

"The "CreateProcessEx" function basically works exactly like the well known Windows API "CreateProcess"."

Shouldn't that be good enough? I mean the same crash would occur if you called the win32 API CreateProcess directly.

[iconic]

I think your documentation is fine in stating that CreateProcessEx works like "CreateProcess" but "CreateProcessW" is different in behavior as opposed to "CreateProcessA" so it's misleading when it comes to the lpCommandLine argument. Some users may miss such small footnotes on MSDN that describe differences between the 2 function variants. This is the only reason I created this thread as I could see potential issues with users who want to simply use literal or constant strings while switching to CreateProcessExW. Well, as you said it should be good enough documentation as-is, just wanted to mention it since it'd be such a trivial thing to solve. I'm not saying it's madCodeHook's fault by any means since MSDN does describe the behavior perfectly (refer to my previous post)

--Iconic

[madshi]

Maybe I should simply work around the problem by copying the string internally to make CreateProcessExW not have the same issue as CreateProcessW.

[iconic]

That'd be great madCodeHook takes the complexity out of API hooking and DLL injection so why not a rudimentary issue with Windows CreateProcessW API As always Madshi, keep up the great work

I stated this in my first post since it's literally that simple as you know, saves the user from a nasty crash in the literal/constant string scenario

To fix this inherent Windows issue with CreateProcessW problem you can just copy the lpCommandLine argument to the stack before calling the underlying Windows API CreateProcessW in your CreateProcessExW wrapper.

--Iconic

[madshi]

Ok, will put it on my (long) to do list, thanks for the heads up.