Tracking launch errors for your game with a simple c++ app

Question

I am trying to create a simple app to track launch errors for my game. The idea is to launch a c++ program, that in turn launches the main game .EXE file with CreateProcess(). The c++ app then proceeds to wait untill the process finishes and shows an error report to the user, if the error happened. This is how I implemented this:

#include <windows.h>
#include <iostream>
#include <string>
using namespace std;

int main()
{
    // additional information
    STARTUPINFO si;
    PROCESS_INFORMATION pi;

    // set the size of the structures
    ZeroMemory(&si, sizeof(si));
    si.cb = sizeof(si);
    ZeroMemory(&pi, sizeof(pi));

    const string appName = "MAIN.exe";
    const string appLocation = "";


    // start the program up
    BOOL result = CreateProcess((appLocation + appName).c_str(),   // the path ".." <- перейти вверх "\\" <- относительный путь.
        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 si structure
        &pi);           // Pointer to PROCESS_INFORMATION structure



    if (!result)
    {
        MessageBox(HWND_DESKTOP, ("Could not locate " + appName + "! Please reinstall the game!").c_str(), "Error!", MB_OK);

        // We failed.
        return FALSE;
    }
    else
    {
        // Successfully created the process.  Wait for it to finish.
        WaitForSingleObject(pi.hProcess, INFINITE);

        DWORD exitCode = NULL;
        // Get the exit code.
        result = GetExitCodeProcess(pi.hProcess, &exitCode);

        // Close process and thread handles.
        CloseHandle(pi.hProcess);
        CloseHandle(pi.hThread);

        if (!result)
        {
            // Could not get exit code.
            MessageBox(HWND_DESKTOP, "ERROR!", "Error!", MB_OK);
            return FALSE;
        }
        else if (exitCode != 259 && exitCode != 2)
        {
            if (exitCode == 1)
                MessageBox(HWND_DESKTOP, "ERROR!", "Error!", MB_OK);
            else
            {
                string errorString = to_string(exitCode);
                LPCSTR errorText = errorString.c_str();
                MessageBox(HWND_DESKTOP, errorText, "Launch error!", MB_OK);
            }
        }

        // We succeeded.
        return TRUE;
    }

    //MessageBox(HWND_DESKTOP, "Text here", "Text here", MB_OK);
    return 0;
}

From my humble tests I did not see any performance decrease, however, the c++ process is constantly sitting in the background and I wonder if there might be any problems with I that I should know about. Maybe there is a safer/easier way to implement this?

UPDATE: Just to clarify here are the reasons why I need this app (alongside trying to track errors internaly, which I already do):

I am developing on c# and XNA 4.0 for .Net Framework 4.5.1. And just that setup can lead to several issues:

1)The user might not have XNA 4.0 redist installed;

2)The user might have Windows 7 with vanila .Net 4.0 and not 4.5.1;

3)The user might have Windows XP which I do not support (due to .Net target 4.5.1);

4)The user might have a GPU which does not support DX 10, (a requirenment for XNA 4.0).

But in most of those cases the app will simply crash on startup, and from what I read, there is no way to catch an error internaly as they happen at an assembly level.

Answer 1

On a modern computer one more idle process in the background would barely be noticeable especially since you use a WaitForSingleObject.

I do however question the usage of a second process for retroactive compatability checking, if you're that concerned parts might missing then package the game with the proper redistros so you always know they're there.

Or just leave the responibility with the end user to have a proper enviroment, you can't be expected to nanny on them about everything, if a player tries to run it on an Apple II they can't be surprised when it crashes.