Next time just try to close and reopen the process (hehe what a cliche...)

The reason is that once a process is launched, all the variables are being written to its own address space.

If you are changing the User \ System variables - the open cmd.exe (for example) won't get the new values, but a new cmd.exe process will...

gl,

Refael

If you do set "a=x%b%y", then a is defined exactly like that, and %b% will only be expanded when required. This is why alphabetical order has no importance. Variables are substituted when their value is required, and PATH is an example of a value that is immediately required.

To automate setting environment variables, put the SET commands in a batch file (.bat) and copy the file to the Startup folder.

Your personal startup folder should be C:\Users\<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, while the All Users startup folder should be C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.

Question: What am I doing below that is different than what you do? You could show us a similar screenshot if you are getting different results.

As regarding the example you have posted, the results are as expected. You have used the setx command, which sets environment variables for the user in the registry, but not in the local environment. You would need to start a new Command Prompt from the desktop to benefit from that variable.

The important point here is that setx works on the registry, but that does not cause the local environment to be re-evaluated. The environment is built only once, when a process is launched, then stays the same all through execution (unless modified locally by the process itself). Any child started by a parent process will inherit its parent's environment, so no reference is made in that case to the registry.

The demo below demonstrates the problem: The variable is set in the above Command Prompt, but doesn't have a local value. The lower Command Prompt is then started from the desktop, and it does have that value.