MessageBox and ShellExecute succeed, but nothing is shown if called right before the application exits

I'm trying to display a MessageBox with some debugging information right before my application exits in case of a specific error. The reason I need to display it as a message box vs. just logging it in a file is because I need it to draw my attention right when the error happens. (With a silent logging, I might miss the moment when the error first starts happening.)

And, it would be also nice to open a file at the same time if the user chooses to.

So I'm calling the following "vanila" code from the destructor of one of the globally declared structs. In other words, it will be called right before the process exits:

int nRes = MessageBox(NULL, 
    L"Specific error occurred, do you want to open the log file?", 
    L"ERROR", 
    MB_YESNOCANCEL | MB_ICONERROR | MB_SYSTEMMODAL);

//'nRes' is returned as IDYES immediately w/o displaying a dialog

if(nRes == IDYES)
{
    int nResOpen = (int)ShellExecute(NULL, L"open", L"path-to\\file.txt", NULL, NULL, SW_SHOWNORMAL);
    BOOL bOpenedOK = nResOpen > 32;

    //'nResOpen' is returned as 42 but the file doesn't open
}

The code above works fine if I call it from anywhere else while the process UI was still shown. But the behavior described in the code comments happens when I call it from the destructor right before the app closes.

Any idea how to make it work in this situation?

PS. I'm testing it on a 64-bit Windows 10 Pro. The project is built as x64 MFC/C++ process.

PS2. EDIT:

Adjusted the code to follow suggestions in the comments. To repro -- define the struct as such:

struct TEST_STRUCT{
    TEST_STRUCT()
    {
    }

    ~TEST_STRUCT()
    {
        //The call below only plays the error sound...
        int nRes = MessageBox(NULL, 
            L"Specific error occurred, do you want to open the log file?", 
            L"ERROR", 
            MB_YESNOCANCEL | MB_ICONERROR | MB_SYSTEMMODAL);

        //'nRes' is returned as IDYES immediately w/o displaying a dialog

        if(nRes == IDYES)
        {
            SHELLEXECUTEINFO sei = {0};
            sei.cbSize = sizeof(sei);
            sei.lpFile = L"path-to\\file.txt";
            sei.nShow = SW_SHOW;
            sei.fMask = SEE_MASK_NOASYNC | SEE_MASK_FLAG_NO_UI | SEE_MASK_NOCLOSEPROCESS;

            ::SetLastError(0);
            BOOL bOpenedOK = ::ShellExecuteEx(&sei);
            int nErr = ::GetLastError();
            if(bOpenedOK)
            {
                if(sei.hProcess)
                {
                    DWORD dwR = ::WaitForSingleObject(sei.hProcess, INFINITE);
                    DWORD dwExitCode = 0;
                    if(::GetExitCodeProcess(sei.hProcess, &dwExitCode))
                    {
                        //Check error code

                    }
                }
                else
                {
                    //When called before app's exit it gets here -- no process handle
                    //'nErr' == 0x8000000A
                }
            }

            if(sei.hProcess)
                    CloseHandle(sei.hProcess);
        }
    }
};

I then created an MFC dialog-based GUI project, and added declaration for the TEST_STRUCT right before CWinAppEx derived variable as such:

Then debug it with Visual Studio. (In my case VS 2008 SP1.) Put the breakpoint on the destructor, run the app and close it. The breakpoint should trigger. Then walk through the code above. I was able to reproduce it on Windows 8.1 as well. (Read comments in the code.)

The problem is calling the code after main has finished. That is a murky time in the C++ standards, and the runtime and MFC system is shutting itself down. It would be better to launch your code before the end of the application.

If I remember correctly, theApp has a function which is called near the end of the lifespan of the application.

Global variables are initialized from the top of the file (compilation-unit) to the bottom of the file.

Between different files in the same binary (.exe, .dll), the order of how these files are processed is not defined by any standard.

Modern (C++11 and better) make some effort to ensure they are available, by having dynamically constructed things.

ComplexThing & get_some_stl_resource() {
     static ComplexThing resource;
     return resource;
}

the code above generates the ComplexThing when first needed, and will destroy it at the end of the program with an added atexit handler.

The calling of the atexit things is the opposite order to their creation. In your case, there is no code in the constructor, which gives the language no chance to pin any behavior. So when your destructor is called, there is no guarantees of any functionality, as there was no statement for what would be needed from the construction.