Thread: CreateProcess variable definition

When calling CreateProcess you can use the StartupInfo and ProcessInformation structures to specify/retrieve some extra information about the process being created. In a lot of examples you'll see something like this:

Code:

    STARTUPINFO si;
    PROCESS_INFORMATION pi;

    ZeroMemory( &si, sizeof(si) );
    si.cb = sizeof(si);
    ZeroMemory( &pi, sizeof(pi) );

    CreateProcess(...);

Which is kind of surprising to me since I don't see any remarks about this on the corresponding MSDN page.

I understand that if you're creating a process that makes use of the StartupInfo struct it is important to make sure that StartupInfo struct being passed doesn't contain any garbage data. So even if you don't need to specify any StartupInfo options this struct should be zero'd if the process being created depends on it.

But this doesn't seem to be the case with the ProcessInformation struct. The system will fill all the members of this struct with the appropriate information and it's up to the caller to decide what to do with it.

Question 1: If you're absolutely certain that the process being created will not do anything with the StartupInfo struct, is it safe to pass it to CreateProcess while containing garbage data?

Question 2: Why zero the ProcessInformation struct before calling CreateProcess when the system will always fill this struct with the appropriate information? Shouldn't it be perfectly fine to pass this struct while it contains garbage data in any case?

Question 3: In the situation described above is it correct to define/declare these structs as such before calling CreateProcess?

Code:

    STARTUPINFO si = { sizeof(si) };
    PROCESS_INFORMATION pi;

    CreateProcess(...);

1/2 - I'm not sure it matters. It's good practice to zero things out for these types of api's anyway.

3 - I wouldn't make any assumptions about member positions.

Here's a utility function I use:

Code:

bool run(const wchar_t *cmd, PROCESS_INFORMATION *pi/*=0*/, bool bHide/*=true*/,
         const wchar_t *cmd_line/*=0*/)
{
    // CreateProcess() needs a non-const string for 2nd param
    const wchar_t *p1 = 0;
    wchar_t p2[MAX_PATH * 2] = {0};
    
    if (cmd_line)
    {
        p1 = cmd;
        lstrcpyW(p2, cmd_line);
    }//if
    else
    {
        p1 = 0;
        lstrcpyW(p2, cmd);
    }//else

    PROCESS_INFORMATION ProcInfo = {0};
    STARTUPINFOW si = {0};

    si.cb = sizeof(si);
    
    if (bHide)
    {
        si.dwFlags = STARTF_USESHOWWINDOW;
        si.wShowWindow = SW_HIDE;
    }//if

    BOOL bSuccess;
    bSuccess = CreateProcessW(p1, p2, 0, 0, FALSE, 0, 0, 0, &si, &ProcInfo); 
    if (!bSuccess)
    {
        LogMessage(L"CreateProcess(%ls %ls) failed, le = %u", 
                   cmd, cmd_line ? cmd_line : L"", GetLastError()); 
        return false;
    }//if
    else
    {
        LogMessage(L"Run(%ls %ls)", cmd, cmd_line ? cmd_line : L"");
    }//else

    if (pi)
    {
        // caller is responsible for closing handles
        *pi = ProcInfo;
    }//if
    else
    {
        CloseHandle(ProcInfo.hThread);
        CloseHandle(ProcInfo.hProcess);
    }//else

    return true;
}//run

gg

Originally Posted by Yarin

Check the documentation. If said parameter is marked "out" then yes, but if it's marked "in-out" then no.

How can you be certain that passing the StartupInfo struct (which is marked "in") while containing garbage data is unsafe when the process being created will never do anything with it?

I guess it's not specified if CreateProcess will do anything with the StartupInfo parameter before this data will become available to the newly created process. So passing the StartupInfo struct while it contains garbage data to CreateProcess could result in undefined behaviour. This should be avoided and so, as Yarin states, it becomes irrelevant whether the newly created process does anything with the provided StartupInfo data.

But why do all the examples regarding the use of CreateProcess zero the ProcessInformation struct as well before passing it to CreateProcess other than good practice?

So passing an uninitialized output argument could cause undefined behaviour?

Originally Posted by Ktulu

So passing an uninitialized output argument could cause undefined behaviour?

Technically it could. Bad actors could assume CreateProcess succeeds, and if PROCESS_INFORMATION is uninitialized, the garbage may be read, introducing undefined behavior.

Feel free to remain unsatisfied with good practice, perhaps I phrased it poorly, but it is easier to prove that a program works when you know the state of the variables from beginning to end.

Where does the documentation say that it reads the ProcessInformation struct? The documentation says:

lpProcessInformation [out]
A pointer to a PROCESS_INFORMATION structure that receives identification information about the new process.

This gives me the impression that there will only be information written to the ProcessInformation struct about a newly created process. Thus leaving garbage values in the ProcessInformation struct will result in the same behaviour as setting everything to zero before passing it to CreateProcess.

I should have been more specific when I referred to "an uninitialized output argument".

Originally Posted by Yarin

But even so, I would still zero out ProcessInformation. That way if CreateProcess fails I can still use an handle out of the struct. Like Codeplug demonstrated, it's not exactly hard to do it.

That depends a lot on the situation how CreateProcess is being used. When CreateProcess fails it might not have altered the ProcessInformation struct. If you then decide to call CloseHandle with the hProcess and hThread members of ProcessInformation (which makes no sense to me) it might result in undefined behaviour, assuming ProcessInformation is left with garbage values.

But if in some situation the parent process relies on the successful creation of the new process, meaning it would terminate otherwise, there is absolutely no need to pass the ProcessInformation struct initialized with zero values.