Createprocess and 0xc0000142 error

Question

i have the following test code:

#define CMDLINE ".\\dummyFolder\\dummyProc.exe op1 op2 op3"

int main(int argc, char **argv) {

STARTUPINFO info;
info.cb = sizeof(STARTUPINFO);
info.lpReserved = NULL;
info.cbReserved2 = 0;
info.lpReserved2 = NULL;

PROCESS_INFORMATION processInfo;

SECURITY_ATTRIBUTES procAttr;
procAttr.nLength = sizeof(SECURITY_ATTRIBUTES);
procAttr.lpSecurityDescriptor = NULL;
procAttr.bInheritHandle = false;

SECURITY_ATTRIBUTES threadAttr;
procAttr.nLength = sizeof(SECURITY_ATTRIBUTES);
procAttr.lpSecurityDescriptor = NULL;
procAttr.bInheritHandle = false;

bool handlersInheritable = true;

char cmdLine2[sizeof(CMDLINE)];
strcpy(cmdLine2, CMDLINE);

char AppName[sizeof(".\\dummyFolder\\dummyProc.exe")];
strcpy(AppName, ".\\dummyFolder\\dummyProc.exe");


if (CreateProcess(AppName, cmdLine2, &procAttr, &threadAttr,
        handlersInheritable, 0, NULL, NULL, &info, &processInfo)) {

    //::WaitForMultipleObjects(procQty, handlers, waitForAll, waitInterval);
    CloseHandle(processInfo.hProcess);
    CloseHandle(processInfo.hThread);
    CloseHandle(info.hStdError);
    CloseHandle(info.hStdInput);
    CloseHandle(info.hStdOutput);
} else {
    std::cout << "Returned: " << GetLastError() << std::endl;
}

std::cout << "Exiting main process" << std::endl;

return 0;
}

This is just a test code for creating processes in windows. The problem is that when i launch "dummyProc.exe" i get a 0xc0000142 error.

The process dummyProc.exe runs fine from the command line, but not from within the code.

Here's the dummyProc code if it helps:

int main(int argc, char **argv) {


std::cout << "Working!!!!" << std::endl << "Receivedi: " << std::endl;

for (int i = 0; i < argc; ++i)
    std::cout << argv[i] << std::endl;


return 0;
}

So, any ideas?

Elrod

See support.microsoft.com/kb/960266 – Inadmissible

Answer 1

The most obvious thing that char cmdLine2[sizeof(CMDLINE)]; declares a string of length equal to your machine's pointer size. You need to use strlen(CMDLINE)+1 instead. Likewise for appName.

Note that the first parameter to CreateProcess does not need to be writeable. Just pass the string literal directly to it. No need for appName variable.

As for lpCommandLine which does need to be writeable it's easiest to do it like this:

char cmdline[] = "op1 op2 op3";

That gives you a writeable buffer. Note that you do not need to repeat the executable file name.

Another problem is that you have not initialized all the parameters to CreateProcess. For example the STARTUPINFO struct has 19 fields and you initialize only 3. You should initialize all your structs to 0 and then fill out any fields you need to be non-zero. Like this:

STARTUPINFO info = { 0 };

Do this for all the structs you pass.

You can, and should, pass NULL for the lpProcessAttributes and lpThreadAttributes parameters.

Clemmer

Not initializing all bytes of STARTUPINFO will result in every process exit with code as 0xC0000142 immediately - even for C:\Windows\SysWOW64\cmd.exe. Overlooked this culprit for hours. It's like the OS wants you to fail when you don't work properly. – Minimalist

Answer 2

This answer is to relate another cause for 0xc0000142 - placed here (even though another answer was accepted for this question) because there is very little useful information on the intertubes about this error - and a shocking lack of any useful information on the subject from Microsoft - and so someone's internet search may get them here. (Well, mine did.)

So: You can get The application was unable to start correctly (0xc0000142) on starting a process written in C++ where you access though a null pointer in a constructor of a static object. (In my case it was in an initializer of a constructor of a static object.)

Your hint to this will be an event in the application log (event id 1000 source "Application Error") which has lines similar to the following:

Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000000000000

0xc0000005 is access violation, of course, and the offset of 0 (actually anything less than 0x10000 is a reference through a null pointer.

Anyway, the surprising thing (to me) is that evaluating statics happens before the debugger can attach (!!) so launching it with ImageFileExecutionOptions set or even directly within Visual Studio doesn't let you debug this thing!!

(And then of course you won't find 0xc0000142 in any Microsoft documentation whatsoever. Well done, NT team!)

Laudable

That NTSTATUS is documented as STATUS_DLL_INIT_FAILED – Clemmer