Certain Variables won't expand in Windows System Environment Variables PATH [duplicate]

SystemRoot expands as expected because it is a pseudo/predefined environment variable. WinDir is a regular environment variable, and "competes" with others like PATH in the initialization sequence.

Best explained by Raymond Chen at Windows Confidential: The hidden variables: "Embedding one environment variable within another is simply a matter of good operational timing". Quoting more:

Here’s how the environment-building process works. It proceeds in roughly four steps:

• First, the system creates some predefined machine-wide environment variables, such as System­Root and ALL­USERS­PROFILE (but not COMPUTER­NAME or Program­Files).
• Second, it creates environment variables from the System section of the Environment Variables dialog box. The System environment variable definitions can use the “%” notation to refer to the predefined environment variables created in the previous step. For example, you can set a System environment variable to %System­Drive%Extras. After the System environment is complete, Windows starts building the User environment.
• Step three is to create predefined per-user environment variables, such as USER­PROFILE and APP­DATA. The COMPUTER­NAME and Program­Files-related variables are also created here, even though they’re technically System variables and not per-user variables.
• Finally, the system creates the environment variables. These are in the User section of the Environment Variables dialog box and have access to any variables created by the first three steps, so you can set a User environment variable to %USER­PROFILE%Extras or a custom System environment variable set in the second step. If a User environment variable has the same name as a System environment variable, the new value replaces the old.

...

One customer was having difficulty setting the System PATH environment variable to %APPDATA%;C:Windows. They found the final environment merely contained the literal path as specified (percent signs and all), instead of replacing it with the value of the APPDATA environment variable. If you look through the sequence of operations previously detailed, it’s clear why this occurred. They were trying to set a System environment variable based on a variable that had not yet been defined.

The solution was simple: Move editing the PATH from the System environment list box to the User environment list box. That way, when it wanted to use the %APPDATA% environment variable, the variable would be there.

For a simple example of possible "race conditions" when defining environment variables based on others, consider the circular case where one defines two system variables as:

bbb=%ccc%
ccc=%bbb%

On my Windows 7 this results in the variables evaluating to:

C:etc>set
...
bbb=%ccc%
ccc=%ccc%

• Ahhh that makes sense. Thanks for that explanation!

  – AppetiteForDestruction

  Commented Feb 1, 2016 at 6:05
• it doesn't make any sense at least in such vague terms like "some predefined variables", "SystemRoot but not ComputerName" and especially ProgramFiles which is technically (sic!) System but in fact isn't. I tried to google any formal specs but there are no any at least at the first 5 screens of google output (

  – maoizm

  Commented Apr 29, 2017 at 17:43
• @maoizm See also ss64.com's Windows Environment Variables and this answer to Why can't I access a variable named CD on Windows 7?.

  – dxiv

  Commented Apr 29, 2017 at 17:56
• 6
  I discovered the following empirically when I realized that everything alphabetically after "PATH" was not expanded in the path. Is it worth editing in? -> Additionally, the SYSTEM and USER environment variables seem to be loaded in alphabetical order within a section, so if PATH refers to %JAVA_HOME% and %SCALA_HOME%, and those are defined in the same section, then when PATH is expanded, it will include the correct (expanded) value for JAVA_HOME, but it will include the literal (unexpanded) "%SCALA_HOME%".

  – shoover

  Commented Sep 27, 2018 at 23:39
• 2
  @shoover Thanks for the additional tidbit. Still, the exact sequence of evaluation for regular environment variables remains undocumented, so it could change with the next Windows build tomorrow, without MS owing any explanation, and therefore it would be a risky gamble to rely on it.

  – dxiv

  Commented Sep 28, 2018 at 5:37
• 1
  @shoover - Confirming your discovery. If i create %PATG% and %PATI% and add them both to %PATH%, the former expands, the latter does not. While @dxiv makes a good point that this may not be the official logic, it seems pretty reliable (and stupid) to me.

  – cautionbug

  Commented Oct 24, 2019 at 3:27
• So the workaround is to set extra variables %MY_SCALA_HOME% etc.

  – shoover

  Commented Oct 24, 2019 at 4:48
• 2
  FWIW, on Windows 11 (23H2), if the Path contains any variable that is alphabetically after Path, then none of the variables get expanded. I've discovered this with having %GIT_BIN% and %TOOLS% in the Path, and none of them expanded. I've removed %TOOLS%, and the remaining %GIT_BIN% expanded. Which is... surprising, to say the least, but I can fathom a sequence of events, why/how this is happening.

  – D. Kovács

  Commented May 7 at 5:20