CreateProcess returning error code = 5, access denied on Server 2003, Vista


  • Hello,

    I've got a windows service application that is trying to spawn a process to execute another console application.  It works great on Windows XP, but is failing on Server 2003 and Vista with error code 5, "Access denied".  I'm suspecting it has something to do with security.  Unfortunately, I am not sure what I should do.  Could someone please point me in the right direction?


    This is the code:


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

    if (CreateProcess(NULL, // application name
    (LPSTR)commandLine.str().c_str(), // command line
    NULL, // process security attributes
    NULL, // primary thread security attributes
    FALSE, // inherit handles
    0, // creation flags
    NULL, // environment block
    NULL, // full path to the current directory for the process
    &si, // startup info
    &pi)) // process information
        WaitForSingleObject(pi.hProcess, INFINITE);
    int lastErrorCode = GetLastError();
        LPVOID lpMsgBuf = NULL;
                             (LPSTR) &lpMsgBuf,

        // bla bla

    Monday, January 12, 2009 11:59 PM

All replies

  • If you want this to run on Vista, be aware that this is by design.

    See: Impact of Session 0 Isolation on Services and Drivers in Windows Vista.

    As a general rule, windows services should never do this as it opens the door to shatter attacks. You should re-consider this effort.
    Tuesday, January 13, 2009 12:11 AM
  • Hello,
    I wonder why but the following code works with my case...
    I have my Vista with which UAC is disallowed, though.

            int ret; 
            if( !CreateProcess( lpPath,   // No module name (use command line) 
                NULL,        // Command line 
                NULL,           // Process handle not inheritable 
                NULL,           // Thread handle not inheritable 
                FALSE,          // Set handle inheritance to FALSE 
                0,              // No creation flags 
                NULL,           // Use parent's environment block 
                NULL,           // Use parent's starting directory  
                &si,            // Pointer to STARTUPINFO structure 
                &pi )           // Pointer to PROCESS_INFORMATION structure 
                ret = (int)(::ShellExecute(NULL,_T("open"),lpPath,NULL,NULL,SW_NORMAL) ); 
                    return ; 

    Tuesday, January 13, 2009 12:11 AM
  • I certainly agree that this is a good thing in the Vista design to separate service execution from regular user application execution.   I guess the danger in what I am trying to do is that the service application which is running at an elevated privilege level is trying to spawn a user application which could be hijacked for malicious intent.

    Unfortunately, I do not have the flexibility to avoid this requirement in my service application.  I have to be able to somehow execute another program from the service application.   This other program performs some required processing that I am not able to absorb into the service itself.  Do you have any other ideas how I could do this safely?

    Thanks for the help!
    Tuesday, January 13, 2009 3:37 PM
  • One other piece of information I left out is that this service application is running as the "System" user.  I have verified that the "System" user does have the security privileges to access/execute the program spawned via the CreateProcess API call.
    Tuesday, January 13, 2009 5:11 PM
  • The application isn't on a network share by any chance, is it? The SYSTEM account by default cannot access network resources.
    Tuesday, January 13, 2009 5:41 PM
  • Nope, it's installed in a folder on the C: drive.  I've also tried to execute several different programs each installed on the C: drive as well with the same results.

    The program that I need to execute as a child process has no UI.  It simply performs some data extraction from an archive file.  I would absorb this functionality into my service application if I could, but I do not have the source.

    Tuesday, January 13, 2009 7:32 PM