Diagnosing and Resolving a ToastNotification Exception

Question

QUESTION:
My simple Windows notification application throws an exception with the error message "Access is denied." How can I fix this?

PREFACE:
The structure in use is prescribed by the current implementation of and constraints placed on our application. While a better structure than this may exist, changing the structure is not an option at this time.

Relevant structural information:
We have a service that always runs. This service will spawn a process--let's call it data.exe--for every active session ID on the machine. For example, if there are currently four sessions active on the server with session IDs 1-4, data.exe will be running for all 4 sessions. Notably, the user name in Task Manager for each process is SYSTEM, despite running in non-zero session IDs.

INFORMATION:
My application--toaster.exe--is supposed to be launched from a different process via CreateProcessW(). The full launch function is adapted from a Raymond Chen blog post found here. As a brief explanation of what this function does, it launches a program with the shell as its parent process. For clarity, I implemented this function into data.exe to launch toaster.exe, and the adaptations I made are simply to handle errors and, obviously, to launch the particular program I want, rather than cmd.exe. Mr. Chen's function was the only method I found that would successfully and reliably launch my application and have it perform as intended.

Currently, if I launch toaster.exe by clicking on it, it performs its functions perfectly. I can also confirm that I am able to launch toaster.exe from another process--I setup a test application that can successfully launch toaster.exe in such a way that it does not throw an exception. To clarify what I mean by "functions perfectly," toaster.exe successfully sends me a simple one-line notification with a message that I have hardcoded for testing purposes.

However, if I launch toaster.exe from a program that was launched by our service, it hits an exception when it attempts to create the winrt::Windows::UI::Notifications::ToastNotification object. Unfortunately, this last one is the only launch method I care about--this program needs to be compatible with being launched in this way because it will always be launched by data.exe, which, as mentioned in the preface, is launched by our service.

Here is the function in toaster.exe where the exception occurs:

using namespace winrt;
using namespace Windows::Data::Xml::Dom;
using namespace Windows::UI::Notifications;

void SendBasicToast(const std::wstring &strMessage)
{
    // Construct the toast template
    XmlDocument doc;
    doc.LoadXml(L"<toast>\
    <visual>\
        <binding template=\"ToastGeneric\">\
            <text></text>\
        </binding>\
    </visual>\
</toast>");

    // Populate with text and values
    doc.SelectSingleNode(L"//text[1]").InnerText(strMessage);

    // Construct the notification [THIS LINE CAUSES AN EXCEPTION]
    ToastNotification notif{ doc };

    // And send it!
    DesktopNotificationManagerCompat::CreateToastNotifier().Show(notif);
}

DesktopNotificationManagerCompat.h comes from this Microsoft repository, which is supplemental material to their local toast notification tutorial. For completeness of information, I will note that DesktopNotificationManagerCompat::CreateToastNotifier() is a simple wrapper for ToastNotificationManager::CreateToastNotifier() and is defined as such:

ToastNotifier DesktopNotificationManagerCompat::CreateToastNotifier()
if (HasIdentity())
    {
        return ToastNotificationManager::CreateToastNotifier();
    }
    else
    {
        return ToastNotificationManager::CreateToastNotifier(_win32Aumid);
    }
}

I have already tried removing this wrapper function and directly calling CreateToastNotifier() with my AUMID as a parameter, but this also resulted in an exception being thrown. However, this is not strictly relevant because the exception is thrown on the previous line.

The way I call the toast function:

try
{
    std::wstring strMessage{ L"<(^.^<) || Default Toast || (>^.^)>" };
    SendBasicToast(strMessage);
}
catch(winrt::hresult_error &e)
{
    //Log the exception message
}

The only way toaster.exe will be launched is via data.exe as described in the above paragraph (and if the user clicks it in the notification tray, but that is beyond the scope of this question). As evidenced by this question, however, it does not work as intended in the particular circumstance under which I need it to work. I have diagnosed the issue to a single line (keep in mind I am effectively using namespace winrt::Windows::UI::Notifications):

ToastNotification notif{ doc };

EDIT:
Thanks to @IInspectable suggesting that the exception may have type winrt::hresult_error, I was able to discern that the error message I am receiving from the ToastNotification constructor is "Access is denied." Normally, I would expect this to require elevated privileges to resolve, but when I run the program myself, it runs with standard privileges and does so without issue. What access is being denied and how do I attain it?

Microsoft Q&A Page for reference

PRE-EDIT EXCEPTION TROUBLESHOOTING:
[This section is no longer strictly relevant]
I cannot find any MSDN documentation about this class in WinRT (only C#), and looking at windows.ui.notifications.2.h--the file that Visual Studio opens when I click "Go to definition" on ToastNotification--I was unable to discern what type of exceptions this constructor may throw. Thus, I know the line that is throwing an exception, but I do not know what type the exception is, and therefore I do not know why it is throwing this exception, nor how to fix it. I don't recall everything I have placed into the parenthesis after catch, but I know I have tried assuming it was a std::exception, const char*, and const wchar_t*. Attempting to use the catch block with all of these resulted in a crash.

I am at a loss for how to diagnose this issue, let alone fix it. The best information I have is that this exception only occurs when toaster.exe is launched from data.exe, but I don't know what to do with that information.

Answer 1

EDIT 2022/2/28:
I have found a more elegant solution to this problem involving WTSQueryToken() and GetTokenInformation() thanks to this SO answer.

WTSQueryToken() returns a filtered user token, and without any extra steps, this token can be placed into a CreateProcessAsUserW() call to spawn my notification app.

I opt to call GetTokenInformation() to obtain the unfiltered (read: elevated) token for the user, which allows me to keep all my application's logs centralized in the Program Files directory. I am unclear if a process launched with an unfiltered token of a user without admin privileges will still be able to log to the Program Files directory, but this is non-essential to the process's ability to run.

SOLUTION:
The error message given for the thrown exception is Access is denied. This may or may not be the result of a bug related to the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS flag. The workaround for this is simply to spawn the process again from the child process, using the exact same function call minus the problematic flag.

In my case, I pass a parameter that acts as a flag to tell the child process that it needs to relaunch itself.

EXPLANATION:
Thanks to the guidance of @IInspectable, I was able to resolve my issue.

Firstly, IInspectable informed me that the exception's data type was likely that of a winrt::hresult_error, which ended up being correct. From this, I was able to see that the exception message was Access is denied.

After updating my question to reflect this, IInspectable returned to point me towards the bottom of the comments of the Raymond Chen blog post that I linked in my question.

In short, the comment suggests that there is an underlying bug in the API that causes processes spawned in the way demonstrated by Chen to load with incorrect parameters, and offers a simple workaround by using Chen's function from within the child process to launch another child process. The comment also suggests that removing the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS flag from the second function call is necessary, but this is not something I needed to do for the workaround to succeed.

For posterity, the comment from the blog post comments is as follows:

There are issues using the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS flag… Environment variables for the new process are copied from the High-IL process not the Medium-IL process which cause issues with shell functions and some directory paths (%temp%, %userprofile% etc…) The token security descriptor for the process is also created without an ACE for the current user blocking access to most resources and the token security descriptor will also have a High-IL even though the process itself has a Medium-IL… This blocks the new process from accessing any system objects (events/pipes/sections/IPC etc…) while also blocking the process from opening its own process token with TOKEN_QUERY access. This seems to be a severe bug with the API but not sure if it’ll be fixed. As a workaround you can call CreateProcess a second time but from the new child process (without the PARENT_PROCESS flag) and it’ll be created with the correct token DAC security and environment variables (this is also why the above above sample doesn’t have issues with cmd.exe since it launches child processes).