desktop-toasts | raw samples for desktop toasts using com activation | Dektop Application library

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).