4

I have a strange behavior with the environment variables at my Windows XP SP3.

When I logon as Administrator, the %SystemRoot% strings in PATH are substituted to C:\WINDOWS, the value of the variable 'SystemRoot' is C:\WINDOWS.

But when I logon as any non-administrative user, the %SystemRoot% literally remains in the PATH, although the variable 'SystemRoot' has the same value as with Administrator's account.

Running PowerShell as a normal user:

PS C:\Users\vic> $env:path (Enter)

%SystemRoot%\system32\WindowsPowerShell\v1.0\;C:\Program Files\AMD APP\bin\x86;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static

Running PowerShell elevated (I right click, run as admin):

PS C:\Windows\system32> $env:path

C:\Windows\system32\WindowsPowerShell\v1.0\;C:\Program Files\AMD APP\bin\x86;C:\Windows\system32;C:\Windows;C:\Windows\ System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static

Env path in Windows:

C:\Program Files\AMD APP\bin\x86;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SystemRoot%\System32\WindowsPowerShell\v1.0;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static

Why?

  • 1
    What is the question / issue precisely? – Austin T French Oct 17 '13 at 14:12
  • He's asking why the expression of the $PATH variable is different (albeit slightly) when the shell is elevated. – Colyn1337 Oct 17 '13 at 18:50
1

This is probably related to a known bug in Windows XP, Windows 7, and several others. (Based on available documentation, it either does not affect or has not been seen in Windows 8 or later.)

The bug is documented in Microsoft KB Article #329308 (Environment variable may not expand %APPDATA% to the Application folder). It is also documented as a Medium vulnerability in the NIST National Vulnerability Database, as CVE-2007-6753. One of the cited references in the CVE entry, an article on the ACROS Security Blog, claims the issue may be as old as, or even older than, 2003.

Though the referenced KB article specifically mentions %APPDATA%, the bug affects all "variables-within-variables", and particularly becomes a security concern when it shows up in the %PATH% variable.

I don't know why elevated privileges would make a difference in how this bug is expressed. In my experience, reproduction of the issue is typically pretty flaky anyway. But the general case of variables-within-variables not being properly expanded is a known bug, so I would not spend much time trying to actually troubleshoot it.

The only workaround I'm aware of is to edit the affected variables so that paths are explicitly defined, instead of reliant upon other variables. Anywhere you see "%SystemRoot%" in %PATH%, replace it with the exact value of %SystemRoot%. Do the same for any other nested variables in your environment where possible - especially where those variables define file/folder paths.

  • I encountered this issue on windows 10 (1803). It appeared without any clear cause this morning. I have replaced all env. variable substitutions within my path with explicit values and I could work again. – Stephane Nov 27 '18 at 11:05

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.