Csdrhrt

The environment variables shown by the SET command can be notably different depending on the
privilege level of the command prompt session. Moreover, it seems that any program run with
administrative credentials by the same user can create environment variables that will persist long after that process ends, and will be set in any subsequent elevated process
launched by that user (and ONLY in those elevated processes). I have not been able to find those variables in the Environment tab shown by Process Explorer for any process associated
with the user login session. My Question is: where are those values stored, and why is
Process Explorer unable to access them (of course, since Process Explorer runs elevated by
default those variables appear in its own Environment tab)? Or did I just overlook them?

Where do the environment variables for an elevated cmd.exe process come from?

Like all processes, it gets its environment from the process that spawned the command-prompt instance.

When a process spawns another process, the child process inherits the parent’s environment. If the parent was privileged, then it probably has more/different variables than if it isn’t. When it spawns a child process, the child gets the same set to start with.

The environment variables shown by the SET command can be notably different depending on the privilege level of the command prompt session.

Because when Explorer doesn’t actually spawn privileged processes, the CSRSS does. When you run a program “as admin”, you get a UAC prompt which dims the screen. This is because the CSRSS is a system process which handles UAC prompts and process-elevation. So while Explorer and its child processes have one environment, an elevated command-prompt (which is spawned by the high-privilege system process at the behest of Explorer) gets a slightly different set with some extra/different variables.

Moreover, it seems that any program run with administrative credentials by the same user can create environment variables that will persist long after that process ends and will be set in any subsequent elevated process launched by that user (and ONLY in those elevated processes).

Nope. The set command is session-only. Once you close that command-prompt, any changes you’ve made go poof. To make persistent changes, you must use an external tool like a third-party utility or the Microsoft tool program setx. This is true of even elevated command-prompts; the set command simply has no functionality to modify the environment in the registry.

I have not been able to find those variables in the Environment tab shown by Process Explorer for any process associated with the user login session.

Because any changes you make with set will only be visible in that specific command-prompt and any processes that you launch from That specific command-prompt; the changes do not propagate to other processes.

My Question is where are those values stored, and why is Process Explorer unable to access them (of course, since Process Explorer runs elevated by default those variables appear in its own Environment tab)? Or did I just overlook them?

The session variables are stored in that specific command-prompt’s environment. Process Explorer can see them for that specific instance of cmd, but they won’t be in any other process. If you launch a program from that command-prompt, then you can see those changes in the child process’ Environment tab in Process Explorer because it will have inherited them from that command-prompt.

If you use a program like setx to set a persistent variable, then they will be stored in the registry. If you set a user-level variable (for the current user), it will be stored in HKCUEnvironment (or HKU<USER>Environment for other users). If you set a system-level variable, then it will be stored in HKLMSYSTEMCurrentControlSetControlSession ManagerEnvironment.

Be aware that if you manually modify the environment through the registry, only new processes will pick up the changes. To get existing process to see the changes, you have to either restart them or broadcast a WM_SETTINGCHANGE message. (Tools like setx broadcast the message to all top-level windows.)

I think the output of SET can only be different when you're not logged in as a member of the Administrator group. That's why you're asked for a user/password in that case, you actually login as a Administrator for that process.

If you are already a member of the administrator group, then the output of SET is the same in both cases for me.

Therefore, if my hypothesis is true, the elevated privilege variables are defined as User Variables for Administrator.

It is not very clear exactly how the environment variables are set in a newly created elevated process, but most of them come from the current user's existing set (as shown by the non-elevated cmd.exe SET command), as well as any that exist in the user's HKCU/Volatile Environment registry key, which have been created since the start of the current login session (or current instance of Explorer?) and are not shown in the non-elevated SET list. There are a few variables in my Windows 10 which occur in the non-elevated list but not the elevated one.

This question was motivated by the behavior of older versions of Macrium Reflect, which is discussed at https://forum.macrium.com/Topic752-1.aspx The current version of that program now creates those problematic variables at HKU/.DEFAULT/Volatile Environment (AKA HKU/S-1-5-18/Volatile Environment) instead of under the HKCU key.